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.
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:
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.
I do not think that Web Shop is an Application Service. If yes, than a Branch Office should be business service too. I suppose that both are locality or “business channel” where business services are provided.
An application in ArchiMate is modelled as 4 elements: application component (the ‘acting element’), application interface (the way the actor can be interfaced with, what is externally visible of that actor). The behaviour of the application component is the application function, and what is externally visible of that behaviour is the application service.
So, the post does not say that the Web Shop is an Application Service. It is an Application Component which has an interface, and behaviour and externally usable behaviour (or service). [Web Shop] Application Service means ‘the service that is provided by the web shop application’.
Your branch office in ArchiMate terms is a Business Actor, which can be assigned to a Business Role, which is the same ‘actor’ at the business layer as the application component is in the application layer. Such an actor can be responsible for providing a service.
You might want to study the free syntax excerpt of Mastering ArchiMate to understand how ArchiMate uses these terms. See the home page of the book.
Let me paraphrase you:
[Branch Office] _Business Service_ means ‘the service that is provided by the branch office actor’. Is it correct ?
I am sorry but for me it is a little confusing when the model (for instance in the last diagram) contains three different elements (application component, application function and application service) each with the same name ‘[Web shop]’. What is the sense of elements named like this ?
If you agree that a service can be understood as something that benefits the customer, than the business service in this example is ‘to buy something’ and it does not matter if it is provided by the stone shop (business actor) or web application (application component).
BTW I’m not an ArchiMate complete beginner. I have read ArchiMate specifications and some available examples.But when I see examples like this, I’m always going uncertain if I understand the concepts and their purpose.
I would say that the ArchiMate standard itself is not the best way to learn the language, as it s written not for its didactic qualities but as a reference document. I can suggest a good book, for which a free syntax excerpt is even available (see menu at the top of this page…)
Howe much I like to help people by explaining ArchiMate, this is not the place to answer all your questions about ArchiMate, e.g. what the use is to have 4 elements that make up a single ‘application’ (regardless of the names used in this example). If you have questions after reading the syntax excerpt (or the book) you can always contact me.