On layers in enterprise-architecture

How many layers are there in an enterprise-architecture?

If we read any of the standard texts, you’ll see there are several popular answers. For example, Archimate says there are three: Business, Application and Technology. TOGAF says there are four: Business, Data, Application and Technology (though in the ADM, ‘Data’ and ‘Application’ are bundled together as a single layer, ‘Information-Systems’). I’ve seen others that say five, adding an ‘Information’ layer between ‘Business’ and ‘Data’. The one common factor in all of those layered structures, you’ll note, is that ‘Business’ is at the top, and ‘Technology’ – or, more specifically, IT-hardware and infrastructure – at the bottom.

If we look at the Zachman framework, we’ll find five layers, or six, or sometimes maybe more, or maybe less, depending on interpretation: it kinda varies. And these layers are somewhat different from those in Archimate and TOGAF and the like: there’s sort-of ‘Business’ and ‘Systems’ and ‘Technology’ and so on, but it’s framed in a different way, kinda sideways on from the rest.

And then there are other frameworks such as TMForum’s Frameworx, which in some of its views presents a four-layer layered structure much like TOGAF’s:

But another view of the same nominal framework shows a related-yet-different layered-structure of ‘Integration’; then ‘Business Process’, ‘Information’ and ‘Applications’ as segments in a single layer; then ‘Business Metrics’; and ‘Best Practices’:

And yet another view shows all of this again in an entirely different way, as a whole matrix of intersecting layers:

So which one is the right way to layer an architecture?

Confusing, to say the least… Why all these variations?

It’s because the correct answer to the ‘how many layers’ question is ‘none‘.

Within any architecture – ‘enterprise’ or otherwise – every entity can be viewed in multiple ways, and often must be viewed in multiple ways if we’re to make sense of where that entity might best fit in the overall scheme. Any supposed ‘layering’ is therefore an arbitrarily-chosen overlay or filter on the overall view. The layers are an artificial abstraction based on a set of assumptions about ‘how the world works’, that exists for practical convenience only, and for a specific type of purpose only – never more than that.

There’s a crucial distinction here between ‘useful’ and ‘true’. Layering can be useful – no doubt about that. Yet the moment we think that any layering we choose is ‘the truth‘ – is somehow ‘real’, in and of itself – then we’d have already lost the plot. We’d no longer have an architecture – instead, we’d already be halfway to a poorly-thought-through design that’s riddled with arbitrary assumptions and fundamental flaws.

The crucial point to understand here is that a layered-type structure can only fully make sense from a single viewpoint – such as, in those cases above, from the viewpoint of someone designing or managing an IT-infrastructure. Probably the simplest analogy here is with an ‘impossible object‘ such as a Penrose Triangle: we can sometimes kinda fake it up so that it seems to make sense if we look at it from exactly the right viewpoint (e.g. right-hand photo in image below) – but from anywhere else, it probably won’t:

When seen only from the selected viewpoint, the distortions that are needed needed to make it seem to work can become all but invisible. There’ll often be some warning-signs or symptoms that suggest that something doesn’t quite make sense – yet many people will ignore even those, because everything else does seem so much to make sense from that chosen perspective. To recognise what’s really happening, and to make the distortions visible, we have to look at things somewhat sideways-on – as in this New Scientist video of ‘impossible motion‘, or in this YouTube video of ‘impossible balls‘.

If we are only going to work from one viewpoint – and only from that one viewpoint – then, yes, subject to a whole string of ifs-buts-and-perhapses, we can sort-of get away with it. For that specific purpose, the practical convenience of a ‘layered’ view would probably outweigh its factual and functional inaccuracies.

But if we do do that, then at that time, by definition, we can’t and won’t be doing any kind of whole-of-context architecture. Instead, we could and would only be working on the architecture of a smaller subset within a larger context, as represented by that single viewpoint into the whole.

