The Infatuation with “Building Blocks”
Blog: Strategic Structures
Why the majority of Enterprise Architects are in love with the concept of “building block”. Perhaps because blocks don’t answer back and spoil the design, Aiden Ward suggested.
In TOGAF 9.1 “building block” is used 349 times, not counting the separate use of ABB and SBB acronyms. There is a whole chapter devoted to building blocks. In there, we find the following:
A building block is a package of functionality defined to meet the business needs across an organization.
A building block has a type that corresponds to the TOGAF content metamodel (such as actor, business service, application, or data entity)
A building block has a defined boundary and is generally recognizable as ‘‘a thing’’ by domain experts.
Now, if a “building block” is a “package of functionality”, taking it together with the second statement, then “actor” and “data entity” are – according to TOGAF – types of “package of functionality”. That doesn’t bother me so much, as logic and consistency have never been among the strong sides of TOGAF. I’m more concerned with the last statement. There are indeed some entities from the model that are recognised by domain exerts as “things” with defined boundary, but I haven’t heard a domain expert using “building block” to discuss their business. Even if there are some that do, having surrendered to the charms of eloquent Enterprise Architects, I don’t think they use that language among themselves or that they need to.
Enterprise Architecture is not unique in using technology metaphors for understanding its organisation. After some circulation of the brain as metaphor for computer, then the computer returned the favour and have been used for decades as a metaphor for the brain. Not even that, it tuned the thinking of some cognitive scientists in such a way, that many of them managed to “prove” that the brain is doing information processing. That school of thought, the so called computationalists, has still a lot of followers today. The same school regards the mind “running” on the body just like software is running on hardware. That approach has been doing much more harm on an array of disciplines, than the usage of building blocks on Enterprise Architecture. But qualitatively, it is a similar phenomenon.
It’s now time to choose some structure for building the point about my puzzlement (and then hopefully solving it), and I select the following titles for my text blocks: name, history, and purpose.
Name
The primary source of irritation – I have to admit – is the name itself. But it is also a minor one, so we can quickly deal with it.
Where is the name coming from?
EA is often perceived by non-EA people as something coming from IT which is not even proper IT. The IT parlance in general has borrowed a lot of terms from other engineering practices. Software development in particular has shown preference for construction engineering over – what would have seemed a more natural choice – electronic engineering. And that’s why we are “building” software. Having in mind how iterative that is, if that “building” is brought back and applied to actual buildings, there won’t be many happy investors or inhabitants.
Anyway, “to build”applications is well established and doing well in software development. But what is the utility of “building block” in Enterprise Architecture? Indeed, representing some abstractions as boxes, and placing them one over another resembles playing with Lego. The metaphor is bringing a more than welcome simplicity to the architecture discussions. But, apart from smoothing communication between Enterprise Architects, is it useful for anything else? And how does the name reflect the actual use of the concept?
My quick answer is: there is nothing that can be built using architecture building blocks. Something can be drawn and then reconfigured in another drawing. Isn’t it then more appropriate to talk about “description” blocks or “design” blocks?
Some Enterprise Architects are well aware of that. In fact it seems that the choice of “building block” over “component” is exactly to remind the users that the former is not the latter but just an abstract representation of it. This has been debated for about a decade, and various solutions have been proposed, including “reusable” blocks, which would make the purpose explicit, at least.
But this awareness is neither widespread not persistent enough to prevent the stabilisation of some thinking habits leading to decisions that look good only within the protected virtual reality of architecture descriptions.
History
There are two lines of history we can follow. One is the evolution of “building block” in the Enterprise Architecture discipline; the other is how a building block comes about in a concrete EA practice. If that was about species, a biologist would call the first line phylogenesis, and the second one – ontogenesis.
Following the first one would probably reveal interesting things but would require an effort that the concept does not justify for me. That’s why I’ll limit tracing that history to the hypothesis of the origin I discussed in the Name section.
A building block in a concrete enterprise architecture practice is typically coming as specialisation of a generic element. That generic element, called concept, stereotype or construct, is based on assumptions about what are, based on a history and knowledge of different concerns at the moment of the meta-design, the important patterns that need to be represented. These are, if we take Archimate as a popular example, things like Role, Event, Process, Service, Interface, and Device. Their application however, is limited by three restrictions:
- first, when an entity is represented it has to be as one of these types;
- second, the criteria for making the choice is coming from interpreting definitions of these concepts and not from what the represented object from the real world has or does (there are generalised relations, but they are not used for that);
- third, something cannot be represented as more than one concept.
So, a building block, being a specialisation of a concept, asserted in this way, inherits both this set of restrictions and everything else that’s coming from the object-oriented paradigm, which the use of “specialise” and “inherits” implied already.
Purpose
The use of building blocks in Enterprise Architecture is either directly supporting, or historically linked with, reusability.
A building block represents a (potentially re-usable) component of business, IT, or
architectural capability that can be combined with other building blocks to deliver
architectures and solutions. (TOGAF 9.1, p.11)
In order to support reusability building blocks should have the right level of granularity. Basically, they need to balance between flexibility and efficiency. In order to be reused, which would mean recombined, they shouldn’t be too coarse-grained, otherwise there won’t be enough flexibility. On the other hand, if there are too fine-grained, it won’t be efficient to maintain reference architectures.
Now, this seems key for understanding the popularity of “building block”. Enterprise Architects have to justify their reason-to-be. As both reusability and flexibility make a good business case, stabilisation of that concept could be just due to survival pressures. And then Enterprise Architecture in order to exist as such, should not only be allowed and fed but should have ways to assert itself as a social system. And the “building blocks” provide one of the conventions that make the network of communications within the EA practice sustain its identity.
Fine then, problem solved: Enterprise Architecture – being predominantly practised the way it is now – needs concepts such as “building blocks” in order to survive as economic entity, and as social system.
And yet, Enterprise Architecture can be practised and can bring more benefits without building blocks, layers, tiers and suchlike. It can be done by not reducing what is learned in the process to what was decided at the moment of knowing much less when the meta-model was fixed. The objects that need to be described and designed can get their type from how their descriptions satisfy the conditions for classification. And last but not least, it could be done entirely in the language that domain experts use and “building block” is not used by them, at least not in the service industry. When it is used by actual builders, I doubt they mean “package of functionality”.
Leave a Comment
You must be logged in to post a comment.
