In the post What is wrong with this picture? I showed a pattern devised by an enterprise architect to model the standard services they want to provide to customers. The idea of such a service is that is is largely some sort of web service where you can for instance get some data or some calculation. An example would be a calculation service to calculate net wages from the wages, in other words, do tax calculations. Of course, such a service also includes support, e.g. a help desk for if something has gone wrong.
His pattern was interesting, to say the least. Let’s see what was wrong with it and award the prize:
Here it is again, but with some parts highlighted so I can easily refer to them:
Let’s start with the relations I’ve marked red. These are not allowed in ArchiMate. I asked in that previous post which pitfall mentioned in Mastering ArchiMate was shown here. The answer is: Don’t trust your tool. He created his pattern with a professional (and certified) ArchiMate tool, but his tool allows relations that are not allowed according the standard. Often this is an error of the tool, but there sometimes is a cop-out: according to the standard, you are allowed to ‘extend’ ArchiMate. Not in this case, though.
But even for those relations that are syntactically correct (and tools do check that, unless you use just a drawing tool such as Visio or OmniGraffle) you cannot trust the tool to guard against meaningless or wrong representations of what you intend to say.
Tools are limited. For instance, tools often have a neat trick: just draw a relation and the tool selects the most likely one to apply: a ‘magic connector’ to help you out. Such ‘magic’ tricks look nice, but the experienced user does not need them and inexperienced one might use it as a band-aid for not quite understanding the language, which often produces incorrect results. You wouldn’t trust your wordprocessing software’s spelling checker to decide what is meaningful in a language you don’t really speak, would you?
The orange relations are syntactically correct but semantically wrong. They mean quite something else than he had in mind or — in case of the Association — don’t really mean something specific at all. The blue one is the wrong way around. The violet ones could make sense, except that it is unclear why they run in both directions. My guess is that he wanted to model information flow, in which case maybe the Flow relation would have been more appropriate, maybe?
Interesting about his pattern is that nowhere we can see that the customer’s IT is using a web service we provide, which is the core of the whole setup he wants to model.
Anyway, there is way too much wrong here. This architect is using ArchiMate elements and relations in a completely random manner. His idea is that he is being pragmatic. My idea is that this is indeed the case, but that the result looks like ArchiMate but is as much ArchiMate (or useful) as “Digging one hope nice interacted, frangible but Pete tweaker blob” is English (the spelling checker did not complain once!). Pragmatism is fine, but at this level he is better off not using ArchiMate.
So who gets the prize? Richard Jarvis for:
“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’”
Let’s end in a productive way. Suppose we wanted to help him with his pattern. What should we tell him? There are of course many, many ways to model this in ArchiMate (it’s a language after all). Let’s start with showing him the two core parts of his elemental service.
After all, there are two services we provide to the customer. The technical service and the support service. Note, I’m using some shortcuts (derived relations). Note specifically the one between the web site Application Component and the Data/Compute web service. You can use both Assignment and Realisation there. Most people use Realisation. These days I’m leaning more to Assignment (derivation of the route via Application Interface) because I like to show the relation of ‘who’ performs ‘what’. The same would be possible on the left side if we had modeled the Business Role that performs the service instead of the process. But generally, we want to show the process.
Anyway, if we want to be complete, there are three ways we serve the customer. We provide a human help desk, we provide a website and we provide the actual IT service. All three of them together make up the Product we offer to our customer.
As I said, this is just a single way of doing it. We could for instance be a bit more precise on the customer’s end and drop the use of the Product by specific uses of the services that make up the Product. After all, the current picture is not quite correct as it suggests that some sort of human is using the Data/Compute service.
With regard to the input/output we might add them like this:
One element less than his pattern and three clear sub-patterns of use. A good start, I think. Finally, note the violet Used-By. Suppose the human help desk also uses that same web site? Then this is the way to show that in the pattern.