On Archimate 2.0

Archimate 2.0 is now available – its formal release was at the end of January 2012, during the Open Group conference in San Francisco. I’ve been a bit busy in the meantime, so this is the first chance I’ve had to do a proper review.

Why Archimate?

Archimate aims to be the standard notation for all enterprise-architecture work, bridging an important gap between free-form whiteboard-style sketches and detail-layer executable models.

The catch is that it all depends on what’s meant by the term ‘enterprise-architecture’… which is not a trivial point, as Len Fehskens explained on the Open Group blog early last year, in his seminal post ‘Enterprise Architecture’s Quest for its Identity‘.

The short answer is that version 1.0 of Archimate was a very good fit for what Fehskens describes as ‘EITA’ – enterprise IT-architecture. It was not a good fit for whole-enterprise architecture – a literal ‘architecture of the enterprise’ – because in essence everything in Archimate 1.0 centred around IT, and it had no real means to describe anything that did not in some way directly impact upon IT.

For a logistics context, for example, we could model how information about a package would move through the system, but not the physical package itself: so there was no real way describe any of the scenarios by which the parcel and the record of that parcel might become misaligned – or, perhaps more importantly, become realigned. (In the real world, that kind of misalignment still happens way too often for anyone to be comfortable or complacent about it – as can be seen in so many Twitter-complaints with the ‘#fail’ hashtag. It’s a very real business-problem – and usually a problem that is rooted somewhere deep within the architecture of the enterprise. Which is why it is our problem.)

There were also several key items that were missing from the Archimate metamodel that were going to be needed by anyone aiming to bridge the infamous business/IT-divide – particularly about motivation. (There’d been some coverage of that in the earlier versions of Archimate, but were dropped in the 1.0 release, perhaps to improve its alignment with the TOGAF 9 metamodel.)

The underlying anatomy of Archimate is also somewhat problematic. As I explained somewhen mid last year in a long post, ‘Unravelling the anatomy of Archimate‘, to me there are what seem to be several fundamental flaws in the structure of its metametamodel that actively constrain its use to an IT-oriented view of enterprise-architecture. And there seems to be no easy way to resolve those flaws without going a long way down into the internals and starting again. The surface-layer can look much the same – and certainly remain backwards-compatible – but the internals would need to be very different to make Archimate usable for the kind of business-oriented enterprise-architecture that so many more EAs are moving towards now.

So when I first found out about the revision for this new version, my attitude was ‘high hopes but not high expectations’. And that’s pretty much what’s happened – except that there’ve been some been very useful additions, some of them in places that I didn’t expect.

So for those of us working in whole-enterprise architectures, there’s good-news, and there’s bad-news. And there’s quite a lot of good-news, and nothing in the bad-news that we wouldn’t have expected, so let’s get the latter out of the way first.

Bad-news: there’s no fundamental move away from IT-centrism

The bad-news it that we’re still stuck with the same inane IT-centrism as before – right from the very first sentence of the specification:

An architecture is typically developed because key people have concerns that need to be addressed by the business and IT systems within the organization. … Architecture descriptions are formal descriptions of an information system, organized in a way that supports reasoning about the structural and behavioral properties of the system and its evolution.

There’s a lot more to any enterprise than just its IT-based information-systems, but in essence that’s all that this new version of Archimate would allow us to handle. And that annoyingly-arbitrary constraint is carried through into the same old pseudo-layering of Business, Application and [IT] Technology, in which ‘Business Layer’ is a similarly arbitrary and annoyingly-incomplete placeholder for ‘anything not-IT that might affect IT’. Not only absurd, but now seriously out-of-date for current EA practice – as even Open Group would freely admit, given the nominal focus of many of the presentations at the San Francisco conference and elsewhere

Sigh.

And they’ve used the same ‘plug-in’ concept for all the new add-ons as in the TOGAF 9 metamodel – which is a nice idea, but there’s nothing to support it in the existing Archimate metametamodel. So the result is that the underlying architecture has become yet more fragmented – which is going to make it even harder to do the fundamental rework of the architecture that must be done it’s to be usable forward into the future.

Oh well.

But that’s about the sum-total of the bad-news, and none of it was unexpected, so let’s move on to what is good in the new release.

Good-news: the Motivation extension

This wasn’t unexpected, but it’s still very good news: we can now link any architectural-entity explicitly to the reasons why it exists, and in a manner that allows for formal rigour between all of those interrelationships, roughly in line with the Business Motivation Model (BMM). The new entities are a subset of the BMM, but still eminently usable:

  • Stakeholder
  • Driver
  • Assessment
  • Goal
  • Requirement
  • Constraint
  • Principle

In the Business layer we can link these to the existing entities for Value and Meaning, to create a (mostly)-complete trail of derivation for business-purpose. No equivalents in the other two layers, but it probably doesn’t matter as long as entities there are linked up into the Business layer, either direct or via the new Motivation entities.

The only thing that’s bizarre about this is the whole idea of treating motivation as an ‘extension’, rather than core. To use Simon Sinek’s term, surely we should always ‘start with why‘?

Good-news: the Implementation & Migration extension

This one’s likewise very good news, and I wasn’t expecting it at all. This gives us a means to model the dynamics of an architecture – the way in which the architecture itself undergoes change. Again the new entities here are only a subset of what we really need for this, but they’re certainly enough with which to get started:

  • Work-Package
  • Deliverable
  • Plateau (for example, an ‘intermediate state’ at some predefined time-horizon)
  • Gap

It does make sense to describe this as an ‘extension’, because we don’t need it to describe a particular configuration or ‘state’ of an architecture – though we do need it whenever the architecture is to change.

The really good-news about this is that it provides a nice graphic workaround for the fact that almost none of the existing toolsets handle architecture-dynamics in any useful way. And if the toolset-vendor implements the appropriate ‘hooks’, this would also provide a solid anchor-point for cross-links into project-management tools and the like. Nice.

Good-news: the Location entity, and other minor amendments

A Location entity had been included in the earliest iterations of Archimate, but for some unfathomable reason it was dropped long before the Version 1.0 release; it now makes a very welcome and very necessary return.

A glance at Zachman should give the reason why it’s so important: without it, we have no means to describe the ‘where‘ of the architecture, whether in virtual, physical or any other form.

The Location entity is arbitrarily placed in the Business layer – which makes no sense, of course, because location should apply to everything, but it’s probably the only way that it can be handled within that absurd IT-oriented ‘layering’. Despite that placement, it is allowed to connect with every other entity, mostly via ‘assignment’ or ‘association’ relationships.

The other oddity is that there’s no explicit distinctions between types of location – particularly virtual versus physical, which is extremely important even in IT-architecture. No doubt this can be handled within toolsets via attributes, but it is a distinction that needs to be addressed.

There are a few other clean-ups down in the Technology layer, mostly new types of IT-specific relationships for newer technologies. To me the most significant item is Infrastructure Function – significant mainly because its stated purpose is to reinstate some much-needed structural symmetry in the underlying metametamodel for Archimate.

What next?

The specification ends with a ‘Future Directions’ chapter, which summarises some ideas about what could be added in future. Which is all fine: except they still don’t include anything that would make it more usable for the non-IT aspects of enterprise-architecture.

At the very least, if Archimate is to be usable for what it purports to do, we need it to be able to cover the symmetric equivalents of Application and Technology in the non-IT space – and not try to dump it all into ‘Business’, where most of it does not belong. The core partitionings that we need in an architecture are:

  • role-type – passive-structure, behaviour and active-structure
  • asset-type – physical-object, virtual-information, human-relation
  • agent-type – physical-machine, IT-system and/or human-process

Role-type is the nominal core of current Archimate. But asset-types are in effect conflated into and scrambled within Technology, Application and Business layers respectively; and the only agent-type fully acknowledged is IT-system, with the others either ignored (physical-machine) and/or arbitrarily shunted into the Business ‘layer’ (human-process). This makes it all but impossible, for example, to use Archimate to describe business-process redesign or process-fallback where the existing or alternate implementation-methods would use machines or manual-processes; it makes it impossible to describe a business-continuity plan for a context where the IT is out of action; it still leaves it impossible to describe that logistics paralleling-problem between physical parcel versus information about the parcel. This are real needs in any viable enterprise-architecture, and we need a notation that can cover them. Hence, if Archimate is to be the notation of choice for EA, it needs to address these concerns: there is simply no other option.

From assorted snippets of conversation with various colleagues I know that such concerns are being explored in the discussions for the next version of TOGAF, currently code-named ‘TOGAF Next’. So if Archimate is to keep aligned with TOGAF, any putative ‘Archimate Next’ would have to follow suit. So I do still have high hopes for something useful and usable happening there; is it too unreasonable this time to have high expectations as well?

4 Comments on “On Archimate 2.0

  1. I am part of a Usability Architecture group (Usability Researchers, Usability Designers, Usability Prototypers…) embedded within a Government Agency’s Architecture Group. TOGAF, and Archimate, have recently been adopted as a standard. Currently, I am trying to fit my user-view into Archimate through the Motivation extension and working on either a separate user viewpoint diagram (for relevant pieces of the project) or embedding them into other Viewpoints (like the Actor Co-operation Viewpoint).

    Curious to know whether others have attempted a user view (with for e.g., Usability Critical Success Factors, KPIs, Personas, Storyboards, HL Designs…) or how others see this fitting with Archimate…

    Thanks!

    • Hi Sandra – a good challenge!

      From my understanding, the practical problem you’ll face is that both TOGAF and Archimate focus primarily on the IT hardware and software, and only have at best a rudimentary grasp of people-as-people. Or, to put it another way, they have only a minimal concept of ‘user’, and none at all of ‘experience’ – which makes them somewhat problematic for work on ‘user-experience’… 😐

      To be blunt, I don’t think you’ll be able to use TOGAF to do anything meaningful on user-experience, because it’s constrained to an almost completely separate part of the overall system scope. The new Motivation extension makes linkage to Archimate more viable, but it’s still only a very snall overlap with UX – even less than is available in BPMN, for example. My understanding is that you will have to use other types of models or views to do the actual UX modelling, and provide ‘hooks’ within those views to crosslink to Archimate – such as via the Motivation Extension, and a handful of entities in the Archimate ‘Business Layer’. It’s a kludge, but it’ll work. (Sort-of, anyway.)

      One person to contact is Bas van Gils (@basvg on Twitter) at BizzDesign – he’s been doing a lot of practical work on pushing the boundaries of Archimate. For example, see his posts on Archimate on his ‘Strategic Architecture‘ weblog. (He’s based in the Netherlands, but visits Canada quite often: perhaps check with him about a possible meetup?)

      Do also take a look at the free (university-funded) Archimate tool ‘Archi‘: it has a useful ‘sketch’ mode that allows you to work outside of the formal rigour of the Archimate notation, yet still link properly to the language as required. That may help you get round some of those limitations – but again, it is focussed on Archimate, which is still not a good fit with the needs of UX work.

      I’m currently over in Central America, working with a small consortium here on creating a much broader platform that could model and manage these crosslinks, but even a prototype is probably several months away at least, so for now you’re best to stick with the limitations of Archimate.
      Hope this helps? – good luck, anyway, and please do keep in touch on this.

Leave a Reply to Pat Cancel reply

Your email address will not be published. Required fields are marked *

*