On modelling ‘self-service’ with Archimate

In enterprise-architecture, how should you describe or model ‘self-service’ – in which the customer, rather than the organisation’s employee, uses the organisation’s systems to place an order, or search for information?

The classic way of looking at this is from an ‘inside-out’ view – or, more usually, ‘inside-in‘, where company staff are considered to be the only users. But that doesn’t work in this case: the customer is not only an ‘outsider’ relative to the organisation and its systems, but is literally outside of the organisation’s control.

Gerben Wierda – grand-master of modelling with Archimate, and author of ‘Mastering Archimate‘ and ‘Chess and the Art of Enterprise Architecture‘ – picked up on this point via a LinkedIn post by Samuel Holcman, ‘Inside Out vs Outside In Enterprise Architecture‘. Gerben’s first response was a post on his Enterprise Chess website, ‘“I Robot” – There Is No Such Thing As ‘Customer Self-Service’‘:

The issue [that Samuel Holcman] raises is that the clients of organisations more and more seem to become the ones that perform the organisation’s processes (e.g. self-service), and that they thus should be taken into account as parts of the architecture of your organisation. Some even speak about the ‘extended enterprise’ in that context. I have been disagreeing with that view for a while, and this is a nice occasion to put that in writing.

(I suspect that the “some [who] even speak about the ‘extended enterprise'” would include me, but that’s not a point I need to go into here!)

Within that post, Gerben laid out a handful of intentionally over-simplified Archimate models to illustrate that a simple substitution of internal order-clerk to external customer doesn’t seem to make sense in formal Archimate terms. Instead, he proposes that it makes more sense to say that the order is still actually placed by an internal ’employee’ – but a robotic employee in this case, as represented by the respective functionality of the website:

It’s not the customer that is acting in our landscape at all, he is just interfacing with us.

He then adds a few notes about the ‘big-picture‘ implications of such robotic-employees, which personally I’m very happy to see, but again don’t relate much to the point that I want to explore here. The point that I do want to explore relates to the admittedly quick-and-dirty Archimate model with which Gerben ends up in that post:

Archimate: Robot Service (c) Gerben Wierda

What we have here, in effect, is a computer-based application – an Application Component, in Archimate terms – as a direct substitute for the human Business Role of Order Entry Clerk.

Stop and think about that for a moment, in terms of the classic ‘BDAT-stack’ (‘Business’, ‘Data’ plus ‘Applications’, and [IT-specific] ‘Technology’), as used in Archimate, TOGAF, and darn near every one of the mainstream ‘enterprise’-architecture frameworks:

What I’d hope you’d notice from that cross-comparison is that everything in Gerben’s diagram above is, in classic terms, part of the Business Architecture layer: Gerben’s ‘Robot’ is a direct substitute for a Business Role. But yet the BDAT-stack says that it can’t do that, because applications can only be in the Data/Applications layer. So the Robot is kind-of in both layers, but also in neither, both at the same time…

Gerben being Gerben, he spots that problem straight away – hence the follow-on post on his Mastering Archimate website, ‘Modelling Self-Service In Archimate‘. And quietly demonstrates, through a series of descriptive diagrams, that the current version of Archimate simply will not allow us to model this now very common business-pattern. Not in any Archimate-‘legal’ way, anyway.


Again, Gerben being Gerben, he shows that once we do allow certain adjustments and adaptations to the Archimate syntax, we can sort-of just-about make it work – though all of it is somewhat of a kludge, and even then perhaps only works as long as we stick to an strict IT-centric and organisation-centric view of the context. Yet as he also shows, and highlights, there really is no way to get round the fact that in that scenario, one of the Business Role entities is actually what he calls a Robotic Role – but in a place which, according to the Archimate layering, can only be done by a human. Hence, as he says in the Conclusion section to that post:

The common layered approach of enterprise architecture, also part of ArchiMate, is creaking at the seams. Applications are used as robots at the business level. And the infrastructure layer is currently transforming to software-defined anything. We might need a wildly different approach for this brave new world.

To which I would strongly agree…

Yet I’d actually say that we need take it even further than that – a lot further. That’s because, in reality, “the common layered approach of enterprise architecture” is a truly horrible mess of arbitrary assumptions and arbitrary conflations:

  • Business‘ = anything-human + anything-relational + principle-based (‘vision/values’) decisions + higher-order abstraction + intent
  • Applications/Data‘ = 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)

