The layers of enterprise architecture are: business, application, information and

All Architecture — which is best seen to be about ‘the design decisions that are hard to change‘— requires structure. Simply designing/documenting a hodgepodge of elements and relations is unusable and thus — according to Uncle Ludwig — meaningless. As Enterprise Architecture as a discipline has arisen out of the need of complex, but constantly changing IT landscapes, this structure has often been a form of layering of ‘business’ and ‘IT’. This was because the main focus of IT Strategy has long been ‘aligning Business and IT’, which for top management generally meant ‘how do we get the right IT for our business?’. Is a layering approach (still) valid?

Warning: Analytical EA Geekery ahead.

TL;DR

A well known and often used approach to enterprise architecture is to use a layering model, the most common of which is some sort of Business – Applications – Technology stack, the B(D)AT stack (with D for Data added to it). The EA modelling language ArchiMate is based on it, for instance.

There are many problems with the BAT-stack, and they all spring from it origin: enterprise architecture grew out of application architecture when architects — generally with software engineering backgrounds — started to look at the enterprise-wide landscape. In other words, it’s history is IT-centric. And worse: its history is outdated-IT centric. It comes from a time when ‘humans using applications’ and ‘applications using platforms’ was almost all there was and when ‘business’ was something that humans do. But these days, some organisations may exist for 90% of their visible behaviour of IT-behaviour. And the humans in the organisation are mostly there to keep the IT running or fulfilling what the IT orchestrates. They do not just use IT, IT uses them. Another problem is that the split between applications and platforms is becoming blurred, e.g. when Full Deployment by Code deploys platforms, configurations, and applications in one combined action in Cloud environments (and you have to discover after the fact much of what was done, such as identifiers).

The BAT-stack might seem IT-centric, but that is not really the case. It works just as well for physical applications on physical platforms. So, its history is IT-centric, but the stack itself isn’t (as long as you change ‘Data’ in the BDAT variant to something more generic).

The only real problem is that some people still think these layers are somehow independent entities, and they hardly are (probably never were).

So: no layering? Not quite. We still have a form of layering: we have applications (both physical and informational) on top of platforms. We have a whole web of these. But as separate layers in the enterprise architecture they make ever less sense.

With a footnote on why (EA modelling language) ArchiMate’s Active/Passive split (also part of an IT-centric history) is problematic.

Because of the aforementioned waterfall, the classic/orthodox approach to model EA became the BDAT-stack, where BDAT stands for “Business, Data, Applications, Technology”. One basic form looks like this:

As represented here it can be extracted from well known frameworks like TOGAF or ArchiMate. There are various reasons to dislike this stack. Tom Graves for instance dislikes it (Dump the BDAT-stack!) because he dislikes everything that equates ‘enterprise architecture’ too much with IT. Hans Bosma for instance, too dislikes it too because it is too IT-centric and proposes a different stack (for ArchiMate) that consists of Organisation – Actor (both human and IT) – Infrastructure (general facilities). Some dislike the pure stack/layering idea completely and use something like this to organise their decisions:

And here it is at the core of Enterprise Architecture modelling language ArchiMate:

Many architects really love layers.

So, what are the issues with that classic stack? Here are some issues, minor and major:

• Applications are also Technology. In IT, there really isn’t a difference between ‘infrastructure’ and ‘applications’. In the end they are all simply (cooperating) algorithms running on some hardware;
• There is so much autonomous IT these days, directly performing business behaviour, that in many cases Applications are in fact Business;
• There are layers within layers, especially in the Technology/Infrastructure layer, and these are often important (platform) elements that merit their own attention;
• The original BAT-stack was a clear separation of actors in (then-valid) layers. But Data is not just something from the Application layer. Data is everywhere (which is reflected in ArchiMate, in a way). I am going to ignore the Data element for now until at the end. Sorry, data-geeks;
• The BAT-stack is indeed IT-centric, or one could say data-information-centric. This reflects the history of IT in business: it all started with the automation of administrative tasks — all about information. But actually, if you look closely, the stack can be interpreted outside IT as well. We may have physical ‘applications’ that make use of physical ‘platforms’. Think mounting a turbine with a rotor (application) on a tower (platform) to create a wind turbine. Or putting a circular sawing machine (application) on a work bench (platform) in order to saw wood (material, not data). The IT world has many more layers of dependency and more diverse relations between platform and applications (think one platform supporting multiple different applications) than the physical world, though.