Which is why we cannot and must not mislead people by describing the respective architectures as ‘enterprise’-architectures, because they’re not. By definition, they can’t be – they are only a view of the context as viewed from a single viewpoint. For a true ‘architecture of the enterprise’, the only valid approach is to assume that everything and nothing is ‘the centre’, all at the same time. Anything less than this would almost guarantee distracting distortions, awkward ‘invisibilities’ and unfounded assumptions, and in turn all but guarantee the failure of the overall architecture.

Which is where we come back to the classic ‘layered’ models of enterprise-architectures, and how and why they are so problematic and error-prone – especially at a whole-of-enterprise level. There are three key problems in particular, which may also combine together to cause even worse problems:

— The layers also act as filters on the overall view – which may not be a problem if the applicable context is only a subset of the view through the layers, but may be seriously-problematic if the context is actually a superset of the view through any layer, or the combination of layers. I could perhaps summarise the scale of implicit risks of this problem with a quote from my post ‘A bit more broken‘, discussing examples of current trends that can impact architectures to support new or existing business-models:

…the emergence and evolution of information technology; also the impact of regulation and deregulation enabling key types of business-models; globalisation; the role of containerisation and other physical-transportation technologies; raising and lowering of tariff-barriers; the role of non-IT-managed ‘tribal knowledge’; nanotechnologies; 3D-printing technologies; patents and other ‘intellectual-property’ regimes; the impacts of organisational culture; jurisdictional clashes; the rise of the BRICS nations and the faltering of many ‘developed’ nations; the increasing role of China and others in Africa with regard to control of key mineral-commodities; the risks to global communications posed by rising levels of space-junk and suchlike; broad-scale political themes such as the Arab Spring; and, increasingly, the impacts of climate-change.

There are immensely complex architectural trade-offs here, immensely complex wicked-problems, of which only one strand is the IT. So if the architecture for the enterprise is based on a ‘layered’ concept that implicitly ignores everything other than IT, we might well find the organisation suddenly struggling to survive, with no means to identify what happened nor any means to respond, because the information needed to make sense of what’s going on has been ‘filtered-out’ from the view.

— The view through the layers may be ‘non-reversible’, different from either side – somewhat like the difference between looking upward from the bottom of a well, versus looking downward from far above the top of the well. This subset/superset problem is typified in the layering used in both Archimate and TOGAF, where the effective scope narrows as we move ‘down’ the layers:

• if we look ‘upward’ from Infrastructure towards Business, everything can be interpreted in terms of its relationship to IT-infrastructure
• if we look ‘downward’ from Business towards Infrastructure, all non-IT applications, data, resources and technologies become become artificially excluded from the view

The dangers of this kind of unintentional-myopia or tunnel-vision include:

• key architectural concerns, even for IT alone – such as physical-infrastructure, physical-security, power-supply and cooling for a data-centre – can be missed, by being arbitrarily and inappropriately excluded as ‘out-of-scope’ as we move further ‘down’ into the detail-layers of the architecture
• alternate options and affordances – including contextually more-appropriate options – can become ‘invisible’ to the architecture and subsequent implementation-designs
• assessment of cross-context trade-offs can become dangerously skewed

By the way, this problem is by no means specific to IT-oriented aspects of enterprise-architectures. In the military context, for example, hidden architectural-assumptions can and have caused huge problems in issues such as:

• integration of former Warsaw Pact equipment, processes and protocols into NATO operations
• creation and operation of temporary alliances with non-compatible systems, such as in Libya (NATO plus Arab League), Somalia (African Union plus US/EU technical support) and Central African Republic (COPAX plus France), and in multi-nation disaster-recovery operations such as the 2011 Japanese tsunami or (at present) Philippines cyclone
• integration of NGOs and other ‘non-state actors’ into peacekeeping [PDF] and/or disaster-recovery operations
• over-focus on warfighting-capability resulting in unnecessary constraints on capability for peacekeeping and/or disaster-recovery operations (the latter are becoming increasingly-common reasons for deployment of military assets and personnel)

