To adapt an old saying – standards, I love ’em, let’s have lots of them. ITIL, COBIT, IT4IT, ArchiMate, TOGAF, PRINCE2 or SABSA… the list goes on and on. This is isn’t just the standard’s owning bodies deliberately making things more complex – nor is it just down to competition between them. We have multiple standards because they cover different topics. But the reality is that the topics they cover affect one another – there is overlap. So one of the things that I’ve found myself being asked on a reasonably frequent basis is – how does ‘X’ map to ’Y’?
Now, recently I’ve seen a tendency in newer standards to explicitly consider how the standard maps to other standards in the space, and I personally suspect that we’ll be seeing tighter integration between different standards. But the fact remains that this is still the exception rather the norm at this point. So, in this post I’m going to consider a few points around mapping frameworks.
The first question in anything that is difficult is – why bother? Or, to express the question less provocatively, what benefit are you expecting to going by defining this mapping? There are several reasons why you might want to do this. The first, most simple use case is to use some kind of reference model within a formal model. For example, a bank might want to use the BIAN (Banking Industry Architecture Network) reference model directly in their architecture models, or a government entity might want to use the US government’s CRM (Consolidated Reference Model).
A second reason is when the two frameworks are used by two groups and there’s a wish to establish a common understanding and language between the different efforts. For example, mapping the elements of COBIT to TOGAF would enable a clearer understanding between governance and architecture.
A third reason might be model conversion. There can be various reasons why an organization might want to convert pre-existing models to a new standard that they have adopted and so translating the models will naturally require converting one framework to the other.
So how do we go about doing this? Unfortunately, there’s no hard and fast rules, but there are indicators of alignment.
The first step is to look for object types with similar names – but this by itself is not enough, as I’ll describe when I talk about pitfalls. It’s necessary to compare the descriptions of the two types of entity and look for commonalities as well. This can require a little sensitivity to how the same idea can be expressed in multiple ways.
The second technique that can aid in the first is to consider what metadata you would record against each entity type – if a particular attribute makes sense for one entity but not the other, this is an indication that it is not aligned or that the alignment is not perfect.
The third technique is to look at what relations are permissible to what other types – effectively, the context of the entity types within their respective modeling frameworks. Do they have broadly similar relations?
Now we need to talk about the pitfalls that we can encounter in doing this kind of mapping. The first pitfall is assuming that you do actually have to map two frameworks. Architects tend to think in terms of clarity and integration, so it’s a natural impulse to want the standards we use to join up. But it’s all too easy to try to fix something that isn’t broken. So – before charging in, ask whether any of the three use cases that we discussed earlier apply.
The second pitfall is more subtle, and that’s to assume that two concepts that have the same or similar names in two standards actually map perfectly. For example, TOGAF and ArchiMate both have a Goal object as part of their meta-model, but they don’t describe the same idea. In point of fact, the ArchiMate Goal object could be said to map to two different TOGAF object types, Goal and Objective.
Mapping frameworks can be a necessary, even unavoidable task at times – but it’s more art than science, and often the mapping can be more approximation that exact alignment. It’s important to define up front what benefits you hope to gain from doing so – and use this knowledge to inform the effort at each stage. Otherwise it risks becoming an interesting intellectual exercise, but one that gives no payoff.