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 recognized by domain exerts as “things” with defined boundaries, but I’m yet to hear a domain expert using “building blocks” to discuss their business. Even if there are some that do, having surrendered to the charms of eloquent Enterprise Architects, I doubt they use that language among themselves. And they don’t need to.

Enterprise Architecture is not unique in using technology metaphors to understand its organization. After some circulation of the brain as a metaphor for the computer in computer science, then cognitive science returned the favor by using the computer as a metaphor for the brain. Not only that, it guided the thinking of most cognitive scientists to “prove” that the brain is doing information processing. That school of thought, the so-called computationalists, still has a lot of followers today. The same school regards the mind as “running” on the body just like software is running on hardware. That approach has been doing much more harm to an array of disciplines than the usage of building blocks in 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 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 has shown a preference for construction engineering over – what would have seemed a more natural choice – electronic engineering. And that’s why we are “building” software. Keeping 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 brings 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 that nothing can be built using architectural 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 nor persistent enough to prevent the stabilization of some thinking habits. They lead 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 were 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. 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 a specialization of a generic element. That generic element is based on a history and knowledge of different concerns at the moment of the meta-design, and 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 come from interpreting definitions of these concepts and not from what the represented object from the real world has or does (there are generalized relations, but they are not used for that);
• third, something cannot be represented as more than one concept.

So, a building block, being a specialization 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 “specialize” 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 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 they are too fine-grained, it won’t be efficient to maintain reference architectures.

Now, this seems key for understanding the popularity of “building blocks.” Enterprise Architects have to justify their reason-to-be. As both reusability and flexibility make a good business case, the stabilization 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. 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 practiced the way it is now, needs concepts such as “building blocks” in order to survive as an economic entity and as a social system.

And yet, Enterprise Architecture can be practiced 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. 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.”