On Archimate 3.0
Blog: Tom Graves / Tetradian
There’s a new version of the Archimate enterprise-architecture notation now out: version 3.0, launched at the IRM-EAC Enterprise Architecture conference in London last week.
With many thanks to Andrew Josey, Marc Lankhorst, Gerben Wierda and others, I’ve been working my way through the formal specification and accompanying notes, white-papers and the like.
So what’s in the new version? And is it a good fit – a better fit than the previous version – for the needs of enterprise-architecture, as the latter expands ever further outward towards a true whole-of-enterprise scope?
On the surface, and at first glance, yes, there’s a lot to like in the new version:
- There are new entities for strategy and motivation, with Outcome, Capability, Resource and more.
- There are clean-ups for some of the relationships, particularly between layers.
- There’s a new mechanism to define viewpoints.
- There are, at last, entities to describe some types of physical items beyond IT-hardware, and pathways along which physical goods might flow:
That last item will help people a lot if they’re working with Internet-of-Things and the like. It was sort-of possible, even with the previous version, to kludge Archimate to work with the physical-world – but now it’s possible to do it without kludges. For example, the new ‘physical layer’ does provide real support for modelling within the so-called ‘Industry 4.0‘, with sensors and other automation deeply embedded throughout manufacturing-lines and the like.
All of which is good news. In theory, at least.
But only ‘in theory’, because I’m still struggling with serious doubts about how well it’ll work in real-world practice…
Yes, I’ve seen a fair few people say it’s “just right” – just enough richness and versatility to support what they need. Yes, the new ‘physical-layer’ objects mean that we have a better chance now of being able to use Archimate to describe ‘internet-of-thing’ architectures and suchlike, which it certainly couldn’t do in the previous version. Some important gaps have now been filled – no doubt about that.
And yet… and yet…
Yeah, let’s face it: it’s still hopelessly IT-centric. Which, bluntly, was exactly what not to do at this point.
What’s the evidence for that? Well, take a look – you’ll need to explore the standard with some solid experience of dealing with architecture concerns from the world beyond IT, but it’s painfully evident once we do take a proper look at it. For example:
- There is now a Product entity – but it’s only available for use as ‘composite’-entity, an aggregation of IT-based services. Okay, yes, sure, that’s what bankers or insurance-folks might describe as a ‘product’. But according the relationships-model, there seems no way to describe anything physical as a ‘product’ – in other words, the most common meaning of ‘product’, like a vacuum cleaner, or a jar of strawberry jam from the supermarket. Oops…
- In principle we might be able to kludge the relationships so as to use the new Material entity to describe physical products – sort-of as in the diagram above. But try explaining to a marketing exec that we can’t use Product to describe a product, it can only be called Material instead? – no, that’s not gonna work, is it…?
- The Artifact entity, which would make more sense as a descriptor for a physical ‘thing’, is still defined as ‘an item of IT data’ that somehow kinda sits in the Technology layer.
- Applications are still IT-only – there’s still no concept that a human (or a machine, for that matter) might do something that is an exact logical analogue of an ‘application’. Or, more importantly, no means to describe such an activity. Which means, for example, that Archimate gives us no means to describe key aspects of architectures for business-continuity, disaster-recovery, load-balancing and more. Not helpful…
And these are by no means the only worries: for example, see Michael Poulin’s critique, particularly around Capability, Action and Service.
But the real problem is…
Actually, no, there are several really big problems with Archimate – and I’m not sure that they can be fixed, either in this version, or any future one. (Especially not whilst Archimate is under the control of Open Group – which is, after all, an IT-standards body, with rather too much of a vested-interest in keeping enterprise-architecture entrapped in IT-centrism for as long as possible…) Most of these problems interweave with each other, and include:
– The new entities and relationships merely add to the existing chaos of inconsistencies and special-cases in the underlying anatomy of Archimate.
– It still uses the BDAT-stack – or rather, a simplified variant of it, as ‘Business’, ‘Application’, Technology’ – which inherently entraps it into IT-centrism.
– Its concept of layering still embeds the same truly horrible set of conflations:
- ‘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)
(The few exceptions – such as ‘System-Software’ in the ‘Technology’ layer, and, now, ‘Contract’ in the ‘Business’ layer – merely add the confusion…)
– It’s now even more explicitly linked to TOGAF and its ‘Architecture Development Method‘ (ADM):
…which, again, rigidly locks it to the fundamental error of the BDAT-stack, and also rigidly locks it to an architecture-framework that is, increasingly, becoming much more of a hindrance than a help for real-world enterprise-architecture.
Oh well…
To be blunt, what this most reminds me of is the huge missed-opportunity of the launch of TOGAF 9, back in early 2009. Back then, there was a real chance – certainly a hope – that Open Group would have the courage to break out of the IT-centric box. In the event, they muffed it: they gave us instead a framework that had the pretence of a broader capability, but actually was even more locked into a kind of more-covert IT-centrism – and they’ve been pulling further and further backwards ever since.
And it’s much the same here, with this new version of Archimate. There’s a surface-appearance of improvement – in fact actually is a genuine improvement if (but only if) your architecture-focus is still in IT. But for the rest of us – and it’s a rapidly-increasing number of us now, in enterprise-architecture and beyond – it is, like TOGAF 9, a huge missed-opportunity: yet another step in the wrong direction. Which doesn’t help.
What Archimate 3.0 gives us is, yes, a worthy attempt towards what its creators no doubt think of as a greater completeness. But it’s still hopelessly IT-centric, which is frustrating as heck to those of us who work in whole-enterprise-architectures. Yet the most serious problem with this new version is that it’s moved yet further again towards a language that’s intended for design, not architecture – and that distinction is crucially important here. It’s far too complex and constrained for the much more free-form needs of early-stage architecture, over at the front-end of the Squiggle, yet it’s also not really complete enough for usage as a proper design-language, in the sense that UML or BPMN are, for example. The result is that it falls into a horrible dead-space, a kind of uncomfortable ‘Uncanny Valley‘, where it’s not really usable for anything – and in some ways getting worse with each new ‘upgrade’. Which, again, doesn’t help.
The blunt fact is that we still don’t have a usable, toolset-supported notation for enterprise-architecture, as architecture. What we need is something simple enough to use on a whiteboard or a paper notepad, fast, with the bare minimum of entities and relations – and then record that into a toolset, in a format that makes it easy to review and revise as much as we need. What we have instead with Archimate is a cumbersome, overly-complex design-language, hardwired to a fundamentally-misleading layers-model, that requires us to select and then specialise the right item from some 60 entity-types and a dozen different relationship types, all of which have to be linked together in exactly the right way for the model to work at all. The result is that not only is Archimate hopelessly slow to use for most architecture-practice, but it incites architects to do exactly what we should not do – namely settling too early to a design – simply because it’s too much effort to change the darn thing once we’ve finally managed to get it up on the whiteboard or the screen…
We need that simpler language for enterprise-architecture, and we need it now. Archimate won’t do that job – in fact is now perhaps further away from serving that need than it ever has been. As a community, we need to get together, urgently, to work out how best to resolve that need, before this new version of Archimate makes things even worse than they already are.
Leave a Comment
You must be logged in to post a comment.
