Modelling Self-Service in #ArchiMate

I wrote a post on Chess and the Art of Enterprise Architecture about ways to look at self-service from an architectural perspective: “I, Robot” – there is no such thing as ‘Customer Self-Service’.  In it, I argue that saying that the customer performs part of your process is not the best way to look at it and that, instead, it is an example of the advance of `robots’ in our society. In the blog, I illustrate the story with a few simple ArchiMate views, in this post, I go into a little bit more detail on the ArchiMate side and we will go into the strange effect the standard layering in enterprise architecture (business, applications, infrastructure) may have now that we enter a brave new world of ‘automated actors’ (or robots).

I suggest you read the other post first for the background (so I don’t have to write it twice).

If you’ve finished reading it, we start with a classic setup of a simple process. You sell something to a customer. E.g. you might sell things over the phone or in a real shop. Your process is that the customer makes the deal with a Sales Clerk, and then the Order Entry Clerk puts the order in and let you pay, after which the company Courier is employed to send the product to wherever the customer wants it. In a very simple view, it looks like this:

As you can see, this is slightly different, because I am more precise about triggering. There might be a flow between Show Inventory and Create Order, but one does not by definition trigger the other.

Now, the people who argue that you have outsourced part of your process to the customer say (e.g. I’m quoting Samuel Holcman here):

When you make a purchase of […] a company online, you probably consider yourself a consumer or customer but, if youthink of it, you also assume the role of “order entry clerk”. By making the purchase experience “self-serve”, the company you are buying from has actually outsourced the role of order entry clerk to you.

Modelling that gives me:

But, if you follow the line of that other post, it is better to see the seller employing a ‘robot’, so it becomes:

To look more in detail to the ArchiMate modelling, we could ask ourselves: “Where, then, is the customer?”. Well, we could add the service we are offering and show the customer using that service:

It is perfectly allright, but it does not convey an important aspect of the situation as it does not show the customer actually using the web site.

In the ‘customer performs part of our process’ pattern, using the web site can be added simply:

This is kind of nice, because it clearly shows ‘self-service’. The Ordering Business Service offered to the customer is Realised by the Create Order Business Process that is performed by the customer. In other words: truly self-service.

The odd one in the view above is the Ordering Business Service, though, not the Business Process Create Order (that is perfectly fitted to the role of customer) but the Business Service. We are now not showing that it is us that serves the customer, whereas in reality, without us being available to serve the customer, the customer could not create an order at all (this is one of the issues with the self-service pattern, it does not show the role of the seller — us — very well). So, we promote the web application’s service and lose the Ordering Business Service:

The red Trigger relation is not allowed in ArchiMate (which I think is a restriction it should lose as triggering happens all over the layers, e.g. a server crashing may trigger a business process), so to keep showing the triggers we must draw them from Business Process to Business Process. By the way, yes I know it is weird that a Sales Agent shows inventory while the order is a web site, but please bear with me, this is about patterns, not about real situations.

It might help to make a more fully fleshed-out description first, before we go back to a simplified view:

What I have done is clearly separate the behaviour of the customer (his responsibility) and our behaviour (our responsibility). I’ve added a Product element to show what it is we offer to the customer. Our behaviour is partly automated. Now, I am using Business Services only for human behaviour and directly couple automated services, following the story in this earlier post.

This time, however, we will be going much deeper into one of ArchiMate’s intricacies. Because ArchiMate’s way of linking the application&data layer to the business&information layer to show automated processes is a shortcut, and maybe even a messy shortcut. There are in fact two ways we can show that the customer’s behaviour uses our behaviour in this case. One is, the customer uses our web shop (Application Service) , as directly above. The other is the customer using our (abstract) ordering Business Service, such as in the fourth view from the top. Both together look like this (the red Trigger is still illegal in ArchiMate):
The customer behaviour uses our application behaviour is the pink + orange route. The customer behaviour using our business behaviour is the blue + orange route. They are both correct in ArchiMate terms. In fact, they exist side by side, because they are two different ways to look at the same.

Interesting is what to do with the Application Service if you do not model the use of the Application Service by the customer’s behaviour directly (the orange Used-By following the pink route).  To model the dependency of the Self Service Shopping (Business Service) on the [Web Shop] (Application Service), I suggest in the book the use of a Used-By for the green line in the above view (Section 28.2, View 327 on page 189). But in that earlier post I pointed out that this wrongly suggests that the seller is using the web shop instead of the customer.

If we want to keep modelling in different abstractions (the common layering approach of enterprise architecture, which was born in a time of rigid infrastructure and humans using applications in non-automated processes, all of which are not true anymore), at least we should adapt ArchiMate to make a true representation at the business layer for robots, as I suggest in Section 28 of the book.

Warning: this is not valid ArchiMate (it is just something I would like). We create two different concurrent views on what is going on. From an application view, we can see that the customer’s process uses our web shop application, from a business perspective, we see that the customer is using our robot and we do not need to add applications as actors to the business perspective as we have robots.

Now, we can create two separate perspectives, a clean business perspective:

and an application perspective:

We can simplify these more. Business perspective:

and application perspective:

Conclusion

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.

[Update 11/Feb/2015] Tom Graves has written an interesting follow-up on his blog: On Modelling Self-Service With ArchiMate.