(For more on this in the military context, see, for example, the work of US military-theorist David S. Alberts, or the links in my post ‘Hybrid-thinking, enterprise architecture and the US Army‘.)

— Layered models tend to incite inappropriate conflation – in which logically- and/or functionally-different concepts, attributes or entities become merged or blurred together in inappropriate or misleading ways.

For example, in the classic ‘three-architectures’ layer-model used in both TOGAF and Archimate, in effect anything physical ends up in the ‘Infrastructure’ layer, anything to do with information ends up in the ‘Application’ layer, and anything human ends up in the ‘Business’ layer. In Archimate especially, this conflation appears to be taken to extremes:

• ‘Business’ = anything-human + anything-relational + principle-based (‘vision/values’) decisions + higher-order abstraction + intent
• ‘Application’ = anything-computational + anything-informational + ‘truth-based’ (algorithmic) decisions + virtual (lower-order ‘logical’ abstraction)
• ‘Technology’ = anything-mechanical + anything-physical + physical-law (‘rule-based’) decisions + concrete (‘physical’/tangible abstraction)

One result, as described in my post ‘On human ‘applications’ in EA models‘, is that neither framework provides any means to describe any information-manipulation ‘application’ that is not enacted exclusively by IT – such as Amazon’s ‘Mechanical Turk‘ (an ‘application’ explicitly designed to be enacted by people) or a kanban board (an ‘application’ that, in its original form, explicitly manages its information via physical cards).

Another is that the conflations make it much harder to see or understand options and opportunities for substitution and the like, either by choice – such as in trade-offs between different service-delivery methods in a multi-method service such as mail-sorting – or enforced by ‘outside’ forces or events – such as in business-continuity and disaster-recovery.

Such conflations also often make it extremely difficult to avoid ‘vendor-driven architectures’ and similar ‘solutioneering’, in part because it makes it all but impossible to describe some context without all of the baggage pulled in along with it. And these conflations are also a primary source of IT-centrism and other forms of ‘anything-centrism’ – which are all but guaranteed to result in incomplete and/or actively-dysfunctional architectures.

Practical implications for enterprise-architectures

Most current ‘enterprise’-architecture is still strongly IT-oriented. For such types of work – especially in the common case of IT-infrastructures to support high-volume transactions for information-oriented industries such as banking, finance, insurance and tax – the classic ‘three layers of architecture’ concept is a fairly good fit for those particular needs. The problems described above do not disappear as such, but the constraints of that ‘inside-out’ layered-view, centred around IT-infrastructure, do fit those specific requirements well enough such that the convenience of a ‘layered’ model will usually outweigh the risks.

Note, however, those points about specificity above: the ‘three-architectures’ model only fits well with that specific set of requirements:

• IT-infrastructures – the focus-point for the three-layer ‘stack’
• narrow subset of business-needs – in essence, high-repetition, high-certainty, high-volume
• narrow subset of industries – primarily IT-based, information-oriented, highly transactional, such as finance, banking, insurance, tax

Conversely, the further we move outside of those specific constraints, the worse will be the fit between the ‘three-architectures’ model and the respective real-world context. Hence the further we move outward, the more problematic and risk-prone that model will become – and, hence, if the framework we use assumes a layer-based model, we will need to compensate in our architecture-practice for those risks and problems.

In effect, that classic ‘three-architectures’ model is merely one instance of a more generic architecture-development pattern which we could summarise as follows:

• Big-picture – indirect impact (e.g. ‘Business Architecture’ as ‘anything not-IT that might affect IT-infrastructure’)
• Common (or ‘client‘) – direct impact (e.g. ‘Applications Architecture’ as ‘anything directly-using IT that might affect IT-infrastructure’)
• Detail – the core concern or centre-of-interest

In other words, it doesn’t have to be IT: the same pattern could apply to finance, security, HR or just about anything else in relation to its broader context. Note, though, that whatever domain we use as our focus for this pattern, we would still need to take care with regard to the ‘non-reversible’ problem described above: those problems are not specific to IT-architectures, but more generally to misuse or misunderstanding of the nature and inherent limitations of that ‘layers’-pattern.

