Dynamic relationships in ArchiMate

ArchiMate is especially powerful because of its rich set of relationship types. These relationships are grouped/classified in 4 sets:

1. Structural
2. Dependency
3. Dynamic
4. Other (called "Special" by me)

The basic pattern in ArchiMate modelling is:

1. You identify the main components in your architecture landscape. Those (as a rule) will be Active Structures. They will mostly be Internal Active structures (such as Business Actors or Devices), and networks (neither external or internal).
2. You detail these main components or nodes using structural relationships.
3. You identify the cohesion between these components by determining how they are connected using dependency relationships (mainly Serving).

If you have done this properly, the result should be a graph of Active Structures connected with each other through Services/Interfaces. This ensures the primary architecture principle of high cohesion-loose coupling. Great work!

However!

We also have dynamic relationships. They also create relationships between elements. An example:

The "Accept Claim" process is performed by a Role: Customer Service Representative. That process triggers (a dynamic relationship) the Assign Claim process.

However, that process is performed by a different internal active structure: High-Risk Claims Adjudication.

I have an issue with this model. What is it?

Well, the issue is the direct triggering of the behaviour of another entity, bypassing the entire premise of ArchiMate, namely the encapsulation of behaviour with an external layer.

As you may remember, the behaviour of an Active Structure in ArchiMate is Internal, that is: not available directly from outside (= other entities besides the one that performs this behaviour). If you want that internal behaviour of another entity to be of service to you, the honourable way to do that would be to utilise the published external behaviours, also called Services:

This is the honourable way to trigger a behaviour:

1. I need to do something: Accept Claim
2. When that is done, I would like someone else to "take over": I request that by invoking a service called Assign Claim. Handover!
3. The assign claim service is realised by the Assign Claim business process of that other (internal active structure, so effectively invisible to me: loose coupling)

This is why I always explain that: no I do not have a fundamental issue with using dynamic relations, but please keep in mind that in a proper architecture those relations are best seen as a kind of shorthand:

The same applies to the Flow relationship: it is very impolite to directly flow into someone else's (internal) behaviour, but it can be useful to show the shorthand notation.

Especially for implementers (solution architects or developers) working with these ArchiMate models as input, this is an important aspect to be aware of.

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:

• 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

TOGAF 10^th Edition: TOGAF Standard — Architecture Content

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:

1. 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
2. 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:

• Using ArchiMate to Visualize the TOGAF Enterprise Continuum

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

• The ArchiMate metamodel
• Business-centred ArchiMate
• The Business-IT Fallacy
• Round instead of square
• Kantelen met enterprise architectuur

Introduction

This article explains an ArchiMate® viewpoint, the Strategic Planning viewpoint which has been made by our team within the Dutch Ministry of Defence. We have found this viewpoint to be particularly effective in partitioning the transformation effort (which as you might understand is substantial within the context of Defence!).

Strategic alignment is often overlooked. It usually focusses on strategic views such as a Capability Map, but often leaves it at that. We then miss how these strategic landscapes are actually trickling down into the actual solutions.

Or we dive into possible solutions, usually taking too little or no effort to really understand what the problem is and what approach to take.

Capability-based planning

A central tenet of our approach is not specific for Defence, but becoming quite the standard in business architecture. As you may recall, TOGAF specifies a stratified approach to modelling regarding the content of the architecture repository, specifically the part called the Architecture Landscape. The architecture repository of the Dutch Ministry of Defence and most of the enterprise repositories I have worked with in my career have a similar structure:

1. Strategic architectures
   Architectural descriptions for organisation-wide things, expecting to be generic to any part of the enterprise. One of the descriptions is the Capability Map.
2. Segment architectures
   Descriptions specific for the different main components of the enterprise. An example segment within the MoD would be the Navy. The term "domain" can be viewed as a synonym.
3. Capability architectures
   This is where we describe the various capabilities (within the MoD termed "enterprise capabilities" to distinguish them from the military and NATO capabilities, which we decided to label "operational capabilities") and how they are realised by services and underlying business, software and technology. This approach partitions the solutions landscape according to the capabilities defined in the Capability Map mentioned above.