This page is published under the terms of the licence summarized in the footnote.
Architecture
as an abstract description
Abstraction
in architecture frameworks
Generalisation
– Specialisation
Schema
for architecture description artefacts
Abstraction pervades our thoughts and our expressions of them. We all use abstraction every day. And we entangle different kinds of abstraction without thinking about them. That’s OK. But abstraction is a tool of the architecture trade. So architects should understand the different kinds of abstraction - well enough to monitor and control the use of abstraction. And guidance for architects must be clear about levels of abstraction. Authors should not leave their readers uncertain which kind of abstraction they are talking about, and should not unconsciously confuse the different kinds.
|
Abstraction |
1: A process of composition, generalisation or idealisation by which shorter and more general descriptions are produced from longer, more detailed and more specific descriptions. Or 2: A component or process that is made by the process at definition 1. |
Behind the three kinds of abstraction mentioned in this definition lurks a fourth more general kind of abstraction - omission. This paper defines compares and contrasts these four kinds of abstraction in a way that is intended to help architects use them systematically. A reader writes:
“I have a feeling that you have … clarified some important presentational concepts, which probably no-one has ever clarified with that precision before. I must admit to some question whether you allow your readers the best chance of catching your thought first time.”
Sorry, this is my best shot after years of shooting at this target. So better not expect to understand everything on first read through. The concepts herein are further illustrated in related papers. After you have explored those, I hope you will return to find this paper is better organised than you found it first.
Architects produce abstract descriptions of real working systems. A working system is a complete set of elementary parts, made of physical materials, many of them uniquely configured to work in that system. Any description of a system must be relatively incomplete, coarse-grained and idealised. The description will be documented using some generic or even universal terms and structures. In short, architecture descriptions are abstractions. And note that different kinds of abstraction will result in different descriptions of a given system.
Abstraction and its opposite (concretion or elaboration) are essential tools in creating and using architectures. Architects use abstraction to describe existing/baseline systems and to describe new/target systems. Architects and designers proceed by elaborating abstract descriptions until those descriptions are sufficient for builders to construct the concrete systems. Abstraction underpins the way architectures are described using frameworks like those of TOGAF and Zachman. In short, every architect has to understand and manipulate abstractions.
Of course, the architecture process is more than description. It involves knowing the given requirements and constraints, knowing design patterns you can apply, understanding the trade offs between different design options and making decisions. (Those are addressed in our reference model and training courses.) But you can’t follow the architecture process if you can’t manipulate architecture descriptions. So this and a few closely-related papers are about description.
The table below shows four scales in which abstraction works from the bottom up. So for example, omission makes a description increasingly sketchy until it become vacuous – has only a name or title – is purely nominal.
|
Abstraction |
Omission |
Composition |
Generalisation |
Idealisation |
|
|
Nominal |
Coarse-grained composite |
Universal |
Concept |
|
|
Sketchy |
Mid-grained composite |
Fairly generic |
Logical model |
|
|
Elaborate |
Fine-grained composite |
Fairly specific |
Physical model |
|
|
Complete |
Elementary part |
Uniquely configured |
Physical material |
|
Concretion |
Elaboration |
Decomposition |
Specialisation |
Realisation |
BTW, uniquely configured means tailored, customised or organised in a way that is useful in just one specific context or place.
Given a description, you might find the table above helps you assess or explain its level of abstraction. There are other ways to present the same four dimensions. For example, you can swap around the rows and columns of the table:
|
Abstract |
Scale |
Concrete |
|
Nominal |
Omission ßà Elaboration |
Complete |
|
Coarse-grained composite |
Composition ßà Decomposition |
Elementary part |
|
Universal |
Generalisation ßà Specialisation |
Uniquely Configured |
|
Concept |
Idealisation ßà Realisation |
Physical Material |
Architecture frameworks divide up the architecture space in many different ways. The Zachman Framework and TOGAF present several dimensions of architecture definition, such as:
The last four dimensions above are the four kinds of abstraction discussed in this paper. And it is interesting to note that TOGAF uses all four kinds of abstraction
|
In TOGAF’s
Architecture Development Method |
In TOGAF’s
Enterprise Continuum |
||
|
Abstraction by
Composition (Level of
Detail) |
Abstraction by
Omission (Architecture
Domain) |
Abstraction by
Idealisation |
Abstraction by
Generalisation |
|
High level |
Business |
Ideal |
Generic |
|
Strategic |
Business |
Requirements |
Foundation |
|
x Segments |
Data |
Architecture building blocks |
Common System |
|
x * y Capabilities |
Applications |
Solution building blocks |
Industry |
|
|
Technologies |
Deployed Solutions |
Organisation |
|
Low level |
Technology |
Real |
Specific |
It may help to start by understanding the four kinds of abstraction have overlapping but somewhat different purposes. This table shows some typical purposes.
|
Omission |
Aids communication by |
Hiding details |
Elaboration |
Makes useable by |
Adding details |
|
Composition |
Aids management by |
Hiding complexity |
Decomposition |
Makes work by |
Division of labour |
|
Generalisation |
Makes reusable in several places |
Hiding differences |
Specialisation |
Makes fit one context by |
Extending with features |
|
Idealisation |
Makes portable by |
Hiding physical features |
Realisation |
Makes concrete in a place by |
Adding instantiation details |
The four kinds of abstraction are themselves related in a class hierarchy:
The following sections explore each kind of abstraction in turn.
|
Omission |
Aid communication by |
Creating a digest or summary of a more elaboration description |
|
Elaboration |
Make useable by |
Adding information missing from a digest or summary view |
Composition, generalisation and idealisation all have the effect of hiding details. And when hiding details you might find yourself composing, generalising or idealising at the same time.
However it is possible to omit details without doing any other kind of abstraction. You can present a view, a slice of a description that focuses on one perspective and hides others. This is the idea behind views and view points, which are defined and discussed in the paper “Omission and view points” at ref 1.
|
Composition |
Make things manageable by |
1: the assembly of parts into a whole; 2: the organisation of units under a manager or owner; 3: the encapsulation of content inside a shell. The result is some kind of aggregate or composite component or process. A composite contains its components in some sense. A description made with reference to a whole, manager or shell is more abstract than one that refers to its parts, units or content. |
|
Decomposition |
Make things work by |
Division of one composite or aggregate component or process into several components or processes. |
A composite contains its components in some sense. For example:
However, the concept of containment does blur into concepts of ownership, management, or even gravitational pull. For example:
You could reasonably say that composition is a subtype of association, a relatively stable or a strong kind of association. That is a side issue here, where the aim is to focus on how people abstract from the small to the large, from the minor to the major, from the parts to the whole, from the lower level to the higher level.
Architects can and do describe one composite using different, clashing, decomposition structures. Often, there is a more physical structure and more logical structure. For example,
Composition or decomposition can be done repeatedly to create a multi-level hierarchical structure.
· For example: a city contains areas, which contain blocks, which contain buildings, which contain rooms. Here, a composite has a location, and its parts are co-located.
A city is a concrete composition of concrete things. There are more abstraction compositions.
· A somewhat abstract composition of concrete things. For example: an enterprise contains divisions, which contain departments, which contain employees. Here, a composite might or might not be located in one place. If not, the owner or manager should know where the parts are.
· A very abstract composition of ideas about concrete things. For example, the Linnaean classification of living things. The composites are abstract, but the things they describe have a concrete existence. The classification itself is locatable, but the elements are dispersed.
· A purely abstract composition of nothing but descriptions. For example, a dictionary contains entries, which contain words and their definitions. The elements are real in the sense that they are written down, owned and managed, but they are only descriptions.
|
Generalisation |
Enables reuse by |
Abstraction from several specific components or processes into a more generic component or process. The generalisation contains only the common features of its specialisations. |
|
Specialisation |
Enables use in one place by |
The elaboration of a general component or process into a more specific component or process. A specialisation contains its generalisation in some sense. |
An instance of a specialisation is at the same time an instance of all generalisations above it. A specialisation contains its generalisation in some sense. So the full description of a specialisation must be longer than the description of its generalisation. The specialised concept inherits from or extends the generalised concept.
For example, the two subtypes below extend the definition of their super type:
Similarly, the two subtypes below extend the definition of their super type:
A generalisation is often an abstract group of things, rather than a concrete composite. There may be instances of the generalisation in the real world; but you cannot address them as a group, they are not co-located, they have no manager, no owner, no physical shell around them.
Generalisation or specialisation
can be done repeatedly to create a multi-level hierarchical structure. For
example: Consider the Linnaean classification of living things.
This is an abstract composition hierarchy. A higher category in the classification is a composite of
lower categories. But more importantly, every category is a generalisation; it
defines those properties that are shared by all the specific types below it.
Its main purpose is to generalise.
|
Taxonomic group |
Particular general types |
|
|
Kingdom |
Animalia |
|
|
Phylum |
Chordata |
Mollusca |
|
Class |
Mammalia |
Gastropoda |
|
Order |
Primates |
Pulmonata |
|
Family |
Hominidae |
Arionidae |
|
Genus |
Homo |
… |
|
Species |
Homo sapiens |
Black slug |
Generalization is fundamental to the highest level of enterprise architecture, where enterprise architects define:
Generalization in enterprise architecture can be overdone. It can yield vacuous abstractions - structures that are highly reusable yet of little value in each place they are used. The more general the structure, the less helpful in designing a specific solution, the more work is left to the designers. Also, in IT architecture, generalisation is often the enemy of performance. So use it with caution.
The concept of a generic type is
also fundamental at the lowest level of data processing system design, where
software architects define:
Generalization in detailed software design
can also be overdone.
(See the paper “Generalisation” at ref 1. for notes on sets and types, the evolution of types, the limitations of inheritance.)
|
Idealisation |
Makes portable by |
Abstraction from one specific component or process into a higher-level description or requirement statement. A kind of generalization. It can be viewed as a kind of reverse engineering. It creates a description that can be communicated as the requirement for the real thing. |
|
Realisation |
Makes concrete by |
Leading to the instantiation of physical materials. It can be viewed as forward engineering, as a progression from requirement to solution. |
Idealisation could perhaps be called dematerialisation, or spiritualisation, or conceptualisation. Realisation could also be called instantiation, materialisation or reification.
The right-hand column of the table
below shows what are probably the most well known and popular labels for levels
in an idealisation hierarchy.
|
Abstraction |
Omission |
Composition |
Generalisation |
Idealisation |
|
|
Nominal |
Coarse-grained composite |
Universal |
Conceptual Model |
|
|
Sketchy |
Mid-grained composite |
Fairly generic |
Logical Model |
|
|
Elaborate |
Fine-grained composite |
Fairly specific |
Physical Model |
|
|
Complete |
Elementary part |
Uniquely configured |
Physical Material |
|
Concretion |
Elaboration |
Decomposition |
Specialisation |
Realisation |
The following three examples of idealisation are explored further in the paper “Schemas for architecture description”.
Idealisation makes a description more generic – implementable in different ways on different platforms. However, the goal is not necessarily to reuse the generalisation in many different places at once. Sometimes the goal is technology-neutrality and portability - to help the owner transport the idealised description/requirement to a new solution, a new technical environment. Perhaps more often, the goal is simply to abstract, to shorten, to simplify – to omit details for ease of communicating an architecture description, or the requirement for a system.
For further discussion of idealisation see the paper “Schemas for architecture description” at ref 1.
Architects produce many levels of description. They use several kinds of abstraction in one description. Architects can and do use abstraction consciously to manipulate their descriptions.
You can easily make a schema for architecture descriptions artefacts by mapping one kind of abstraction to another. Others have done this already. For example, TOGAF’s Enterprise Continuum maps two levels of Idealisation to four levels of Generalisation. The dimensions of the Enterprise Continuum are shown in table below, though TOGAF gives different names to the rows and columns.
|
Generalisation Idealisation |
Universal |
Fairly generic |
Fairly specific |
Uniquely
configured |
|
Conceptual/logical model |
|
|
|
|
|
Physical model |
|
|
|
|
Given a schema of this kind, architects can assign each architecture specification artefact to a cell of the schema, then use the schema as an index to find artefacts in an architecture repository. For further discussion see the paper “Schemas for architecture description” at ref 1.
Note that an abstraction schema like the one above is used for description of things, not the things themselves.
· The enterprise architect records the specifications of subsystems in some kind of architecture repository. These architectural specifications are often arranged in idealisation layers (conceptual, logical and physical) but all these layers are remote from the operational system.
· The infrastructure architect records the physical instances of subsystems (the ones specified by the enterprise architect) in some kind of IT configuration management database.
· Systems management tools are used to monitor and control the material instances of subsystems that are deployed around the physical infrastructure.
The term architecture is used for descriptions at the higher levels of idealisation. The term configuration is often used at lower levels of realisation – closer to the implemented systems. The running system is usually called a system.
Composition and generalisation are opposites in some ways. A composite contains the components below it. A specialisation contains the generalisation(s) above it. Yet composition and generalisation are also used together, and easily confused.
Example 1: people misinterpret the
levels of idealisation in the Zachman framework as levels of composition. For
further discussion see ref. 2.
Example 2: two very experienced
consultants in enterprise architecture frameworks (one worked with DoDAF, the
other worked with FEAF) were discussing the nature of enterprise architecture:
·
One said
that enterprise architecture is essentially a) a baseline architecture and b)
broad and shallow.
·
The other
said that enterprise architecture provides general guidance to solutions
architects by way of goals/objectives, principles/policies, standards and
preferences.
The two consultants thought they
were in agreement, and yet:
·
The first
spoke of a description of the baseline/current state, while the
second spoke of guidance for steering the target/future state.
·
The first
implied enterprise architecture is an abstraction by composition into
coarse-grained components, while the second implied abstraction by generalisation
of shared principles and standards.
I hope this paper will help architects to use abstraction in a more systematic way. You may find you need to read the other related papers at ref 1 to get a deeper understanding.
Composition and decomposition are ubiquitous in enterprise and IT architecture. Architecture methods feature recursive decomposition structures of goals, organisations, functions and processes.
Some propose scaling up software architecture to enterprise architecture. At the bottom level of design, software engineers make facades to composite structures, use SOA and UML. So, one sees attempts to teach the highest levels of business system design using exactly the same tools. In practice, the things at the top of a composition hierarchy are often so different from the things at the bottom that they need to be given different names and treated differently. See the papers “Composition” and “Business is not software” at ref 1.
City planning has cultural resonances for the French (surely
due to Haussmann’s renovation of
Curiously, it appears to me that solution architects, working at a level between enterprise architects and software architects, may find generalisation-specialisation less useful. Solution architecture can be largely about composition and decomposition.
Abstraction is used as a noun and a verb; it can be a thing or a process. When you hide parts, units or content, then the whole, manager or shell can be seen as an abstraction. When you divide a component into parts, then this decomposition process is a kind of elaboration. Does this mean the reverse - composition - is necessarily abstraction?
A reader writes: “How can composition be regarded as abstraction if the composite contains all its parts, and the composite itself?”
Good question. When you create a structure from the bottom-up, you must add a new component to contain existing components, then add a relationship between each part and the new composite. So composition (like decomposition) can be viewed as a kind of elaboration. That does seem paradoxical. However, this paper is not about completing a software design, it is about making more abstract descriptions.
Composition leads to abstraction in descriptions when you
name or describe only the whole, manager or shell.
People with a background in software architecture tend to feel uncomfortable about such arbitrary hiding of detail, because the full structure still exists, and we cannot make a working system without completing the structure down to the level of elementary parts which are executable. But even software architects can turn a composition into an abstraction by realising a composite as a shell or façade that does not include its parts, but delegates work to them instead.
If you realise an ideal architecture, then you turn it into a real system, by definition. But you can realise a composite or generic component as a real system, without making it fine-grained or specific.
You can realise a high level composite component or process as a shell – a thin façade that divides work and delegates it to several lower level components or processes behind the scenes. The leader of an organisation unit may act as kind of façade to the unit, and so represent that unit to the outside world.
|
Organisation unit |
Unit leader: acts as a façade to the unit |
|
Army |
General |
|
Corps |
Lieutenant general |
|
Division |
Major general |
|
Brigade |
Brigadier |
|
Regiment or Group |
Colonel |
|
Battalion |
Lieutenant colonel |
|
Company or Squadron |
Captain or Major |
|
Platoon or Troop |
Warrant officer or 1st/2nd lieutenant |
|
Section or patrol |
Corporal to staff sergeant |
You can realise a generic component or process in material form, perhaps as subroutine, perhaps as a base class, perhaps as a shallow façade that delegates work to one of several different specialised components or processes behind the scenes.
And note that a shallow façade component may be at once an abstraction by composition and generalisation.
The complexity of a system is usually measured in terms of configuration complexity. An architecture description is an abstraction from a system. So architectural complexity can only be measured at that level of abstraction. That level of abstraction is very much a choice made by the architect. An architect deliberately suppresses the details of any component or platform that can be taken for granted, no matter how much complexity there is in the structure of that component or platform. See also footnote on configuration complexity in “Agile Change Management” at ref. 1.
References
Ref 1: other papers at http://avancier.co.uk
Ref 2: “Why not the Zachman
Framework” in the Library at http://avancier.co.uk
Footnote: Creative Commons Attribution-No Derivative Works Licence 2.0
Attribution: You may copy, distribute and display this copyrighted work
only if you clearly credit “Avancier Limited: http://avancier.co.uk” before the start and
include this footnote at the end.
No Derivative Works: You may copy, distribute, display only complete and verbatim
copies of this page, not derivative works based upon it.
For more information about the
licence, see http://creativecommons.org