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?