Architecture Levels of Abstraction and Detail: How to Make Those Work For You
One of the most popular topics to debate amongst architects is: what is the proper level of abstraction needed to be applied when creating architectures? Although always a lengthy debate, I don’t ever recall reaching a conclusion that was satisfactory to me. Even worse, at times, my architectural work was discredited by people, claiming “its level of abstraction was too high to be useful.”
For a long time I have been looking for a way to tackle this challenge and the serious waste of time it causes, keeping architects from doing real work.
Recently I found some answers and I hope others can benefit from them as much as I do:
- People tend to call something ‘abstract’ when a certain viewpoint confuses them. In fact they express that they feel uncomfortable with a viewpoint presented when it does not match with their perceptions of reality that they are used to.
- When talking about functionality and quality, there are no different levels of abstraction, only different levels of detail. For example, ‘driving’ remains ‘driving’, no matter if you narrow down the specification of the kind of driving by pointing towards the use of a car or a bicycle.
- When talking about construction, ‘abstraction’ is a term that is very well applicable. To refer back to the example of the bike: The concept of a bicycle is two wheels and a frame. This concept is so abstract that it applies to almost all actual bikes, including the one stored in my own shed. On the other end of the spectrum, the latter, a physical instance of a bike, is so concrete that I can take it at will to drive it. Actually the design and creation process itself is a process from moving from a very abstract level to a very concrete one, including all intermediate steps.
Nice observations, you might think, but how can they actually ‘work for us’ in our architecture practice? Here are some suggestions that ‘do the trick’ for me:
- When starting the architecture process, often it is a good idea to start by defining functionality and quality. Functional entities are very stable and can be communicated with almost all stakeholders, because they are technology agnostic. In most cases, end-users are not interested in technology and construction, but in the functionality they will be offered. This however does not automatically mean that end-users are able to point out and define functionality very well by themselves. On the contrary, they find it hard to articulate and express their needs in a structured manner. And that is exactly where one of the jobs of the architect comes in: Determination of involved functionality by means of a methodical and structured questions and answers exercise. This way, requirements can be turned into specifications of the desired solutions.
- Every solution that is brought forth in the real world, is created by construction. Every construction has a structure. In its most abstract form, this structure is (arche)typical for all instances of this kind. To my surprise, the highest level of abstraction can be found when looking at the relations that exist between functions that together provide a service. An example of a generic pattern that describes the basic correlations between functions that make up authentication and authorization (using Archimate):One abstraction level lower, also technical components can be described in a generic way. For example an access list on a file system (that realizes ‘Permission Register’ functionality), has a limited set of permissions that it can hold typically: Read, Write, Execute, Delete and Rename. It is very useful to have a good overview on existing archetypes, because they limit the design space, enable a structured approach and as a result, dramatically shorten the design time.
- Architects should be as specific about functionality as is necessary to express stakeholder’s requirements. Very often this exercise runs from coarse to fine in an iterative process, where the level of detail differs per function, depending on what the architect and his stakeholders want to express. When it comes down to the construction, architects should limit themselves to the first top levels of abstraction: a) relations between functions and b) guidelines that are used by the technical designer in the transformation of a generic technical design into a specific technical design. However, the way these guidelines are expressed should match with the ‘comfort zone’ of the designer, so there are occasions where guidelines are verbalized on a lower level of abstraction than actually desired. For example, instead of specifying the permissions, an architect might want to specify NTFS as the file system that should be used, avoiding a theoretical discussion on file system permissions.
My conclusion is that in its essence, ‘abstract is good’, because knowing the fundamental structure of things helps us in our design process tremendously. In my opinion, for an architect it is mandatory to start from a functional view. However, people may perceive talking about functionality as very abstract, because they are not used to this kind of viewpoint. Although there is nothing abstract about functions, it might help to translate functional models into ‘artist impressions’. These artist impressions provide a constructional view on an abstraction level that appeals to people because they match with their ‘comfort zone’. That is the way to play with levels of abstraction and detail. In other words, making sense of this is an art; an art that is mastered by every good architect.
As part of the OIAm infrastructure architecture method, we have identified a number of generic functions and patterns that are used when a requirements definition exercise is carried out. Stakeholder concerns are plotted on these patterns to create applied patterns that hold specifications of the desired solutions. This process is depicted below.
During this process, first the desired functionality is determined, then the required quality is being identified and as a last step further specifications are being collected and translated into guidelines for the technical design phase.
I wish you the best in your architecture endeavors.