(It’s even worse than that, because in most variants of ‘the common layered approach’, we can’t even describe any technologies other than electronic computer-type IT.)

The result, as I’ve described elsewhere, is that it’s always been all-but-impossible to use ‘the common layered approach’ to describe even quite routine enterprise-architecture concerns such as business-continuity/disaster-recovery or data-centre design – let alone the kind of concerns I regularly deal with in my own work that address physical-technologies and multi-channel  transmedia business-models and the like, or upcoming technologies such as programmable hardware and smart-materials. Yet as Gerben shows, ‘the common layered approach’ is so limited and constrained that it can’t even handle current IT-based business-models such as an e-commerce website, where an Application inherently also acts as a Business Role.

Hence it’s not that ‘the common layered approach’ is “creaking at the seams”, as Gerben puts it: instead, it’s more that ‘the common layered approach’ is completely broken, at a fundamental level, right down to its deepest rootsand always has been. Yes, at one time it might well have seemed convenient, from an IT-centric perspective: but even back then, it was an IT-centrism that merely reflected certain arbitrary unquestioned assumptions about the nature of the IT of that time, which were all but guaranteed to fall apart at some future point in time – which is exactly what’s happening now. For any architecture that’s needed to centre around anything other than that classic ‘big-IT’ – an “anything other” that happens to be perhaps 95% of any real ‘architecture of the enterprise’ – that ‘layered approach’ was always the wrong way to do it: a fact that we, as a discipline and profession, we really do need to face right now.

Yes, I’d agree that the BDAT-stack, and ‘the common layered approach’ in general, has been useful in the past, and is still possibly-useful for certain decreasingly-common specialist purposes. For anything else, though it’s a chimera, a booby-trap riddled with potentially-dangerous delusions. Reality is that the BDAT-stack has long since passed its ‘use-by’ date: it’s time to drop it – and instead reframe our architecture-frameworks around the ways that all other architectures actually work. Please?

