The previous blog discussed the essential BMM concepts that are of particular relevance and use to small and medium sized enterprises. This is sufficient to start modelling business motivation in an unstructured manner on paper or using common drawing tools. But if the goal is to create a persistent architecture artefact that can be share, enhanced, and used to inform other architecture activities, then we need to model in a more formal and structured manner. BMM itself is not a formal specification, so it must be mapped onto an existing modelling language.
In this blog I will discuss how Archimate can be used to define a BMM Metamodel. More specifically, Archimate 2.1 and the Motivation Extension. A brief description of how Archimate 3.0 affects this work is provided towards the end. The tool used is Archi, a great open source project.
Specialising the Archimate Motivation Extension
The first step is to create the BMM concepts in Archimate through specialisation of existing elements, illustrated in the following diagram.
BMM Means are modelled as Archimate Requirements. An Archimate Requirement is defined as an aspect of what a system (in its widest sense) does. The Mission, Strategy and Tactic concepts are all statements of action and can be viewed as high level requirements. Directives are also clearly a type of requirement or constraining requirement (I have deliberately chosen not to use Archimate Constraint).
BMM Ends are modelled as Archimate Goals. An Archimate Goal is defined as an end state so this is a pretty straightforward interpretation.
BMM Influencer is modelled as an Archimate Driver. An Archimate Driver is defined as something that drives change in an enterprise. Again, this is a pretty uncontroversial mapping.
Lastly BMM Assessment and BMM Impact are modelled as an Archimate Assessment. An Archimate Assessment is defined as the outcome of an analysis of a driver. They are both types of assessment, so again I feel that the mapping is appropriate.
Defining the BMM Metamodel
Now we have the BMM concepts modelled as Archimate elements, we can now define the BMM Metamodel using Archimate relationships. I have chosen not to specialise the relationships so that they map to the BMM relationships – the BMM relationships are a bit too specific and wordy for this . Instead, I am using standard Archimate relationships and I feel that these are sufficient for the purpose. The following diagram shows the BMM Metamodel in Archimate.
The relationship shown between BMM Influencer and BMM Assessment is an Association. Archimate is strict about the relationships that can be drawn between elements. The only relationships allowed between an Archimate Driver and an Archimate Assessment are Association and Influences. In BMM the BMM Influencer is neutral and it is the BMM Assessment that determines the effect on Means, so Influences did not feel like an appropriate relationship between these two concepts. Association was therefore selected as the most appropriate relationship.
A similar argument can be followed for using Association between BMM Assessment and BMM Impact. The relationships available are Association, Influences, Aggregation, Composition and Specialisation. Compositional relationships do not feel right as we are not creating a meaningful order or structure. Specialisation is certainly not right and neither is Influences. We are left with Association again, and I think this is the right relationship. We are simple associating related statements.
The relationship from BMM Assessment to BMM Directive is Influences, and this is certainly correct in terms of both BMM and Archimate. Similarly, the relationship from BMM Directive to both BMM Tactic and BMM Strategy is Influences.
Aggregation has been used to define the organisation of BMM Mission, BMM Strategy, and BMM Tactic as well as BMM Vision, BMM Goal, and BMM Objective. Aggregation was used over Composition because it is more of a group of common elements rather than a strict whole-part relationship. For example, a BMM Tactic may relate to multiple BMM Strategies.
Lastly, Realisation is used to connect BMM Means concepts to BMM Ends concepts. This is straightforward and is aligned with BMM and Archimate – and action will realise a goal.
In this blog I have demonstrated how the core BMM concepts discussed previously can be mapped onto a common modelling language, Archimate, to create a BMM Metamodel that can now be used to capture business motivation in a formal and structured manner.
By using Archimate we now have access to a wide range of tools for modelling. We can also map the motivation modelling directly to other enterprise architecture work, such as roadmapping. The next blogs will take a look at how to use the Archimate based BMM Metamodel and how to use it in the definition of roadmaps.
Appendix – Archimate 3.0
Archimate 3.0 was released in mid 2016 and it has introduced two new elements that have a direct bearing on this work. The new elements are:
Outcome: This is defined as and end result that has been achieved and is supposed to be measurable. This can be used instead of Goal to represent BMM Objective.
Course of Action: This is defined as an approach or plan to achieve a goal and maps directly to the BMM concept of the same name. It can be specialised for BMM Strategy and BMM Tactic rather than using the Archimate Requirement.
John Owen, Principal Architect at Cyma Limited
Email: email@example.com Twitter: @jiowen and @cymaltd
This work is licensed under a Creative Commons Attribution 4.0 International License.