Our favourite abstraction layers
Being able to break up a large and complex problem into various categories and layers helps us make sense of a world that is constantly changing. Creating several layers of abstraction helps us think about a problem at a less granular level then drill down into more and more detail as we need.
When we create catalogues of information around these abstraction levels, it allows us to understand the organisation and the systems within it at various depths of understanding and create diagrams showing viewpoints using the contents of these catalogues that help describe a problems or a solution.
In architecture we typically use three and in some cases four layers to describe even the largest organisations, systems or problem.
Contextual
At this level, we are at the maximum level of abstraction where we deal with the context of a problem.
For an enterprise architect, we may create content at this level to help stimulate discussion and ask question such as “do we need an accounting application” or “how does this new initiative fit within the organisation”.
Solution architects may use this level of abstraction as insight into the key problems or ideas being developed but they do not use it as requirements or other more rigorous inputs.
At this level of abstraction, we tend to forgo modelling rigour and allow more free form thinking to help develop concepts or stimulate discussion.
To be perfectly honest, many organisations do not recognise this as a part of the architectural landscape due to its lack of rigour while for others with only basic architectural capabilities, it is the only diagram that is created! But to not recognise these diagrams means that only people skilled in UML can create information is missing out on a wealth of talent and as such, we tend to embrace these diagrams but be aware of what they are and what they are useful for, nor should they replace the need for more rigorous analysis found in the lower abstraction levels.
Conceptual
At this level we begin to use UML modelling techniques to bring rigour to the high level design. Whether it is looking at the structure of people, the processes that are undertaken, the technology use or the information processed, we now begin to create viewpoints at the highest level that provide simple but accurate depictions of something in the organisation, whether that be a summary of what the whole organisation does or a depiction of a specific system, activity or in fact anything.
We typically create high level components and their relationships with this high level of abstraction. The power at this level is the simplicity it brings. If we start to create content and diagrams that offer very specific information then we probably need to drop to a lower level of abstraction.
Logical
This is my favourite level as it is close enough to the real, physical world but offers a level of simplification that is easy to create and understand.
It is also a level that brings together many of the architecture disciplines as the diagram is either at the heart of where they spend most of the time, or it is just one level of abstraction removed but links to the higher level conceptual layer, adding much more detail as well as the lower physical layer where it closely reflects the real-world.
When requirements for systems are created and maintained, it is often at this level where we focus.
Physical
This is the real world that offers little or no abstraction with these catalogues often held in other areas of the organisation. Such artefacts as operational procedures, user manuals, support processes and documents, technology diagrams. etc. are typically used or referenced for the day to day operation of any system.
