ArchiMate NEXT drops BAT. Now What?

I’ve been involved with/using ArchiMate since 2009 when the first edition of The Open Group arrived. But I have all the versions, including the original one from 2004 on which my current (not then) employer (then ABP, now APG) was involved (as were a few other large Dutch organisations). What to think of the draft of the next instalment: ArchiMate NEXT?

In the coming series I will discuss the ArchiMate NEXT snapshot from July 2025. Personal circumstances have prevented me from doing this earlier, sorry people.

It’s a mess, but how bad is that anyway?

On 3 March 1999, Larry Wall, the inventor of the perl*) computer language gave a presentation at Linux World titled: Perl, the first postmodern computer language. Perl has been eclipsed by Python, these days, but there still is a lot of stuff done in Perl). His vision was: a collection of good ways to do things can be highly usable and effective, without there being some sort of ideal single über-meta-structure. It is, an interesting read for designer geeks. Quote:

You’ve all heard the saying: If all you have is a hammer, everything starts to look like a nail. That’s actually a Modernistic saying. The postmodern version is: If all you have is duct tape, everything starts to look like a duct. Right. When’s the last time you used duct tape on a duct?

Larry Wall, Perl, the first postmodern computer language (1999)

Exactly. Not everything becomes a nail if you just have a hammer. The hammer also becomes a nutcracker, a murder weapon, a way to softly scratch that nasty itch on your back, a lever, an art object. Useful (and as Uncle Ludwig would have it: meaningful).

Anyway.

There are a few fundamental choices that have been made by the original ArchiMate designers (Marc Lankhorst, who was project lead, and others) in the period until 2007 that have sculpted the initial form of the ‘language’, and that are visible to this day. With the experience of the last decade and a half, I’ve come to the conclusion that some of these choices weren’t ones I would have made. I still found ArchiMate to be useful (there is no better non-tool-restricted one to my knowledge), but some of it I found (and find) to be messy. Usable, yes, but messy. A bit too messy for my liking here and there, I admit.

People who model, especially those that think about modelling methods tend to like ideal single über-meta-structures. And they go at it with a set of basic ideas and convictions. In ArchiMate these were the layers (Business – Application – Technology, or BAT, with lower layers active structure and behaviour being ‘Used-By’ (now called ‘Serving’) higher ones) and columns (active structure, behaviour, passive structure — inspired by the subject-verb-object of natural language), the inside/outside split (service/interface versus things like function/process, role/actor, node). Added to that were several forms of abstraction. The passive structure layers were related via Realisation. In the Discussing ArchiMate sections my book I have written how that creates tow totally different meanings of ‘Realisation’. The first is identity: say, ‘answer.doc (Artifact)’ is the bits/a file. This Realises ‘Answer Word document’ (Data Object)‘, but it is the same thing but modelled as usable by application function performed by the ‘MS Word (Application Component)’. This Realises the ‘Reply to Client’ (Business Object)‘, which is created by the ‘Answer Client Request (Business Process)’. All three represent passive structure elements are about the exact same thing in the real world, so the Realisation is — from the perspective of the real world (one we should never forget) the same thing. It’s what in the older ArchiMate literature has been called ‘representations’. All these are different (model) representations of the same entity (from a business perspective).

But other Realisations are not necessarily the same thing, they are often independent creations. ArchiMate, sadly, doesn’t see a Service as the externally usable/visible part of the process or function it comes from. This too comes from deep history, More on that another time.

Maybe I should create a freely downloadable PDF of those various ‘discussion’ sections of the book. [I did, it’s below].

As has become clear to my audience over the years: I have been an enterprise/digital architect/strategist who deeply accepts the — sometimes harsh, always messy — reality. Enterprises are real, after all. I have also tried in my career not to pick fights with facts, because it is inevitable that you lose in the long run**). Of course, that leaves the question if you have recognised all the relevant facts and you may unwittingly be in a fight with them after all. And then you lose. But I digress, as usual.

Paleoarchimatontology

Here is the original ArchiMate metamodel from 2004:

