One of the key characteristics of architecture is looking at the ‘big picture’, but a major challenge is that we can’t present the big picture on one great big piece of paper – it has to fit on a single sheet or model. In order to do that, we have to come up with new concepts that summarize the overall picture into a small number of elements and relationships. We can do this through a variety of techniques, like divide-and-conquer, categorization, generalization, and so on.
The principles of abstraction are aimed at just these problems. This Column will provide an introduction to abstraction and make some links to business architecture.
In my last Column, I described the use of the Business Motivation Model for answering the question ‘how well’. In my column before that, I discussed the business context model. In both cases, I explored the use of models as a basic tool of architecture. Abstraction is key to modeling. First, it is a fundamental technique for modelers, but equally important, each of the different type of models we use in business architecture (such as the BMM and context) is based on a small set of concepts and relationships. Those concepts and relationships are themselves abstractions. So first, let’s explore the principles of abstraction and then look at it with respect to business architecture.
What is Abstraction?
Wikipedia offers several different definitions for abstraction that I’ve adapted below.
1) Abstraction is a conceptual process by which concepts are derived from the usage and classification of signifiers, first principles, or other methods. “An abstraction” is the product of this process—a concept that acts as a super-categorical noun for all subordinate concepts, and connects any related concepts as a group, field, or category. Conceptual abstractions may be formed by reducing the information content of a concept typically to retain only information that is relevant for a particular purpose.
When we examine this definition, we see some important points. Abstractions are derived or inferred based on principles. Abstractions describe related concepts and may be formed by obscuring information that is deemed irrelevant in a given context. Another definition of abstraction is:
2) Abstraction is a process or result of generalization, removal of properties, or distancing of ideas from objects. This may refer in particular to one of the following:
- Abstraction layers, an application of abstraction in computing
- Abstraction (linguistics)
- Abstraction (mathematics), a process of removing the dependence of a mathematical concept on real-world objects
- Lambda abstraction, a kind of term in lambda calculus
Again, we see that abstraction is a process of selecting pertinent information, where what is pertinent is determined by the context (and the skillful architect). We are also told that abstraction applies across a broad range of topics, not just to computer science or architecture.
Types of Abstraction
The definition above lists three specific techniques of abstraction that can be applied across a wide range of domains:
- Generalization – A generalization is obtained by inference from specific cases of a concept. More precisely, it is an extension of the concept to less-specific criteria. Generalizations describe a domain or set of elements, as well as one or more common characteristics shared by those elements. Verification can be used to determine whether a generalization holds for a given situation:
Software (object) modelers should be very familiar with the concept of
generalization and how it is used to define groups and categories.
- Removal of Properties – Abstraction has also been described as the “suppression of irrelevant detail”. We remove properties that are not relevant in a particular context, in other words, that are not important in conveying specific concepts to a specific audience.
- Distancing of Ideas – Objects contain concrete instantiations of specific concepts and ideas. We can use abstraction to separate the ideas themselves from the objects that reify them.
Figure 1 – Examples of Abstraction
Figure 1 shows two typical examples of abstraction. On the left is a common representation of enterprise architecture that illustrates partitioning, a type of separation of concerns. In this example, the whole of enterprise architecture is divided (partitioned) into four domains (abstractions) based on subject area. Each domain represents a generalization of a set of related architectural concerns and elements.
On the right is an example of subtyping which illustrates two of the techniques. First, it illustrates the typical generalization / specialization relationship. Account is a generalization of checking and savings accounts. Checking and saving accounts are specializations of account. In this example, I have also illustrated account as an “abstract type” (signified by the italics), meaning that a generalized account cannot be instantiated, only a specialized account can exist. In other words, Account is only a concept, or idea that has been distanced from the objects of checking or savings account. Note also that Account is an example of removal of properties. Only those properties that are important to all types of accounts are relevant in the context of the general account.
Abstraction in Models
It is important to note that models themselves are an abstraction. Models contain a set of concepts and relationships in a context. Well-formed models have a consistent and specific set of concepts, each of which is an abstraction itself. Together, they provide a representation of a desired (strategy or to-be), actual (as-is), or intended (design) state of real things, within the context of the model.
For example, the Business Motivation Model has the concepts of goals, strategies, tactics, and objective, and the relationships between them. The business context model has the concepts of actors, message, and subjects. Each of these models makes sense within a specific context, such as enterprise, initiative, or project level. We can think of this context as related to the level of abstraction of the model.