The BDAT stack is also an expression of a form of myopia by software/application architects of yore, especially the architects who created the orthodox architecture frameworks. These architects almost exclusively came from the application software engineering world. They branched out to the ‘business’ aspect as that aspect was their main driver/user and the ones paying the cheques. They also mostly ignored infrastructure as something that lower-skilled/educated engineers put together for them from stuff that came in boxes. There, they just demanded the stuff from below, as ‘the business’ did for them. So, while they created a BAT stack, what they actually were thinking of more or less was a HAP-stack:

Humans use applications. Applications use platforms. But — as mentioned above — we also have this these days:

Some organisations almost exclusively provide digital services to the outside world (both to humans or to other IT), and the humans are mostly just there to keep the digital services running (or to change them). We’re moving from a world of Conway’s Law to a world where we see a lot of Inverse Conway’s Law.

In the end it boils down to the fact that the B(D)AT stack is an expression of a very ancient, and long no longer valid, reality in business landscapes. When the B(D)AT-stack was created, the IT-world was a lot simpler. You had human processes and those humans used applications and these ran on ‘infrastructure’ (hardware with operating systems). What humans did was ‘the business’. That is why for instance in ArchiMate the Actor element sits in the business layer, while the Application Component sits in the Application Layer.*)

But what we really have today is:

Which might be simplified to:

While this shows correctly that both humans and applications can be what performs the organisation’s behaviour, it is incorrect in another sense. Because the Platform layer also has human elements, people are required to run (and change) the platform. In fact, what we have is what is shown below. On the left an organisation where its behaviour is very people-intensive (when IT was just a small part of an information-based business such as banking decades ago, or maybe a physical shop), on the right an organisation where the platforms and applications dominate (the IT-heavy organisations of today, or a machine-intensive factory):

Actually, humans use ‘platforms’ too. But that may extend this line of reasoning unnecessarily far, I think. But there is — I repeat — no reason to limit this to IT. Physical platforms and physical applications can be fitted as well. But is most useful (and used) in the world of IT because of IT’s enormous complexity (a car may be built from tens of thousands of elements, a single software system is often built from millions of elements — each if-then-else, for loop, while loop, each function being what a component is in physical engineering).

A word of warning

The focus of all this is mostly the primary processes of the organisations. The actor’s (humans, applications, and platforms) roles in delivering the output of the organisation. But there are many more processes in an organisation. While the web site may be a robot you employ (application) to service your clients, changing the web site, requires a lot of human effort (with more applications and platforms to support them). Your security people (for physical or digital security) are of primary importance, but secondary in terms of the ‘why’ of your organisation. This is by the way how I separate the primary from secondary (and tertiary, …) processes: the direct expression of the ‘why’ of an organisation lies in its primary processes, for all the others holds the equivalent of “we don’t do l’art pur l’art” (we don’t do architecture for the architecture, but to support the primary ‘why’ of the organisation in the longer term).

The ‘acted upon’

So far, we have focused on the ‘actors’ in an organisation. The original ‘BAT’ stack was extended to the ‘BDAT’ stack (mostly reflecting the growth of IT and the fact that logic is brittle and thus machine logic (IT) is very sensitive to the correctness of input data). We too can extend the HAP-stack to include ‘data’. But we’re not going to call it data, nor put it in the stack proper. This is for two reasons. First ‘it’data’ is too IT-centric. And second, a bank may act on bits, a saw mill may act on wood, but a hospital, for instance, acts on its patients, which in turn also act on other things, including the hospital. Try to model that in ArchiMate… **). Who said it was simple? So, for the time being, we call this ‘The Acted Upon’, and the ‘actors’ are a subset of these.

During my career I’ve seen actual enterprise-wide prescribed solution architectures that had up to 9(!) layers. Stuff like ‘The Presentation Layer’, ‘The Database Layer’, etc. Following these theoretical ‘service-oriented’ approaches (against the warnings of more realistic architects) generally ended in disaster (a nice example of the potential toxicity of ‘architecture principles’). Every layer was supposed to be independent from the other and one of the sure things that would happen as a result was that performance died, either because all the overhead, of bottlenecks, or a disastrous accumulation of latency. There is a reason why the popularity of layered application architectures first grew, and subsequently died in the real world. Also an example of the saying that goes back to antiquity: “Amateurs talk strategy, professionals talk logistics” which seems true in IT as well.