The layering in Business-Application-Technology fits the kind of architecture vision that was leading at the time and is still popular today. Architects were above all people who were thinking of the application level, where processes were their inputs and infrastructure was something far beneath them, something not-that-important, just like water and energy, something for less highly educated technical people, and they were architects, after all. Large administrative organisations were involved in the creation of ArchiMate by the university institutions: ABN AMRO bank, the ABP pension fund, and the Dutch Tax and Customs Administration. Architecture frameworks also displayed that culture at the time: a waterfall starting with business requirements and ending with low level technology. So, for instance, they added the ‘Representation’ concept, as in: well, we have a digital file, but also a printed document with a real signature. ArchiMate was a clear representation of their world.

In those days, infrastructure was not taken all that seriously by those people: why should you model this in architecture? It was taken for granted and not seen as an important part of what needed to be ‘architected’. It was also mostly done by people without a higher education degree. Enterprise architects weren’t interested much. So, that low-level stuff in ArchiMate only contained some basic elements. The irony of course is that if anything has seen its innovation it has been infrastructure, but I digress, as usual.

Note: the colour of System Software above is confusing, the standard says only the Infrastructure Service is behaviour in the Technology layer. As the designers wrote at the time: “In the technology layer, the only behavioural concept that is relevant is the infrastructure service. In this layer, it is even more unlikely than in the application layer that the internal behaviour of infrastructure components will be modelled at the architectural level [colouring GW].” — the architecture level being the abstract level at which real architects should operate, of course. I dislike that abstracted ivory-tower-like thinking and in my experience a lot of damage has been — and is being — done in complex business-IT landscapes by trying to abstract away from reality so much that reality starts to get ignored. People after all stumble over molehills, not over mountains. The best architects I have worked with all had a deep feeling for (the engineering) reality. The ones who caused the most damage were those who lived in an idealised unreal world, where ignorance is bliss.

Anyway, a lot has changed since ArchiMate was handed over to The Open Group. The first TOG edition (2009) changed little. The second TOG edition (2013) fixed the structure of the Technology Layer, introducing proper behavioural elements there. ArchiMate 3 added a lot of stuff, though after a bit of a hiccup as the third edition was such a mess in terms of relations that they had to publish a ‘technical Corrigendum’ (3.0.1) before it could be used at all.

Back to BDAT-layering.

B(D)AT is a seductive simplification

In my 2024 talk The Effective Architect at EABPM in London, I included these two slides:

The first slide shows the B(D)AT simplification, a simplification that is nice for digital architects, but that nicety is paid for by being in many ways not so much a usable abstraction of — or even in conflict with — actual reality. The second slide shows a depiction of that reality as we actually encounter it: We have — next to purely human processes — many IT systems, some are applications, some are platforms (software that can hold data and can execute other software — and we have platforms on platforms on platforms etc….). In general, platforms are used by applications (to run on, or to store in), sometimes applications are used to manage platforms. And all over the landscape of IT are humans that maintain, update, manage, these platforms and applications (the green elements in the slide). Applications may be used by other applications (e.g. via an API) And some applications are used by humans. That human that has to restart the server every week and check stuff, is essential to its operation, ignore them at your peril. We have long talked about Business ‘and’ IT, but there is no strict ‘and’ here, that was more the case many decades ago (if ever). A post about this from 2022 is here Layering — is it really a useful approach in Business/IT/Enterprise Architecture?.

See for instance The Anatomy of the ArchiMate Language (2010): “Applying information technology effectively requires a company to have a clear, integrated vision on the relation between its business and IT. Without such a vision, the
IT infrastructure will never adequately support the business, and vice versa, the business will not optimally profit from IT developments.”