Abstraction Levels
Three common levels of architectural abstraction in models, conceptual, logical, and physical are illustrated in Figure 2.
Figure 2 –Abstraction Levels
While the definitions of each level can be a little fuzzy we can provide some guidelines:
- Conceptual – Conceptual models focus on the key concepts and relationship of the whole solution, not on how the system works. As such, they are generally static models where connectors, if present, show relationships, not flows.
- Logical – Logical models describe how a solution works, in terms of function and logical relationships between the resources, activities, outputs, and outcomes. They can show a static view or a dynamic view.
- Physical – Physical models refer to specific products, protocols, data representation, network capabilities, server specifications, hardware requirements, and other information related to deploying the proposed system.
Conceptual models are more abstract than logical models, which are more abstract than physical models. We describe the process of transforming one model to another as refinement when we reduce the level of abstraction. Note that the transformation of models between levels involves more than just adding detail. Abstract concepts are transformed into more concrete concepts during transformation. For example, the concept of a ‘customer’, may be transformed into a logical customer information entity, and then transformed into a set of tables and joins at the physical data level. We can also transform models in the other direction, going from physical (more refined) to logical, to conceptual (less refined). We call this process abstraction.
Business Abstractions
Now, let’s look at two typical business models and explore what abstractions they use, what level they are, and what techniques they embody.
The term business process can mean different things to different people, ranging from high-level ‘end-to-end’ processes, down to executable models. For the purpose of this discussion, let’s focus on descriptive and analytical models defined in BPMN notation.
What are the abstractions used in these models? One likely set would include Actors (represented as swim lanes), Organizations (pools), Activities, Events, Flows, Decisions (gateways), and Information. BPM models use these concepts and relationships to demonstrate the sequence of activities performed by actors in order to deliver outcomes within the scope of control delineated by events.
What is the level of abstraction of the typical BPMN model? Typically, BPMN models are logical in nature, where descriptive models are more abstract than analytical ones. Some higher-level end-to-end process models are more conceptual. Business models in general do not go down to a physical level.
What is the nature of these abstractions? Process models use partitioning to separate ‘how’ the business achieves outcomes into the constituent parts, and then shows how those parts work together. Removal of properties is used to focus on the pertinent information.
BPMN uses categories of concepts, such as activities or events. We could think of ‘activity’ as the generalization, and user, service, loop, and multiple as specializations of activity. In some methods, modelers use the generalizations in descriptive models, and the specializations in analytical models. In either case, note that the relationship between process and subprocess is not the same as shown in Figure 1 between type and subtype. Subprocess is a partitioning of a reusable unit.
Business Capability
A business capability model is used to capture a standardized set of terms that an organization can use to effectively and unambiguously talk about what it does, and what similar organizations do. ‘What’ an organization does is modeled as a ‘capability’ which is defined in the Business Architecture Body of Knowledge as “a particular ability or capacity that a business may possess or exchange to achieve a specific purpose or outcome” (BIZBOK® Guide v3.5, Chapter 2.2).
What are the abstractions used in these models? There is only one abstraction in capability models. The idea of ‘what’ a business does is represented (abstracted) as a capability. The capability model specifically separates the idea of what, from the ideas of how the capability is implemented, or who implements it, etc. Those concepts are treated separately in terms of mapping the capabilities to other concepts. Some approaches to business architecture find this separation and mapping to add clarity, especially in the case where the same capability payment processing) is often implemented multiple times, in multiple ways, by multiple different organizations, using multiple different processes and systems.
What is the level of abstraction of the typical capability model? Capability models are hierarchical, ranging from level 1 down to level 5. A typical model will refine a capabilities down to level 3 across most of the level 1 capabilities, and perhaps go down to level 4 or 5 in a select few. Capability models are conceptual, although the more refined models tend toward a logical level.
What is the nature of these abstractions? Capability models use partitioning to separate ‘what’ the business does into categories, identified by a common vocabulary. Agreeing to the common vocabulary is one of the important outcomes that emerges during capability modeling. Capability models also use distancing of ideas to separate the ‘what’ from other concerns.
While capability models are hierarchical, a higher-level capability is not a generalization of lower levels, and conversely, lower levels are not specializations of higher levels. Each level is a partitioning of function at a different level of abstraction.
As architects and modelers, we all use abstraction every day. I hope this Column has given you some better insight and understanding into this important concept and technique, and perhaps will help to improve your skills.
Mike Rosen
Latest posts by Mike Rosen (see all)
- Digital Transformation: Architecture Value - January 3, 2022
- Digital Transformation: Digital Transformation and the New Normal - July 6, 2021
- Digital Transformation Processes: Achieving “Good” Outcomes - January 4, 2021
- Digital Transformation: BizOps and Business Architecture - November 2, 2020
- Digital Transformation: Turning Data Into Value - June 1, 2020
Speak Your Mind