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 lengthy, I cannot recall an ending of this type of debate that was satisfactory to me. Even worse, at times, my architectural work was disqualified by people, claiming its level of abstraction was too high to be useful. For a long time I have been looking for an answer to tackle this challenge and the serious waste of time it causes, keeping architects from real work.
Recently I found some answers and hopefully others can benefit from those, 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 can be depicted by two wheels and a frame. This concept is so abstract that it applies to almost all actual bikes, including the one is stored in my own shed. On the other end of the spectrum, the latter, a physical instance of 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 mean automatically 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 to 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 being created by constructing something. 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 needed to express stakeholders 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 then 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 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, to make sense 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. For more information on this step, see the global OIAm whitepaper. Soon a special whitepaper on requirements management and OIAm will be released.
I wish you the best in your architecture endeavors, learn more about how BiZZdesign can assist you and your team with your architecture initiatives by clicking on this link.