Have you ever attempted to align two ‘high level’ models? Sure there are likely to be features they both have in common – but then there is likely to be the rest of the model where things have been grouped differently, rolled up into different categories or described at differing levels of detail.
On occasion as a practitioner it can be tempting to forgo rigor and precision when asked to produce a ‘high level model’, especially when asked by a significant business stakeholder under tight timeframes and budget. However, in my experience the downstream consequences of getting a ‘high level’ model wrong can be significant.
Although there is absolutely a place for a quick sketch or ‘strawman’ of your ideas to communicate with a key stakeholder, there is equally a place for rigour and conciseness – after all – others are supposed to be able to build or manage something (e.g., a business, an application integration environment, database, or technology portfolio) using the artefacts that we architects produce.
The problem with the term ‘high level’ is that it is unqualified and can easily mean different things to different people.
The terms ‘contextual’, ‘conceptual’, ‘logical’ and ‘physical’ have their origins in data modelling and are used to denote discrete levels of viewpoint abstraction. These terms were popularised within the field of enterprise architecture by their use in the rows of the Zachman Framework. In my experience these terms can on occasion be used somewhat loosely and inconsistently by practitioners, partly because abstraction is in reality a continuum and not a set of discrete levels, and partly because there are few popularly agreed definitions across common frameworks.
The power of abstraction is the ability to draw attention to the details that matter. This post provides a set of ‘rules of thumb’ to use to consistently identify and specify viewpoint abstraction to enable alignment and comparison between views at differing levels of detail.
Combining, comparing or aligning models often means revising one or both in order to establish a common scope or categorisation of elements. John and Diane Smith in their seminal article ‘Database Abstractions: Aggregation and Generalization” (1977) were amongst the first to identify and define abstraction as either aggregation or generalisation. Abstraction by aggregation is concerned with providing a view that simplifies the composition of an entity. For example, a bicycle can be understood as a single entity, or at the level of its constituent parts. Abstraction by generalisation is abstraction by type or category. For example, a bicycle can be understood (in order of increasing generalisation) as ‘type of non-motorised two-wheeled transport’, ‘type of two wheeled transport’ or. ‘a type of transport’
Frameworks and Abstraction
Within TOGAF 9.1 the Enterprise Continuum is used to deal with the issue of abstraction. The Enterprise Continuum provides a framework within which to position architecture or solution building blocks according to the degree to which they are generic (generalised) or specific to a particular context (specialised).
The Capgemini Integrated Architecture Framework (IAF) in my opinion provides the clearest definitions amongst common enterprise architecture frameworks for the levels of abstraction.
The following definitions for levels of abstraction build on the IAF definitions and have been refined in the context of developing models particularly for large strategic projects where the need to combine and align representations at various levels of detail frequently occurs. The definitions describe characteristics that models at each level of abstraction should exhibit. The definitions for contextual and conceptual are the most contentious and do not equate with the respective Zachman Framework rows. As John Zachman himself states “The Rows of the Zachman Framework define TRANSFORMATION, NOT decomposition”
A contextual level of abstraction is concerned with describing where the entity of interest exists in relation to other entities.
A contextual model treats the entity of interest or ‘architecture’ as a ‘black box’ (i.e., provides no internal details) – and only defines the entity of interest in terms of its relationship to other entities external to it.
A contextual model can be thought of one that describes the scope of the problem space within which a business or system must operate (see IAF definition).
A contextual level of abstraction is the highest aggregation of an entity itself. However, obviously it is possible to continue to abstract by aggregation by considering the entity of interest as a component in the wider system or environment in which it operates.
A conceptual level of abstraction is concerned with identifying what something is by representing the scope of concepts that define or comprise the entity of interest.
The concepts in a conceptual model are generalised as idealised reference types (e.g., subject area model, data archetypes, stereotypes or metaclasses). For example, the concept ‘wheel’ (i.e., denoting something round that rotates) in the case of a bicycle. These archetypes or metaclasses represent the most generalised descriptions of the components that make up the entity of interest.
A conceptual level model can include relationships too – these are relationships that might be considered ‘typical’ between the respective metaclasses (e.g., Porters Value Chain components).
A Business Capability Model (comprised of just capabilities) is arguably a conceptual model, as would be an Application or Technology Reference Model (i.e., a model that models categories of applications or technologies).
A logical level of abstraction is concerned with the design and assembly of the entity and how its components are arranged in relation to one another.
A logical level model identifies the entity components but ‘hides’ their physical implementation details. This type of model is perhaps the most common model type used by both Enterprise and Solution Architects. Most process models are logical level models.
The components within a logical design are generalised as types or classes of components.
A logical level model also documents the relationships between components. These relationships may be specific to the design.
Design principles can be applied to a logical design.
Arguably, in practice this also the level at which ‘conceptual’ data models are developed, (i.e., a model of business entities).
A physical level of abstraction is a specification of which particular physical components will be used in an implementation or actual object.
Components in a physical model may include details such as the version, production date or model type.
A physical model is the least generalised (i.e., the most specialised) view of the entity of interest.
Figure 1 – Alignment across levels of abstraction
Alignment – the ultimate goal
Some practitioners might argue that this level of modelling precision is unnecessary and that all that is needed is the ability to communicate what is intended with stakeholders. This goes to the heart of defining what makes a good architectural model. The requirements are in reality twofold – one to effectively communicate intended design or perspective, the other to frame or guide implementation of the design concept or solution.
Within a large scale implementation there is typically not the luxury of waiting until the entire solution is fully modelled to the physical level. Instead, there is usually a need to be able to partition the solution into manageable stages or modules. A consistent approach to model types and abstraction (see Figure 1) coupled with TOGAF Architectural Partitioning concepts provide the means to ensure that the various phases or modules will align to deliver the original concept or vision.
Of course in practice there is always the need to balance effective communication with modelling precision. Architecture modelling done well may well combine contextual, conceptual, logical and physical details in the one model, while respecting the requirements of abstraction. For example, using a conceptual model to frame separate components which are then detailed at a logical or physical level.
Ultimately the business along with your credibility as an architect may depend on your ‘high level’ model. Resisting the temptation to skimp on precision and detail will mean you will need to qualify the request for a ‘high level’ model in order to land on an agreed level of abstraction. This is more likely to result in a model that both meets stakeholder concerns and also provides a rock solid basis for further elaboration and decomposition. Hopefully the framework outlined in this post will assist you with this important conversation.
What ‘rules of thumb’ do you use to succinctly communicate with the precision necessary to achieve alignment at 10,000 feet?
 J.M. Smith and D.C.P. Smith. Data base abstractions: aggregation and generalization. ACM Transactions on Database Systems, 2(2),June 1977
 Aitken, C. J., (2009), Design Integrity and EA Governance. In Pallab Saha (Ed), Advances in Government Enterprise Architecture, Hershey, PA: Idea Group
 Zachman Framework Rows. What are they?, http://www.zachman.com/blog, March 2015
 M., Porter. Competitive Advantage, 1985.
 DAMA Guide to The Data Management Body of Knowledge 2010.