If you’re using a common ‘enterprise’-architecture framework such as Zachman, TOGAF or Archimate, probably the simplest way to summarise recommended-practice here would be as follows:

• if you’re doing IT-infrastructure only, use the classic ‘three-architectures’ pattern – it should work well enough
• if you’re doing IT-oriented application-architecture and/or data-architecture, you’re probably safe enough to use the ‘three-architectures’ pattern – though do beware of the common conflation-problems described above, and do be careful to check for non-IT-based applications and data that run in parallel with the IT-based ones
• if you’re doing application- and/or data-architecture that does not or should not automatically assume an IT-based implementation (such as in business-continuity planning, kanban-type process-tracking and the like), take especial care to compensate for the inherent IT-centrism of the ‘three-architectures’ model
• if you’re doing ‘business’-architecture solely and explicitly as ‘anything not-IT that might affect IT’, you’re probably safe enough to use the ‘three-architectures’ pattern – but do ensure that everyone involved is aware of the inherent biases and constraints inherent in doing so
• if you’re doing ‘business-architecture’ as ‘the architecture of the business of the business’, you should not use the ‘three-architectures’ pattern in its classic form, as it will skew the architecture towards IT-centrism in potentially-dangerous ways
• if the key focus of your architecture is anything other than the above (e.g. security-architecture, brand-architecture), or if you are doing any other work that explicitly engages concerns beyond the direct remit of IT, you should not use the classic ‘three-architectures’ pattern, because doing so will inevitably filter the required view of the enterprise in seriously-inappropriate ways

Let’s look at the practical implications for each of those three frameworks in a bit more detail.

Zachman

The ‘three-architectures’ problems described above have unfortunately become more prevalent – not less – in the most recent version of Zachman, which now explicitly specifies the same three domains (Business, Application, Technology) of the classic ‘three-architectures’ pattern respectively as the labels for its rows 2, 3 and 4. In previous versions, these were assigned somewhat-more-generic labels such as ‘Business Model (Owner)’, ‘System Model (Designer)’ and ‘Technical Model (Builder)’ respectively.

As a minimum, use an older version – one that does not reinforce the ‘three-architectures’ problems by conflating domains of interest (‘three-architectures’) with levels of abstraction (Zachman-rows). Overall, it’s probably best to do the following:

• identify the key business-question(s) and enterprise-scope of the work before using the Zachman framework
• use Zachman rows as levels-of-abstraction – or vision/purpose, business/strategy, near-future/’logical’ and ‘physical’, implementation, deployment
• moving ‘up’ the rows enables refocus on ‘why’, moving ‘down’ the rows enables refocus on ‘how’
• iterate up and down the rows as appropriate, adjusting the scope as required

Take especial care to avoid the incipient ‘solutioneering’ that arises from going too fast ‘down’ the rows, and/or failing to hold the view long enough in the ‘higher’ rows.

TOGAF

The ‘three-architectures’ model is hardwired into the TOGAF ADM (Architecture Development Method) as its Phases B (‘Business Architecture’), C (‘Information-Systems Architecture’) and D (‘Infrastructure-Architecture’). At first glance, it would therefore seem that it is not possible to use TOGAF reliably for anything other than IT-infrastructure architecture. That interpretation is not actually correct: there are workarounds to enable use of TOGAF ADM for broader-scope architectures.

The first of these is explicit in the ADM diagram, though perhaps not fully explained in the text. The key point here is that ADM does not assume that the Phases will be executed in a linear step-by-step sequence. Instead, each of the Phases can return or skip-forward to any other Phase, via a bidirectional link that passes through the central Requirements-Repository. It’s therefore legitimate to move back-and-forth between those three Phases, potentially broadening the scope as required, though still constrained primarily to IT.

