Posted by George Pang
In a previous blog by Marc Lankhorst, the value of reference architectures was highlighted, including the why and how. In this blog, I want to dive a little deeper, focusing on the ‘product’ that we (or some of us) are familiar with – the reference model, using ArchiMate as the language.
What are reference models?
First we take a step back and refer back to reference architectures, which are described as“standardized architectures that provide a frame of reference for a particular domain, sector or field of interest”.
What a reference model brings to the table is a very clear view (usually on-a-page) of the domain of interest – something that is reusable, and of course can be tweaked to suit the organization.
Examples of reference model types:
- Business Reference Model (or BRM)
- Technology Reference Model (or TRM)
- Information Reference Model (or IRM)
There are plenty of industry reference models out there for anyone to use, but the true power is taking these and transforming them into organization specific reference models – models that can prompt discussion, promote reuse, and provide traceability to other areas of architecture.
How do I represent this using ArchiMate?
Reference models often start their life as just a PowerPoint slide, a Visio diagram, or even just some filled cells in an Excel spreadsheet. This is great for communication, and gets the message across on a one-off basis.
When we are talking about Enterprise Architecture, very rarely are reference models used in isolation – we need to ‘link’ them up to other areas, so therefore need to use a standard to tie the reference model elements to – for example ArchiMate.
A question that comes up again and again is – “what concept should I use to represent the ‘blocks’ on this particular reference model?”
This is a topic area that can often take up days or even weeks of discussion – and arguing about it really just defeats the objective of using reference models as, well, reference – we need to agree on the representation, and then just use it consistently! To advise or answer that question, we really need to zoom in on the reference model in question. I will refer back to the three examples mentioned above.
The Business Reference Model
Essentially describing the “Business on-a-page”, we break down parent ‘areas’ into children, and then grandchildren, etc. It should describe “what the organization does”, and that usually provides a big clue.
For those who have at least a working knowledge of ArchiMate, some kind of ‘behavior’ is being described, and it should be ‘business-y’ in nature. This sounds like a Business Function!
Microsoft Industry Reference Architecture for Banking
The Technology Reference Model
Similar to the Business Reference Model, the TRM typically describes “Infrastructure on-a-page”, but again in a more functional perspective – it should not be about the fine-level of detail of server x, y and z, processors and that type of technical information.
Taking these points in mind, we are again looking at Infrastructure Services and Infrastructure Functions (i.e. behavior).
The Cloud Ecosystem Reference Model
The Information Reference Model
So far in the two examples above, we notice that ‘behavior’ concepts appear to be used – this is usually the case for a range of reference models. ‘Structural’ concepts usually tie closer to implementation after all.
The IRM is a description of the common ‘information’ available within the organization (something like the TM Forum SID is good inspiration). Putting it into perspective, the use of behavioral concepts does not really fit – thus we logically look at the ‘passive structure’ column (which describes ‘objects’ of some sort).
As the ArchiMate stalwarts are aware, there could be a decision to make on whether we use Business Objects or Data Objects to represent the elements of the IRM. This again is subject to interpretation, but generally something as high-level as ‘information’ may best sit as a Business Object.
The Information Framework (SID)
Conclusions
So there we have it. A few suggestions for working with Reference Models using ArchiMate.
You could potentially use a variety of ArchiMate concepts to represent elements in the models; but the most important points are to agree on a standard (and stick to it), be consistent in the use, and share the results!
One last conclusion focuses on presenting to “non-technical” stakeholders – remember, although the Architect may create reference models in a standardised ArchiMate notation (to create valid relationships to perform impact analysis etc), there is no reason why the output can’t be different (it could be an “inform” type viewpoint).
An Architecture Software can help greatly in documenting such models and tweaking to suit the audience visually, so check out BiZZdesign Enterprise Studio.
No comments:
Post a Comment