Questions are commonly asked regarding Reference Models - Peter Harrad discusses these questions and the answers in this blog article.
The most common question I get on reference models (and the answer)
To paraphrase an old saying, reference models, I love ‘em. Let’s have lots of them. One thing that the enterprise modeling arena is not short of is reference models. You have domain-specific ones such as ITIL, COBIT and SCOR. You have industry-specific ones such as Frameworx for Telcos, the CRM from the US Federal government, the Municipal Reference Model from Canada and the various APQC variants.
Now, there are a couple of problems with the reference models that are out there. The most obvious is that each of them has been designed in a silo; there’s generally little alignment between them (if only I had a dollar for every time I’ve been asked how TOGAF and ITIL line up with each other…). This is pretty unavoidable, from my own experience it’s hard enough getting agreement on one standard without trying to get different standard’s bodies to co-ordinate.
Another issue is how a standard like COBIT maps to a modeling standard such as ArchiMate. Perhaps the various standards bodies will do some work on this in the future.
But, there’s another issue with these reference models, something that I get asked about even more than how TOGAF and ITIL interact.
Specifically, “How would we go about using this?” Or, to put it another way, any organization already has processes, documented or not. They’ll also have some form of IT. And they probably have some way to approve IT spend. So, how to make use of the APQC, or ITIL, or COBIT reference models?
The obvious answer is, borrow from the reference model to inspire and amend what you have now. All well and good, but this answer lacks details on how to make use of a given reference model. So for the rest of this post I’m going to outline one approach on how to make use of a reference model (or reference models).
The basic issue that we face is that any organization that looks to modify its processes based on a reference model is in the stereotypical situation of reassembling a 747 in flight. For example, the APQC variants each list hundreds of processes spread across 12 or 13 top-level areas. SCOR lists hundreds of processes, skills and best practices. So the issue becomes one of ‘how can we gradually adopt a reference model?’
The trick here is to accept that this is not going to happen quickly, and to track the gradual adoption of the reference model.
For any given item (a process, a business service, it doesn’t matter) that is a part of a reference model, one of four things might be true:
So the basic concept is to record this status as an attribute against each component of the reference model. It’s best to give each of the above statuses (or whichever statuses that you adopt) a name, simply for brevity’s sake.
Now I’m assuming that the organization is using some kind of modeling tool that manages objects in some way, in particular one that lets you record metadata against them. If this is not the case, then tracking attributes against items via a spreadsheet also works.
Say you were adopting a set of roles, some part of a RACI matrix. Then you might record such an attribute against each role. If you were adopting the data model of the Frameworx standard (known as SID, Shared Information/Data-Model), you would record such an attribute against each data item.
So to return to the ‘jumbo jet in flight’ analogy, you’d be which of each part has been upgraded/replaced.
I’ll make one last observation before I close. As stated before, I’ve tacitly assumed that the organization is using some kind of modeling tool to track the objects that form part of the reference model. If the tool allows for some kind of data-driven annotation, the approach given above opens the door to visual dashboards allowing executives to track the long progress of the analysis over time. For example, I’ve seen the progress of analysis of an APQC model tracked using Visio data graphics.
The reference models that are out there are all very valuable; they embody hundreds of years’ worth of experience across their contributors. But often the scale of them can seem intimidating. In this article, I’ve outlined a way to break the adoption of one of these reference models into ingestible chunks.