The next option to use Phase A to identify the business-question and enterprise-scope – much as described for Zachman above – and then, based on that scope, reframe Phases B, C and D in terms of the generic ‘three-architectures’ pattern – Big-picture, Common and Detail – to iterate back-and-forth between broader and narrower subsets of the scope. The constraint here is that the ‘non-reversible’ problem potentially still applies – the ‘detail’-view arbitrarily constraining the ‘big-picture’-view – but again this can be dealt with and allowed for, as long as people are aware of the potential problem.

A third option is somewhat more radical, though in essence is just a matrix-inversion of the procedures in that part of the ADM. In each of the existing Phases B, C and D, we expect to explore the respective scope in terms of a primary time-horizon (usually ‘to-be’), then do the same with one or more comparison time-horizons (usually ‘as-is’ and any intermediate steps), and finally derive a gap-analysis and initial change-roadmap between each of the time-horizons. Hence in this option we drop the predefined ‘three-architectures’ assumptions about scope, instead setting the scope via the business-question(s) in Phase A, as in the previous option. The focus of Phase B then becomes the scope at the primary time-horizon, Phase C the comparison time-horizon(s), and D the respective gap-analysis and roadmap(s).

In each of these options, Phases E, F and G remain essentially unchanged, whilst Phase H can be usefully expanded to include more on benefits-realisation and lessons-learned, much like any other PDCA-type (Plan, Do, Check, Act) continual-improvement process.

Finally, another option is to reframe the whole ADM cycle and scope in terms of the ‘plugins’ concept in the content-metamodel of TOGAF 9, but in which – rather than the existing hardwired ‘three-architectures’ – all of the metamodel’s building-blocks, including the nominal ‘core-content’, are available to assist in identifying the respective scope and content for an ADM cycle.

Archimate

Unfortunately, the ‘three-architectures’ model is even more deeply embedded in Archimate than it is in TOGAF – it’s actually fundamental to its underlying metamodel. Even though there were some improvements in Archimate version 2 that pushed it somewhat towards the kind of ‘plugin’ concept that we see in TOGAF 9, it still remains inherently IT-centric.

At present, there are no clear workarounds to IT-centrism in Archimate – none that can be classed as ‘legitimate’ in terms of the language-standard, anyway. In principle at least, there is no ‘legal’ way to use Archimate to model something as straightforward as a multi-medium customer-service capability, or existing business-models such as Mechanical Turk, or brand-architecture, security-architecture, or financial-architecture – or how any of those intersect with the IT-specific components that Archimate does support. It’s true that most toolsets do now enable some form of ‘profile’-modification that makes it possible to add extra entities to the language as required – typically based off ‘static-structure’ elements such as ‘Artifact’, ‘Data Object’ or ‘Business Object’ – but by definition these would be ‘non-standard’, and would fail any form of model-validation in accordance with the association-rules specified in the standard.

Again, these problems are fundamental to the Archimate metamodel. It is possible to kludge our way around it somewhat, as per above, but the only real way to resolve the problems is to go back right to the roots of the Archimate metamodel, and rebuild almost from scratch. As documented in my post ‘Unravelling the anatomy of Archimate‘, there are ways to do this, that would still be fully backwards-compatible with the existing metamodel: but before that can happen, there needs to be both awareness of the problem, and willingness to address it – both of which, unfortunately, seem to be conspicuous mostly by their absence. Oh well…

Summary

The correct answer to the question ‘how many layers are there in an architecture?’ is none.

Every layers-based pattern for enterprise-architecture – such as in the common ‘three-architectures’ model popularised in TOGAF, Zachman, Archimate and elsewhere – represents an arbitrary set of overlays and assumptions onto the actual enterprise-context, and may be seriously problematic in how it constrains and distorts both the view onto the architecture, and the apparent range of appropriate solutions to that architectural need. These problems and their concomitant risks were summarised above as:

• Layers act as filters on the overall view
• The views through the layers may be different, depending on which direction we look
• Layered models tend to incite inappropriate conflations of terms

In most cases, there are workarounds for these problems, even in nominally ‘IT-centric’ frameworks. First, though, it is necessary to be aware that the problems exist!