Estimated reading time: 5 minutes
Why Building Blocks?
When embarking on any change effort, in the context of enterprise architecture usually referred to as a business transformation, partitioning the effort is essential for a successful, controlled result. This article tries to explain how to identify those parts: the building blocks that comprise the change.
The partitioning is not only necessary in the solution space (say, a new business process, or the implementation of a new IT system), but also on the strategic level. And both need to be aligned for a successful result.
What are Building Blocks?
The concept of a building block is neatly defined in TOGAF® as:
TOGAF 10th Edition: TOGAF Standard — Architecture Content
- Building blocks have generic characteristics as follows:
- A building block is a package of functionality defined to meet the business needs across an organization
- A building block normally has a type that corresponds to the 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
- A building block may interoperate with other, inter-dependent building blocks.
- A good building block has the following characteristics:
- — It considers implementation and usage, and evolves to exploit technology and standards
- — It may be assembled from other building blocks
- — It may be a subassembly of other building blocks
- — Ideally a building block is re-usable and replaceable, and well specified
A Building Block is an element that is used to “bridge the gap”: we are here, we want to get there, and this component is (part of) what we need to find ourselves “there”.
To partition the building block specification, usually two levels of abstraction are used:
- The Architecture Building Block (ABB)
The focus is on the architectural requirements here. The level of specification avoids specific tools or technology. Again, from the TOGAF Standard:- Fundamental functionality and attributes: semantic, unambiguous, including security
- capability and manageability
- Interfaces: chosen set, supplied
- Interoperability and relationship with other building blocks
- Dependent building blocks with required functionality and named user interfaces
- Map to business/organisational entities and policies
- The Solution Building Block (SBB)
The focus here is more on the specific guidelines for the actual solution.- Define what products and components will implement the functionality
- Define the implementation
- Fulfil business requirements
- Are product or vendor-aware
How to model building blocks in ArchiMate®?
ArchiMate provides a lot of concepts to model the enterprise architecture continuum, but has not specifically defined a concept for a building block.
The following article contains some examples on how to model building blocks in ArchiMate:
However no comprehensive solution or template was presented. Which is not a problem in itself, it just illustrates that modelling building blocks is possible with ArchiMate, but that different approaches can be used, depending on the context of your specific architecture.
Within the Dutch Ministry of Defence our team has defined the following template or metamodel for building blocks, both the ABB (Architecture Building Block) and the SBB (Solution Building Block). Additionally there is also an element called a Realisation Building Block (RBB) which contains the detailed solution as it is implemented within specific tooling. We will not explain that element further.
You can click on the image for an enlarged view.
Some remarks on the view:
- Elements with bold border are considered mandatory in a view based on this viewpoint
- Elements in a bold red border box: at least one element of the types included in the box are mandatory in a view based on this viewpoint
We decided to slightly deviate from the TOGAF specification in that we defined services to be part of the ABBs, and interfaces to be part of the SBBs. This is not a real deviation, because the term “interface” in the TOGAF definition does not correspond 1-1 to the term in ArchiMate.
- The service specifies the kind of questions I can ask the building block, and the format of the answer I receive (if applicable — a request to do something might not require an answer).
- The interface specifies the actual place where I can ask the question, for example a web service URL.
All elements in the building block definition can be neatly found in this metamodel:
- ABB
- Fundamental functionality and attributes: semantic, unambiguous, including security: The Architecture Requirement
- Interfaces: chosen set, supplied: Services (provided) on all layers
- Interoperability and relationship with other building blocks: Services (consumed) on all layers, which will be the services provided by the other building blocks
- Map to business/organisational entities and policies: the Role (ABB) and the Standard
- SBB
- Interfaces: the channels through which the ABB services can be accessed (both the provided and consumed interfaces)
Further work
Obviously the proposed viewpoint is not meant to be final and complete. But we found that for most of our needs the elements sufficiently describe the building block components in our landscape.
Some elements were omitted. We could for example have added processes on the different layers. One of the reasons they are not here is the guideline to model top-level processes in ArchiMate with Functions (see Procesconcepten in NORA – article in Dutch).
An important subject is the strategic alignment. For this please read a separate article, which explains the viewpoint Strategic Planning. That viewpoint deals with the alignment of Building Blocks with Capabilities and Value Streams. Partitioning should not just be with Building Blocks. Actually the start of partitioning should be capability-based, with the building blocks a realisation of the capabilities. In other words: the actual building block boundaries are derived from or based on capabilities. More about that in the article I mentioned.
Attributions
Thanks to my colleagues in the architecture team with the Dutch Ministry of Defence (MoD): Wouter Paul Trienekens, Niels Doeleman, Emiel van Meurs, Herman Meijer and others.
Related articles
Discover more from From the Mist
Subscribe to get the latest posts sent to your email.