The real landscape of an organisation may look a bit like this (remember, there is no need to see this as only IT, physical applications and platforms work as well):

This picture above shows a network of platforms, applications and humans, with added to it the humans that are responsible for making sure the platforms and applications work. These are in green. And I’ve added two examples of outside use of our applications (outsiders in violet). For the rest, we have a set of 8 applications and 9 platforms. In reality, and depending how correctly you count, a large organisation will have thousands. In fact, a spreadsheet that contains formulas and macros is an application that runs in Excel, which is the platform. Luckily, if you have tens of thousands of actie Excel spreadsheets, they run on a single platform (of which you may have hundreds or thousands instances active). But the above may be about 1% of your landscape. So, let’s show the platform layer from that picture above:

And the application layer:

Those are a lot simpler than the first picture. But they also leave out a lot of the relations.

The Bottom Line

The whole idea behind a layering approach seems to be that layers can be seen as independent (recall the 9-layer application architecture disaster mentioned above). It was never completely true that layers are independent and it becomes less true currently, amongst others because more platforms are managed by code (Infrastructure as Code, Configuration as Code) and this use of code then leads to an integration of code for the management (deployment etc.) of both platforms and application (Full Deployment by Code). This is especially visible in cloud platforms where you roll out a whole environment, platforms and applications alike in one big fell swoop of infrastructure as code. The fact that much of our management of IT turns to code thus may lead to the disappearing of clearly recognisable separately managed layers.

Having said that, we still do have a layering even if the humans and applications that interact with ‘the outside’ (for any value of ‘outside’) are no longer layers, but columns. Humans and IT are now working side by side (as well as interacting amongst themselves) to perform the organisation’s behaviour. But we still have layers: we have platforms that we do not expose and that are generic and are only there to support the business specific behaviour we see performed by humans and applications. Of course, if you are Microsoft Azure or AWS, you provide platforms (like kubernetes, web servers, etc.), but you still have the platforms you do not expose and that enable you to do this. After all it’s ‘turtles all the way down‘.

So, we still have a form of layering: we have applications (both physical and informational) on top of platforms. But as separate layers in the enterprise architecture they no longer really make sense (if they ever did). Yes, we need to rationalise as much as is healthy, but that goes for the whole mix of applications and platforms, not simply by layer. Too many dependencies. Your landscape is a web, not a tree, nor a layer cake.

Finally: I’ll be giving the closing keynote of the co-located Enterprise Architecture Conference Europe and Business Process management Europe 2022 in London on 12 October. A bit of a less EA-geekery subject than this article. See you there?

I’ll also be presenting on the 5th Annual Enterprise Architecture for Financial Institutions in Frankfurt (program and site still a work in progress) on 29-30 September 2022.

*)In ArchiMate, it would be more logical to have the humans in the Technology Layer (hardware and wetware), this could Realise ‘algorithms’ (instead of Application Component) — both of the digital and human kind — and these algorithms could realise Roles. But I pray that they will not do this, because every standard change is a hideous amount of work changing the book as there too we have two-speed: making new stuff is much easier than changing existing stuff. Another option would be to have ‘Material’ realise ‘Actor’ in the same way that (data) Artefact realises an Applications Component. Return to text.

**) The most fundamental ‘problem’ with ArchiMate is the active/passive split. This too is a legacy of the administrative software-engineering focus of the original designers. They understood data as passive, worked upon by algorithms. They added the important relation that data could be code by having a (data) Artefact realise an Application Component. But in the real world, the same element can be both active and passive. Splitting active and behaviour makes sense. If I were to design a modelling language, I would probably go for a structure and behaviour. Something is subject (active) when there is an Assignment relation to behaviour (the existence of the behaviour makes it active, not a special category) and object (passive) when there is an Access relation to it.

In this example, the Doctor is purely Active. They listen and operate. But the patient is both Active and Passive. Note: ArchiMate already dropped the split between Active and Passive in its latest addition: the Strategy Layer.

If you really want to let it become weird, when we inform people, we actually change (the contents of) their minds. So, one could argue that the Patient also changes the Surgeon. A surgeon who has to work with terribly behaving patients all the time, becomes a differently behaving surgeon. But I digress. As usual. Return to text.

What are the layers of enterprise architecture?

What are the key elements of enterprise architecture?

What is enterprise application architecture?

What is enterprise architecture structure?