In a previous post, I asked What is wrong with this picture? It was a diagram about a bank offering a telbanking solution to their customers. I asked readers to try to find the problem and within a day or so they did. Here is the expanded story.
Let’s start with the picture again:
And the explanation that came with it:
A bank offers the product ‘Telebanking account‘ to its customers. Opening an account as well as application support (i.e., helpdesk and the like), are modeled as business services realized by the ‘Customer relations department‘. As part of the product, the customer can make use of a banking service which offers application services realized by the Telebanking application, such as electronic ‘Money transfer‘ and requesting ‘Account status‘.
First, let us redraw the diagram without Nesting and with more extended labels to make matters more clear:
Now, we expand the derived relation from Application Services to the Banking Business Service:
This makes it clear that as modeled, the Application Services are used by a Business Process of the Bank’s Employees, not of the Customer Business Actor.
Now, might this still be OK if we would say that the Banking Business Service is a Business Service performed by an automated Business Process so we don’t model Bank Employees using the Telebanking application instead of the Customer? For that we would have to add an Assignment from the Telebanking Application Component to the Provide Banking Business Process:
I renamed the Business Process and Business Service to ‘Automated Banking’ so it is clear what is being offered. This would in fact be the pattern that I have put in Mastering ArchiMate as the pattern for automated business behaviour, but not quite with that intention and certainly not with the idea that via this pattern the Application Services are still exposed to the user of the (in this case Banking) Business Service. So, I have removed the Application Service from the Product Aggregate. If I Nest that, I get:
And we have a Product that is purely defined at the Business Layer. Actually, we can leave the Application Services out of this picture as they are not longer relevant for our model of what we offer the customer: it has become ‘internal detail’. So we get:
This is a clean solution, but it hides the core of what the Customer gets: the use of the Telebanking environment. If we want that in and we want to stay close to the original diagram, we could do this:
Where the Automated Banking Application Services is Composed of the Account Status and Money Transfer Application Services. We now have that overall element that was in the original diagram. Un-Nest it and it becomes:
I personally think this Composite doesn’t really add something useful. We can leave it out and get:
And if we Nest that we get:
Which — if I wanted to model the original diagram, and with the Contract added — would probably be my preferred solution.
You can wonder why the original modeller wanted that Banking service on top of those Application Services? Was he or she maybe unhappy with the idea that the Application Services had no representation at the Business Layer? Maybe he or she should shave realised that the Application Services are used by the Business Layer of the Customer’s Architecture.
A bonus question: where did I find the original diagram? 😀
R&A IT Strategy & Architecture 
ArchiMate 2.0 Specifications, 3.4.4 Product
http://pubs.opengroup.org/architecture/archimate2-doc/chap03.html#_Toc309639742
🙂
Still, the diagram was not ‘wrong’, was it? Merely ambiguous…
LikeLike
Sometimes it is just the label that is wrong. E.g. in 3.2.1 of the standard, the Business Process that is performed by the Travel Insurance Seller Business Role is labeled Take out travel insurance. But “taking out insurance” is informal English for buying insurance, not selling it, as far as I know.
In this case, it is not just the label, it is in the structure of the model. Here it is like: “the doctor eats the patient’s medicine”. I think that it is not ambiguous, but wrong.
LikeLike
It seems to me that the debate relates to the understanding of what a ‘product’ and what a ‘service’ is. I prefer the original diagram – though I’d see ‘Banking Service’ including all blocks, apart from the customer – who consumes the service.
To me the items you label as ‘services’ are not really services in their own right, at best they’re ‘supporting services’ to the overall ‘Banking Service’.
This is important from the point of view of governance. The Board of Directors should know the value/cost ratio for the overall ‘Banking Service’, but they ought not to be concerned about the details of the supporting applications and processes.
The Service Portfolio ought to show the ‘Banking Service’ to the business, the internal components should only be visible to those managing the service delivery and design.
The ‘Banking Service’ being a product is a bit of a red herring – yes, it is a product, but it is a service product.
LikeLike
The problem is not with what a Product or Service is, as far as I’m concerned.
The problem is that the model suggests that not the Customer uses the Telebanking application, but that the Bank uses the Telebanking application. If you want to make it really complete, you should try to add the Application Interface (GUI) to the Telebanking application and then draw a Used-By to the Role that performs the Banking service Business Service. Given that the Bank’s process uses the Telebanking application (according to the original diagram), it is the Bank’s Business Role (assigned to that hidden Business Process) that uses the Telebanking application GUI. And that is plain wrong, because the Bank does not use that app, the Customer does.
LikeLike
I suppose that it depends on what you mean by ‘use’.. The bank uses the application to deliver a service to the customer. The customer uses that application to perform particular transactions. The bank uses the application to gather statistics, CRM data, trend analysis, and to manage demand and capacity – so it uses it for rather more functions than the customer, actually.
The model is, of course, a simplification of what goes on, so it leaves out a lot of this stuff, as it ought to. I think, though, that the important relationship is between the customer and the service – if the service meets the customers requirements, preferences and perceptions, then it will deliver value. The application might be replaced with another one, but the service will continue. The design ought to be at the service level, not at the application level.
LikeLike
I’m afraid I don’t agree with you. Though I think you can define ‘use’ as you do in natural language, its meaning in ArchiMate is in my opinion more precise. As you use ‘use’, it is more like ‘requires’ as in “the bank requires the application service to be able to provide the business service to the customer”. Just because of that, I think we have the possibility to add Application Services and Infrastructure Services to Product.
From the spec: Used by relationships, between application service and the different types of business behavior elements, and between application interface and business role. These relationships represent the behavioral and structural aspects of the support of the business by applications. It is impossible to prove you wrong (so this is really interesting), but I think you stretch the meaning of ‘use’ (or ‘support’ in the text from the spec) too much.
Furthermore, if that same application is used for statistics, etc., these are separate application services (other than Account status and Transfer money) which can indeed be used by the appropriate processes of the Bank. But that does not mean that the bank transfers money from the customer’s account using the Money transfer application service.
LikeLike