The Problem
I am frequently asked what is becoming for me a classic question, “How far should I go with the detail of my model? When do you stop?”
In general, I would say the more information you can capture, the better. We do need to be able to “see the wood for the trees”, though. We don’t want to get lost in the detail – both from a point of view of the sheer volume of information and also from the perspective of capturing things that are not currently interesting.
Many models and frameworks tend to stay at quite a high level. This can be OK for some scenarios – e.g. high level design or a Powerpoint. However, detailed decision support enabled by information from the architecture model requires the detail. If this is not available then all too often, when the details come to light, they break the model.
When interacting with other parts of the organisation, architects who gloss over the details, can often be perceived as ‘arm wavers’ and can quickly lose credibility – even though the ideas themselves may be sound.
In the increasingly technologically educated world, you ignore the details at your peril. The very systems that we have to manage, as Application and Technology Architects, are becoming more and more complex. The Cloud, SaaS can provide significant benefits but the services that they provide still need to be managed as part of the Enterprise Architecture. The ‘details’ are still there but now we’re not directly in control of them. We cannot just ignore them because we have a service provider that manages how that service is delivered.
Really, we need to be able to ‘roll up’ the detail when required. Also it would be great to be able to easily come back to elements of the architecture that we didn’t initially capture to any great depth, and enrich the detail later, when we have it.
I’ve used some technology examples above, but the need to recognise the details exists just as much in Business Architecture. One of the big issues here is that we cannot ignore IT when looking at the Business Architecture. It is the reality of today that nearly every process in the organisation is supported by IT in some way.
A Way Forward
So, how can we manage the details without suffering information overload or finding ourselves in a modelling equivalent of painting the Forth Bridge?
Generally, details are missed because when we uncover them, we have nowhere relevant to capture them. So they are ignored or forgotten. If we could capture all the relevant details as we find them – and model them so that everything we know about some aspect of the enterprise can be related as appropriate to others – this would really add to the organisation’s ‘knowledge base’.
Now, modelling of this nature requires a detailed ‘language’ if we are to be able to reflect the nuances of things at the detailed level. However, this language must enable us to “black box” elements in the model – to save us from getting lost in the detail and deal with them at the right level of granularity for the activity that we’re working on right now.
The important thing about not ignoring the details is that our model needs to reflect the real world if we are to be able to make effective decisions from the knowledge we have captured. This might mean that the modelling activity or the model itself requires some complexity. We cannot hide from modelling complex things when they are truly complex in the real world.
The ability to capture the required details yet roll elements up as “black boxes” is one of the key drivers behind much of the development of the Essential Meta-Model. We started with a simple set of core concepts and introduced additional concepts incrementally to manage the detail as we found we needed it.
Don’t get lost in the details of your enterprise. Embrace them and manage them locally, in their relevant context (don’t worry about the servers if you’re looking at how your applications support your business processes!). Understand how these contexts, which are the layers and views of the Enterprise Architecture, fit together and the details will take care of themselves.