It is time for another one in the “What’s wrong with this picture?” series. This time, I might maybe better have called it “What is not wrong with this picture?”. Here is the story.
A company I know has started to use ArchiMate a few years ago. Now, they found all these different relations and elements of ArchiMate too complicated, so,to keep things simple, they initially decided a while ago to model their system landscape according to this pattern (here represented in the Mastering ArchiMate colour scheme):
This is accompanied by a document somewhere that explains what the numbers mean. E.g. ‘1’ might be a daily batch job to send an export of System X and import it in System Y. ‘2’ may be System B calling a web service of System A, et cetera.
After a while, they found out that this was simple to model but hard to use. There is too little information in the structure to help them analyse dependencies etc.. In fact, what they were doing, they could have done in a simple graphics program such as Visio, they neither need ArchiMate, nor their professional ArchiMate modelling tool for this. (Actually, I know they were warned about this, but they thought the people warning them were making trouble out of nothing and making life far too complicated…).
Their attitude to the language is the extremely pragmatical one: “we are not overly concerned (frankly, not at all) with ArchiMate’s definition of elements and relations, we are using it to get a message across as simple as we can and for that we use it as we like”. As an aside: this attitude towards complexity & simplicity is described in Chess and the Art of Enterprise Architecture as one of the reasons for the lack of actual success of today’s ‘best practices’ in EA, but I digress.
Still, something needed to be done to make their model more than just a set pretty pictures on the wall. So, they decided that they needed to show more about the relations between the different elements in the landscape. The starting point was that they want to model the new services they will be offering to the outside world. Their company wants to start to act as a ‘elemental services’ hub — as they were calling it, providing fundamental services within their industry. Such services are not just technical, by the way, the service is the whole that is offered to prospective customers, think of a combination of web services, telephone support desk for those services, etc., the full monty.
Their architect then contacted me. He told me that they wanted to model the interfaces between all these systems more clearly and that they were having discussions about the ‘business services’, how to model these (operations?, wsdl? one service? many?). Also, he wanted to know which elements to use: Business Service, Business Interface, Application Service or Application Interface.
Smelling a common confusion I asked him what he meant by ‘business service’. Because in engineering circles, it is quite common to talk about ‘services’ as follows:
- In software engineering, a ‘business service’ is often used as the concept name for a service an application provides to humans or ‘the business’.
- In software engineering, an ‘application service’ is often used as the concept name for a service an application provides to other applications.
In ArchiMate, these are both called Application Service. The engineers create a name based on who uses the service (as in their world, the provider is always a program). But ArchiMate’s concept names are based on who provides the service. This is a common confusion.
The architect then sent me the following image (here recreated in the Mastering ArchiMate look) which he had used to explain ‘elemental service’ to others. It was also what he had designed (with their professional ArchiMate modelling tool, mind) as the pattern to use for modelling:
Now, the question of course is (as before): What is wrong with this picture? His goal is to model everything that is needed to provide the ‘elemental service’ to other businesses. And for the readers of Mastering ArchiMate, the supplemental question is: Which pitfall mentioned in the book is demonstrated here?
Earlier “What’s wrong with this picture” puzzles here, here, and here. I’m only awarding a prize for entertainment value of the comments this time, as it is too easy to spot the errors.
R&A IT Strategy & Architecture 
“And so, children, just like in the story of the Shoemaker and the Elves, the company’s products were magically created without the staff having to lift a finger. And in their minimalist world they enjoyed lives of contentment, safe in the knowledge they had successfully transformed ‘UsedBy’ into ‘UseLess'”
LikeLike
Well, first and foremost, the external (Customer’s) Business Process certainly doesn’t realize the “elemental service”. That would seem to be the most obvious flaw.
LikeLike
I agree that that is the most obvious, it was also the first one I spotted. But it is not the worst 🙂
LikeLike
I would like to add two remarks:
Customer (consumer or corporate one) is finally consuming vendors service packed via product. Business service is external output of process, which is a governance of sequence of internal business functions. Be more correct is needed to model business service between process and product.
And IMHO process input / output are not equal business interface. Internal and external parties (actors in roles) are approaching functions of process via business interface (e.g. communication channels). In business layer inputs and outputs (things) are business objects.
LikeLike
I’d really like to know what their “professional ArchiMate modelling tool” is, because I can safely advice them to use Archi. Using it and it’s really usefull “Validator” would have shown that this diagram contains non standard relations, especially the realization between the Business Function and the Application Service (unless it was really needed to explain that in fact all their workers are robots…). Anyway, regarding the overall goal of this diagram (explain “elemental service”) I must admit I absolutly have no idea what this “elemental service” is doing, except that it is vaguely related to “Product/Service X”.
Regarding the “supplemental question”, I’d say the answer is.. All 😉
LikeLike
It is not that strange that this view does not make clear what the ‘elemental service’ is doing as this view is a patttern, not a real view. In a real view, the customer process would be named and all the other parts too, which is supposed to make it intelligeble what the service is.
This view is the pattern that the architect designed for other to use when documenting the ‘elemental views’.
LikeLike
He is using the used-by relations as a way to convey information flow and the realization relation for action flow (trigger), in the direction of the arrow…
So, he’s basically using the tool as a drawing tool, using the offered figures but with self-invented meanings.
LikeLike
I agree Carl; the Output (Business Interface) cannot be Used-By Product/Service X -(Business Product) either directly or as a derived relation. Taking a step back, that makes perfect sense; how could a passive business element perform an action?
As you say, they’re using Archimate as a drawing tool without understanding the implications of what they’ve ‘modelled’. I suspect they’re trying to use Used-By to represent information flow instead of the activity which causes information to flow.
LikeLike
Hello, I will repeat some of the already spotted problems, because I just want to analyse the diagram systematically.
Formal mistakes (not allowed relationships by ArchiMate grammar):
1. Relation “used-by” between Output Business Interface and Product/Service X is not allowed.
2. Business Function A cannot realize Application Service.
(Not many – seems strange, right?)
However there is a lot of misconceptions in the meaning of what author wanted to express (again from top):
3. The “Elemental Service” should be Used-by “Customers process” (not realized)
4. Relation between “Elemental Service” and “Product/Service X Business Product” is too week. The “Elemental Service” should be aggregated by a Product element to make it clear that when you buy a product you have access to the service.
5. The “Elemental Service” should be realized by “Product/Service X Business Process”
6. The Input and Output Business Interfaces should be replaced by Application Interfaces, as I think those are either “human webpage interfaces” or APIs of automated “Product/Service X Business Process”.
7. Continuing, those Application interfaces should be part of some new Application Component (composition)
8. Application Component should by assigned from “Product/Service X Business Process” to show who is performing the process
To sum-up points 6-8 move us closer into fully automated business process pattern described by Archimate.
Now, what to do with “Business Actor” and his “Business Function A” ?
It was said in introduction, that company provides also “human” services (like phone support etc.), So I think that “Business Function A” should realize new Business Service element, which would be a part of (aggregation) “Product/Service X Business Product” (probably some relationships between this “manual” process and automated “Product/Service X Business Process” exist).
I also noticed that realization relationships on the diagram in reality mean “Uses / depends on”. So, Application Service should be used-by the “Business Function A” to realize this new Business Process. And Application Component should realizes (in ArchiMate meaning) the Application Service. Of course I suspect that Application Service is in fact webpage interface for humans, so another elements would be need (or advised) here.
Also, the closed “used-by” circle of Product, Input interface, Product X Business Process and Output interface looks like author wanted to express some information flow, and not only the structure. The same applies to Used-by relations with A and B Business Functions.
BTW: there is not such thing as Business Product in ArchiMate 2, just Product 🙂
LikeLike
I don’t contest your conclusions, but I think you are assuming this diagram presents a valid architecture description. I rather think the diagram represents a contextual framework, whereby a customer process is ‘fulfilled’ by an essential service, which ‘consists’ of a product that is iteratively ‘improved’ by ‘collecting’ input, ‘feeding’ it into some process, the output of which is fed back into the product, etc… The process consists of passing information in and out of functions, some executed by humans, but ultimately ‘invoking’ services offered by applications.
In that sense it rather describes a secondary architecture in Gerben’s book, but using all of the ArchiMate’s symbols for entities and relations, but with none of the meanings… (except maybe for the assignment relationship)
LikeLike