12 Comments on “On modelling ‘self-service’ with Archimate

  1. Hi Tom, the common layered approach is not so common when you look broader to other fields like e.g. cartography (GIS) and the design-build world (BIM). In those fields layers are used to overlay information and to aid with at least one of the following:
    • Data visibility
    • Presentation Techniques
    • Data Filters

    In short: ArchiMate screwed up its whole layers/views thing which leads to incomprehensible posts/discussions & diagrams like those on Gerben’s sites even when it’s about simple things as online shopping.

    Therefore my personal approach is similar to the mapmakers usage of layers, e.g. like the graphic overlay method as described on http://www.ou.edu/class/webstudy/fehler/E3/go/feature_extraction.html which is “modeling tool & language”-independent.

    And I always put limited trust in maps & models because I know that data sources (people/repositories) are often flawed, as the mapmakers interpretation of the data and the mapmaker’s intentions. So feedback loops and the ability to change maps/layers quickly is mandatory.

    • @Peter: “the common layered approach is not so common when you look broader to other fields”

      Yes, strongly agreed, in fact that’s my core thesis here – which is why I’d always put it in quotes above.

      @Peter: “In those fields layers are used to overlay information”

      Again, agreed. In the so-called ‘common layered approach’, it’s slightly different: what we mostly use it for is to exploring links between the views that arise from the respective single viewpoints (‘Business’, ‘Application’ ‘IT-Infrastructure’ etc).

      @Peter: “In short: ArchiMate screwed up its whole layers/views thing”

      That’s another strong agree from me, as you’ll see in my ‘Unravelling the anatomy of Archimate‘ blog-post referenced in the post above (link beneath text “right down to its deepest roots” above).

      (I would say, however, that, given the structural problems and constraints that Archimate forces upon him, Gerben does a great job for that specific context 🙂 – I don’t know if you’ve seen or read his book ‘Mastering Archimate‘, but I’m hugely impressed with it.)

      @Peter: “And I always put limited trust in maps & models … So feedback loops and the ability to change maps/layers quickly is mandatory.”

      Once again, a strong agree from me.

  2. Hi Tom,

    Nice story.

    I think ArchiMate *can* show that IT acts at the business layer, but the way it does it is a (messy?) shortcut: Application Component Assigned-To Business Behaviour. This approach may be considered somewhat of a kludge. I suspect it was chosen to keep the metamodel simple.

    My proposal for a ‘Robotic Role’ concept in ArchiMate (by letting applications realise roles) is in fact changing that cross-layer shortcut to a real representation of `acting IT’ in the business layer, thus in fact *strengthening* the layering approach in ArchiMate (so not to your liking, probably).

    As I wrote in a post linked in the post you link to (ugh!), we could do away with the layering entirely. We could create an abstraction that works more generic (based on the generic concept of a ‘tool’), and it will be possible to model also the physical side of enterprises more easily and we can more easily accommodate the actual changes happening, such as software-defined-everything (from infrastructure to business).

    I do worry that such an abstraction will be easy enough for certain types of people (such as us, as it is our line of work to be able to do such thinking), but it will be very difficult to get the rest of our environment along. On the other hand, if the ‘layer-less metamodel’ can be used to display layers (as illustrated there) we might be able to do both. And also on the other hand: the business is perfectly happy with BPMN-like languages, which have no layering at all.

    Maybe in the end the answer is that (BI)(DA)T is not necessarily broken, but that it is just best seen as a collection of viewpoints that may live side by side, instead of being a structure that underlies it all. A metamodel that does not have the layering as its core structure, but that is capable to show it might be needed.

    The biggest issue might be that our EA community is married to the layering-approach, and that changing that completely may be a divorce that hurts too much for all involved. For many, the layering is as true as reality, something so core to their thinking that they will not be able to let it go.

    • Thanks, Gerben.

      On ‘Robotic Role’, yes, the way you do it does work, for that specific context, and given the constraints that Archimate imposes. The catch is that it’s yet another ‘special-case’ in amongst far too many special-cases already: right down at its roots, the Archimate metamodel is ultimately built around that suite of arbitrary conflations (e.g. ‘Human’ is conflated exclusively with ‘Business’; ‘Role’ occurs only in ‘Business’, therefore ‘Role’ must always be ‘Human’), and in that sense your ‘Robotic Role’ is yet one more example that those conflations just do not work in most real-world contexts – even for IT-architecture, now.

      On “we could do away with the layering entirely”, I’m not saying that layering is ‘wrong’ and that we therefore shouldn’t use it at all. Layering is useful sometimes – especially when we need to describe interdependencies between elements that are visible mainly in distinct viewpoints (as in the contexts for which Archimate was originally designed). What I am saying is that all layering is an arbitrary choice – in other words, useful, not ‘true’.

      The problem with Archimate and TOGAF and their ilk is that they persist in purporting that the BDAT-stack or whatever is the only descriptors that we need, that that layering describes the totality for all architectures in the enterprise context – and that assertion is just plain wrong in the broader scheme of things, and hence actively misleading once we move beyond a very, very narrow big-IT-centric subset of the enterprise space. That’s the only key point I’m making: that if we’re to use layering at all – and it’s an option, not a requirement – then we need to have full flexibility in what we may choose as our respective ‘layers’. That’s all, really: the rest is just detail. 🙂

      On “A metamodel that does not have the layering as its core structure, but that is capable to show it might be needed”, that’s exactly what I described, in considerable detail, in the ‘Unravelling the anatomy Archimate‘ post. Perhaps have a look at that?

      On “The biggest issue might be that our EA community is married to the layering-approach, and that changing that completely may be a divorce that hurts too much for all involved”, we’re not actually asking them to let it go: as long as they’re working solely in the big-IT-centric subset of ‘classic’ EA, the BDAT stack will continue to work just fine for them, just as it always has so far in that context. The only thing we’re asking them to acknowledge is that it doesn’t work well (or at all) outside of that one specific type of context, and hence it now needs to be understood as a ‘truth’, not ‘the truth’ – and that’s all. Okay, ‘a truth’ versus ‘the truth’ is a distinction that may well be beyond the comprehension of some of the ‘newbies’ to the field – especially those infected by the TOGAF mistakes – but those of us who have been around and do understand such distinctions will be able to work across the full EA space without being crippled by a needless mistake from the past.

      What I’d described above is fully backwards-compatible with the ‘BDAT-stack’: they don’t need to change anything, within their own work. The only difference is that it allows us to break free from the arbitrary constraints of the BDAT-stack whenever we need to do so – which, increasingly, we do.

      • I read that ‘unravelling’ post a while back. While about ArchiMate 1, it does point out some serious issues.

        I do like the ‘practicality’ of the approach behind ArchiMate (as opposed to the formal one behind BPMN for instance), but there are some obvious (as well as non-bvious) improvements that can be made. ArchiMate is practical, but I would agree that parts of it are really ‘messy’.

        I think ArchiMate could be really improved if the ArchiMate Forum has the courage and the insight to do so. But that would in many ways not really be recognisable as ‘ArchiMate’ for many. And I think those now actually profiting from ArchiMate have a lot invested in the ‘old ways’. Still, I think I could come up with something that is true to ArchiMate’s essential simplicity, while being less messy and more ‘complete’.

        • Thanks, Gerben

          On “I do like the ‘practicality’ of the approach behind ArchiMate” – yes, agreed. The real problem is that it purports to be all that we need, and that it covers everything we could possibly need in EA – neither of which are true for anything other than a quite trivial big-IT-centric EA.

          On “Still, I think I could come up with something that is true to ArchiMate’s essential simplicity, while being less messy and more ‘complete’” – you know the answer to that, don’t you? 🙂 – go to it Gerben, you’re definitely the best man for the job! 🙂

  3. I’m glad to see we’re reaching a consensus that layered models don’t make sense (and are at best misleading) unless the thing they’re modelling is genuinely layered (i.e. the things in the layers are actually located strictly and exclusively in those layers, which isn’t even true for most IT systems). Peter offers examples of where it does work.

    Ironically this approach is not merely incapable of capturing real business relationships but makes it almost impossible to properly represent more recent IT developments, which live outside of the traditional it shop – most IoT stuff, for example. Compared with this, “self-service” is almost a trivial case.

    • @Stuart: “I’m glad to see we’re reaching a consensus that layered models don’t make sense unless…” etc

      Yep – certainly much more of a consensus on that than was possible even two or three years ago.

      (On “Peter offers examples of where it does work”, did you mean Gerben rather than Peter?)

      @Stuart: “makes it almost impossible to properly represent more recent IT developments, which live outside of the traditional it shop – most IoT stuff, for example”

      Yep. Those various people who’ve too often accused me of being ‘anti-IT’ had actually failed to realise exactly that point you’ve just made: that the BDAT-stack really only works for that tiny category of big-IT, that’s becoming less and less common these days anyway – and that what I’d been talking about was not ‘anti-IT’ at all, but the entirety of IT, and more, rather than just that one small subset.

      In parallel with IoT, I’ve long been interested in a fair range of other sort-of-IT-ish developments such as programmable-hardware (which blurs ‘Application’ with ‘Technology-Infrastructure’) and smart-materials (which often blur ‘Application’ with the physical material itself). We’ve been stack in the doldrums of the BDAT-stack for far too long: once we break out of its arbitrary unnecessary constraints, there are all manner of fascinating new realms that become open to us as enterprise-architects to model and explore! 🙂

  4. Hi Tom. I actually meant Peter Bakker’s GIS example.
    For IoT there are two scenarios that clearly don’t work in the BDAT model.

    One is the “programmable hardware” you mention. Many sensors and controllers fit that model and here indeed splitting application and infrastructure into layers is at best unhelpful.

    The other is the smartphone type of environment, where application can indeed be separated from infrastructure (multiple apps run on one platform) but data is (typically) not separate from application and where protocol handling is often built into the app and there are multiple levels of infrastructure and all this is typically communicating with the other half of the “business application” that runs in a traditional data centre somewhere and and and….. Representing all that as a series of layers is not merely inaccurate but downright misleading and likely to lead to incorrect assumptions and/or stupid architectures. And that’s without even starting to think about the B in BDAT. Rant over.

Leave a Reply to Peter Bakker Cancel reply

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