If that talk about platforms is confusing, take a simple example: Microsoft Excel. It is often shown as a “Commercial Off The Shelf” (COTS) application. But when you start that application, what do you see? A screen with rows and columns of empty cells, a new spreadsheet. It doesn’t do anything useful for your business at that point. But a human can program this spreadsheet with formulas, hard coded variables, and even program macros in a programming language. In fact, when you create a spreadsheet you are creating a program that runs inside Excel. Excel is thus a combination of a platform and a programming environment, and the spreadsheet is in fact an application, not a document (and yes it can be used as a document writing system too — remember the duct tape?). This, by the way, is why having thousands of spreadsheets in your organisation can be such a nightmare (i.e. thousands of potentially inexpertly coded computer programs). The same is true for platforms like SAS, Oracle, etc., none of these do something useful out of the box. They are ‘complex application platforms’, combinations of runtime platforms, maintenance and development applications, specific configuration data, and so forth.

ArchiMate slowly adapted to reality by adding all kinds of — outside the basic ‘Serving’ between layers — Realisation relations between the layers, A Technology Service could Realise a Business Service, that sort of thing. That ‘identity/representation’ relation again.

So, given that ArchiMate NEXT now effectively drops the layering, am I happy with this development? Because, ArchiMate NEXT seems to really drop the layers. While there still is ‘Business’, ‘Application’, and ‘Technology’ domains (not layers), there is now also a ‘Common’ domain, that contains all behaviour — which has been ‘abstracted away’ from the BAT layers — as well as a few abstracted Active Structure elements (elements that can perform behaviour), most importantly Role.

What I like about that is that I can now for instance simply have an Application Component and have it Assigned-To a Business Process (that used to be a derived relation that ended up being a Realisation). Much, much clearer (note, this could have been the case already if Realisation had been seen as a stronger relation than Assignment, but I digress again, and see below in the PDF) .

But something feels askew, and I can’t really put the finger on it. I am feeling the behaviour (formerly) column — and with that ArchiMate — has become fuzzy, less clear and less precise. I like having a Technology Service that is used by an Application Function, or a Business Service that is used by Technology Function (the system administrator role that judges before the necessary reboot of a platform). The clarity of what you model will — I feel — diminish.

So, ArchiMate NEXT drops BAT (somewhat). Is that good?

I am not yet convinced that the way it does it is. The more I look at it, the more doubtful I am becoming.

P.S. The free excerpt of Mastering ArchiMate (about 60 pages) contains the entire description of the language/grammar, the rest of the book (getting a feel for modelling choices with many examples) is only for buyers, That full book includes the sections on Discussing ArchiMate. But here below I am sharing the Discussing ArchiMate chapter that is at the end of the book. You know what is really funny? It is only now that I see I forgot to change the 3.1 in the section 35 heading to 3.2… Anyway, some of these points will probably surface if I write more about ArchiMate NEXT, so you can peek ahead…

P.P.S. You know what is really funny? In the chapter linked here (and from the first Edition of Mastering ArchiMate until today) there is an error in that part. In my defence: TOG made the error when they turned pre-TOG ArchiMate into TOG-ArchiMate version 1.
Above, I noted that originally, System Software was coloured yellow — which was the colour used for behaviour in the metamodel — but that was a mistake. System Software wasn’t behaviour in the original pre-TOG ArchiMate, in theTechnology Layer only the Infrastructure Service was. But when TOG published their ArchiMate Version 1, Section 6.3 contains the behavioural elements of the Technology Layer and section 6.3.2 is … System Software. They were fooled by the colour, and by the Assignment relation from Device probably, and thus so was I (I started with ArchiMate when TOG released it). So, in my Discussing ArchiMate I make fun about System Software being ‘behaviour’, but Paleoarchimatontology has shown me Marc and friends did not make this mistake originally. How it slipped through mystifies me, though.

*) Perl was one of the key elements in the macOS installer I once wrote and distributed — i-Installer — and maintained that was used to distribute TeX (gwTeX…) and other open source software between 2000 and 2007. [Return to text]
**) Unless there were moral obligations to do so. [Return to text]

Next post in this mini-series: ArchiMate NEXT: At your service!

[You do not have my permission to use any content on this site for training a Generative AI (or any comparable use), unless you can guarantee your system never misrepresents my content and provides a proper reference (URL) to the original in its output. If you want to use it in any other way, you need my explicit permission]