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.
R&A IT Strategy & Architecture 
“I’m leaning more to Assignment […] because I like to show the relation of ‘who’ performs ‘what’.”
That’s funny because for me “performs” is more linked to the realization than the assignment. The assignment (IMHO) is more about ‘who’ provides access to ‘what’.
This leads me to an open question: is it meaningful to have an (application) component composed of an interface assigned to a service realized by a function assigned from *another* component ?
LikeLike
You need to provide a picture for me, I had trouble understanding. If you get me the picture, I’ll add it to your comment.
LikeLike
Here it is:
The point is on the top Group (meaningfull?). I’ve added below the “meaning” of realization and assignment derived relations.
Basically, the question I am asking (to myself) is: are ‘A’ and ‘B’ the same, potential composed part of another Application Component or 2 separate things ?
LikeLike
This can be meaningful if your Application Service is in fact an Aggregation of multiple Application Services, which some abstract to modelling one Application Service that is Realised by multiple Applications Functions of multiple Application Components. I don’t like that for various reasons.
In case of your portal, you might also consider looking at the portal as an infrastructure element that supports the applications. That has some drawbacks in current ArchiMate though.
LikeLike
Maybe I should provide also an example of potential such situation I have in mind: Let’s imagine a company offering services using web tools. In such simplified case, the web UI is the Interface and is part of the underlying Application Component realizing the function/service. Now, imagine that this company has a lot of such applications to the point it becomes really had to find them for a user. This company decide to create a kind of web portal that will encapsulate original web UIs (using iframe, web portlet/gadgets or whatever technology). Obviously this portal is a service by itself and has an Interface, but one could argue that this Interface is also the Interface for each of the other Component, leading in the pattern I draw on top of my example (component ‘A’ is the portal, component ‘B’ is a web tool).
Here is a model snippet:
I’ve shown 2 potential way of modelling service usage:
In breen, what seems to be how the end user see it: he uses (through some process) the portal which in turn uses the web tool UI. This makes sens from an IT point of view (the portal includes/merge/uses the web tool) but not really from a process point of view as we loose the information that this process needs this specific web tool.
In blue, what seems to solve this issue: the process uses the web tool which in turn uses the portal service. But from an IT point of view, there is a derived used by relation from portal Interface to web tool service, which doesn’t make sens.
That’s why a potential solution could be the following:
LikeLike
Is there a reason you do not Aggregate the web tool interfaces/services in the portal interfaces/services?
LikeLike
“This can be meaningful if your Application Service is in fact an Aggregation of multiple Application Services”. Yes, that could do the trick but is somewhat problematic for automatic analysis (the aggregation doesn’t permit to derive relations in this direction, so this requires some specific tooling features).
“you might also consider looking at the portal as an infrastructure element that supports the applications”. In fact that’s how I model it today though my case is a little bit different as it’s more linked to web applications hosted internally (no cloud for me) and published through a reverse proxy. The issue I see (thus my question) is that it’s ok if there are no real user interractions, but otherwise (users change their password, manage favorites…) it is an application by its own.
“Is there a reason you do not Aggregate the web tool interfaces/services in the portal interfaces/services?”. No, except I usually try to avoid such situation because of the strange derived relationships this implies. But in this case this seems a good solution.
LikeLike
So coming back to my initial remark, The choice of a realization or an assignment between Application Component and Application Service can be influenced in such situation depending on what you consider the more important to show: how service is accessed (assignment) or how service is performed (realization).
The funny thing (at least for me) is that this is quite the opposite of the assignment between Application Component and Business Process (in this case the meaning is performed). This is maybe something to enhance in ArchiMate, as having different meaning for assignment between active and behaviour can lead to misunderstanding.
LikeLike
I think you should not see Assigned as ‘how a service is accessed’. What Assignment means is ‘who performs the behaviour (in this case of the service)’. Realisation is the view that a service is (separate) external behaviour that is realised by internal behaviour. So: the other way around and there is no difference with the Assignment from Application Component to business behaviour. I’m going to post a Dear TOG letter about this soon.
LikeLike
“I think you should not see Assigned as ‘how a service is accessed’. What Assignment means is ‘who performs the behaviour (in this case of the service)’.”
IMHO this is the same seen from different angles (outside-in, inside-out) : the service is accessed through who/what performs it. This is really close at business layer because interfaces are usually used to distinguish communication channels but at then end this are humans from (often) the same team. At application layer this is more blur/cloudy to me: in my example, I would not say that the portal performs web-tool service but instead provide access to it. I fully agree that this is far-fetched/borderline but I see a subtle difference (am I the only one ?).
LikeLike
That te portal provides access to the web tools is true. But isn’t natural language bewitching us here? What is it that the portal do? What is its behaviour? That is what the portal does. So, while the behaviour of the portal in natural language provides access to the behaviour of the web tools, the portal system performs the behaviour that makes that possible.
You could als for instance model that the web portal service is used by the web tool function.
LikeLike
“That te portal provides access to the web tools is true. But isn’t natural language bewitching us here?”
I don’t think natural language is bewitching us (maybe my -bad- portal example makes you think it). I was more refering to the definition of interface : “An interface is defined as a point of access…” thus the idea that when using a derived assignment we choose to emphasise the fact that the component contains the interface (hence my personal choice of “provide access” label) where at the opposite when using a derived realization we choose to emphasise the fact that the component contains the function/behaviour (hence my personal choice of “performs” label).
To be honest, until recently, I almost never modeled interfaces but started to do it because several “shared infrastructure services” are made accessible through dedicated DNS aliases (this allows us to change the underlying infratructure without -too much- impact on applications configuration). Thus I now use (in this case) Interface as a way to model the DNS alias used to expose (provide access to) a service. This leads me to (I hope) a better example: in a typical Oracle RAC environment, you have several nodes on which DB processing is done, but in order to access them you have to connect to a listener which usually does not run on the same nodes. So if I’d had to define a kind of “High Availability RDBMS Service”, I would model it realized by processing nodes, but assigned to listener nodes. Of course this appears only because here I’d want to model a single, high-level, service and not the real infrastructure details.
“You could als for instance model that the web portal service is used by the web tool function.”.
Of course I could, but this won’t be funny and leading to a whole bunch of metaphysical questions 😉
LikeLike
I still think there might be some cross-over between the general meaning of “point of access” and what ArchiMate means by it.
It is good to remember that ArchiMate splits behaviour from who performs it and to have a complete representation you need both. So, the portal can be ‘a point of access’ but in ArchiMate terms if you model that as an Interface you should also be able to define the corresponding Service.
LikeLike
Copied from my reply in the Archimate LinkedIn group:
An excellent decomposition of the problems with the original pattern. I very much like the way you chose to model your interpretation of the pattern.
Overall, I think your pattern highlights something I’ve been pondering quite a bit lately. In fact, it felt like you *almost* touched on it when you said:
“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.”
This is obviously correct, but I think talking about it as an either/or misses one of the more powerful aspects of using Archimate as a language for a *model* rather than simply as a language for a *diagram*: the support for multiple viewpoints of the same architecture for various audiences. I think your rich business service pattern is a wonderful opportunity to highlight the strengths of this approach. The “Product” view wonderfully captures the business intent but lacks the specificity of the more precise “Technologist” view you describe in the quote above.
Personally, I’d keep the Product view at the simplistic level of your pattern. I’d then take the “Technologist” view to a level of detail that is more helpful for implementers and detailed designers to leverage. While we have many examples for the various viewpoints in the specification, I think one of the things we current lack in the Archimate community is examples of these multi-view types of patterns that really highlight the advantages of both the Archimate language and adopting it within a robust modeling environment as provided by Archi or the various commercial tools.
LikeLike
I agree Andy. In my book and blog I’ve mentioned an issue related with this: when you add a lot of these different approaches to a single model, analysing a model becomes more and more difficult. The more constructs we put in our models to make them rich, the more difficult analysis becomes. Hence, the choice about what to model and what not (regardless of what we show in views) is a trade-off that in my opinion can be steered best from a usage perspective.
LikeLike
Thanks for your post! It got me thinking about the a possible to the service design (as in design thinking) discipline.
I’m currently thinking about how to link service design models (customer lifecycles, customer journeys and service blueprints) to our EA models using ArchiMate. This would enable creating a “customer viewpoint” based on business actors (personas or unique customers) or business roles (generic customers). The benefit of this would be that enterprise architects could easily communicate the “customer outcomes” (or using ArchiMate concepts: “goal” from the Motivation extension) of projects.
A service blueprint which incorporates multiple channels which are different service types (business service or application service) might look something like this:
I really like your last picture as it shows how we could map services to service types (channels). However service blueprints attempt to show how customers interact with our organizations. This requires elements such as:
– The customer lifecycle – this is essentially a customer value chain (f.ex. aware – join – use – develop – leave)
– The customer journey – this is a linear customer process with a service which a unique customer goes through (visit site -> pay -> gain access -> use)
– Touchpoint – a step in a customer process which is done within a service which is provided with a single service type (f.ex. H2H business service or mobile application service)
We can use ArchiMate elements such as “business processes” to model the “customer lifecycles” and “customer journeys”. Or could “customer steps” be “business events” because they often trigger business services? Could business and application services could be used to map “channels”? Could business interfaces and business interactions could be touchpoints?
I’m thinking about a “service blueprint” with the following hierarchical layers which could be mapped to each other:
Customer “process” (for customer lifecycle)
Customer “goals” (for outcomes)
Customer “(sub)process” (for process steps) or “business events” (linked to customer lifecycle)
“Business interface” or “business interaction” (touchpoints)
“Business service” or “application service” (channel)
Product (service)
Capability
Any thoughts on the ideas above for making a “service blueprint” for enterprise architecture purposes? What type of template or diagram would you favor?
LikeLike
I’m very sorry. You raise good points and interesting ones too, but I’m currently too busy to react in full. Quick reply:
– I would suggest also to have a look at this one: http://masteringarchimate.com/2013/09/11/what-is-wrong-with-this-picture/ as it raises the question of what a a business service is, especially when it is delivered by automation (such as a web site). ArchiMate is somewhat ambigu on that.
– Linking various ways of modelling is important in the sense that one should make sure they all tell (part of) the same story. These blueprints such as you sketch them are interesting, but they are more an ontology than a model. I would probably prefer having a model behind such a template instead of the other way around as it is more powerful.
LikeLike