The direction of arrow of the Used-By relation is a constant source of entertainment and/or frustration, see for instance this (started by Sol Kahn, 37 comments) and this LinkedIn discussion (started by Michiel Perdeck, 40 comments). As the latter discussion shows, the frustration with the direction of ArchiMate’s Used-By may remain, it is not always a passing problem for someone new to ArchiMate. Maybe the following helps in the discussions about Used-By.
About the use of Used-By
I would like to start from the following scenario. We have three applications: TheProvider, TheBroker and TheUser.
- TheProvider at its own initiative provides an update to TheBroker.
- TheUser at its own initiative requests information from TheBroker
Looking at it logically, data flows from TheProvider to TheUser via TheBroker. TheUser depends on (data provided by) TheBroker and TheBroker depends on (data provided by) TheProvider. Seen that way, it seems natural to say that TheProvider is Used-By TheBroker and that TheBroker is Used-By TheUser. Let’s first focus on what happens between TheProvider and TheBroker. Technically, TheProvider takes the initiative, connects to a service provided by TheBroker and sends its data to TheBroker. Logically, TheBroker depends on TheProvider for its data. Technically, TheProvider will encounter an error when TheBroker is not available. Logically, TheBroker will function without technical problems, but with out-of-date data if TheProvider does not deliver. Now, ArchiMate doesn’t tell you which interpretation to take. Though ‘main ArchiMate founder’ Marc Lankhorst (see the discussions) prefers the ‘business view’ for everything Enterprise Architecture, the language also is able to support a more technical use. Here they are both. As it generally helps when discussing patterns in ArchiMate, we initially stay with the core metamodel, and we do not immediately use derived relations (such as Application Components Used-By Application Components). 
The upper row shows the technical approach: it is the TheBroker who provides the service and TheProvider who calls that service to send he data over. The lower row shows a more logical approach: TheProvider serves updates to TheBroker, whatever happens technically. Now, what often happens is that these details are not modelled at all. We might see something as simplified as (for both approaches): 
So, at least when creating derived summaries, you’re actually free to draw the direction of Used-By either way 😉 (I know, that doesn’t address the underlying criticism). But, keeping the direction of Used-By as a given, it does become a bit more difficult to understand the sense that the upper one makes, especially if we add TheUser: 
As I illustrated above: ArchiMate can do both, whatever your taste in how you want to model. If you prefer to model everything from the business perspective because you think that way you can communicate more easily to non-architect stakeholders (but see here and here), you should model it in the lower way. I personally prefer the upper way, because I use ArchiMate to clearly document what is going on in the enterprise and I leave the business view of things to the business layer and the technical side of things to the IT layer. So, my Application Services come in two variants:
- What the IT-layer does for the business (abstraction of IT from a business perspective as a link between the modelling layers). These Application Services are in my model Used-By business behaviour, such as a Business Process or Business Function. This more ‘logical’ use of Application Services is not shown in this post.
- How the IT-layer is constructed: Which application uses which other application. Here, my Application Services are technical: they show to the designers and builders what functionality they must deliver. It shows support engineers how the technical side of the landscape is set up.
Have a look at this column too. Towards the end I show the business dependency view and the technical dependency view in one go. Business-wise (and modelled in the business layer) the dependency as shown by Used-By runs in a different direction than technically (modelled in the application layer). So, you have to make a choice. My personal advice would be:
- Dependencies between IT components: use the technical approach in the application and infrastructure layers
- Dependencies between Business components: use the business viewpoint
- Dependency between IT layer and Business layer: use the Application Service as a way to define in business terms what the IT is doing for the business.
About the direction of Used-By, Trigger and Flow
Especially from software engineers, an often heard complaint is that the direction of the Used-By relation in ArchiMate is confusing (or wrong!!). I like the direction, because the directions in ArchiMate have one thing in common: they show ‘dependency’ coherently (not quite, but that is another discussion). The ‘dependency chain’ runs in te direction of the arrows (note: not always in the direction of the relation). And ‘dependency’ is what is (or should be) foremost in architects’ minds. Maybe de definition of an enterprise architect should be “complex-and-uncertain-dependencies specialist”. Marc Lankhorst stated in the discussion started my Michiel Perdeck: “For data flow and control flow, ArchiMate has flow and triggering, respectively.” And indeed that is true. Let’s first add Trigger relations, to show who takes the initiative. Have a look at: 
What I did here was add the core Triggers (in black) and two derived Triggers (in red). Remember: derived Triggers may move either end point of the original Trigger from the internal behaviour to either the external behaviour Realised or to the Assigned one performing the behaviour. See page 32 of the book. Now, the upper (technical) approach does not give us a problem. TheProvider Triggers the service provided TheBroker. In fact, when you model technically, you do not need the Trigger at all to show initiative, it always is the opposite of use (though it might run in the other direction too — think ‘stateful connection’). But the derived Trigger in the lower (logical) approach shows that the service triggers the function. Think about it: a service that triggers its user? It is the logical result of using the business-perspective approach while modelling the IT layer, but somehow, it makes my skin crawl a little. Maybe that is because I’m not an idealist but a (pragmatic) constructivist at heart. If we return to modelling the technical approach in the IT layers, and we add Triggers and Flows, we get: 
The Triggers are superfluous here. The middle Flow is interesting: it is derived from TheBroker Flowing to itself. Which is why it is maybe better to stay with the non-derived Flows: from Application Function to Application Function. So the end result is: 
The (structural) Used-Bys showing the technical dependencies including who initiates the use, the (dynamic) Flows showing the dynamic dependencies. Using the business perspective when modelling the application layer is technically not wrong. But I wonder if it is a good plan. After all, are we really using this to communicate with business stakeholders? The dislike of the direction of Used-By, mainly by software engineers and above all UML-adepts, strikes me as somewhat strange. Michiel Perdeck even appropriates the statement made famous by Uncle Edsger’s article “Goto considered harmful”, and turns it into “Used-by arrow considered harmful”. OK. Shall we discuss the plethora of various meanings of that single graphical representation in UML (directional association, control flow, object flow, signal, message, state machine transition, extend use case…)? In UML, that arrow is used for many things. The one in people’s head is probably a call mechanism. In pseudo-ArchiMate: function calls a service, instead of service is used-by a function. Now, ArchiMate’s structural relations signify dependency. That doesn’t fit ‘programming’ minds that are thinking of calling a service (which actually contains a dynamic element in its semantics). Maybe we should just tell them that they should use Trigger when thinking of the dynamics. Or maybe ArchiMate should switch the graphical representation of Used-By and Trigger and make the UML/software-engineering crowd happy… (That is not a serious suggestion, by the way.) So, come on, Michiel and friends, “Used-by arrow considered harmful“? Isn’t that not a bit overdoing it? I can appropriate Uncle Edsger as well: “The use of UML cripples the mind; its teaching should, therefore, be regarded as a criminal offence.” (Again, before people get angry: I’m joking). The direction of Used-By will not quickly change, it’s too much set. But Marc, in one of the discussions said that he would consider changing the name:
But I’ll see what we can do about the awkward ‘used by’ name. Achim just suggested ‘serves’, that sounds pretty neat and business-oriented to me.
Please don’t. Find something else that is not passive, but please keep it as neutral in the logical versus technical approach as Used-By is now.
R&A IT Strategy & Architecture 
What’s the issue with the ‘serves’ or ‘serving’ name instead of used-by? Why isn’t that neutral? Would something like ‘provides’ or ‘offers’ be better?
LikeLike
This is all rather subtle, so I might be nitpicking.
For me, serving is, more than using, about the effect of using (a bit of the value, if you will) than the using itself. He served himself a cup of tea by using the kettle. That kind of a subtle difference. You serve something (the something plays a stronger role as the effect). You use something (something is more what you use, not what the effect is). Actually, for cross-layer use, I think ‘serve’ as an explanation or a guideline for defining services is rather useful.
Using is more neutral for me, in terms of it can both be the act of using and the result of using (meaning comes from use). ‘Provides’ and ‘offers’ have the same (even stronger) problem as ‘serves’. I prefer ‘serves’ over them. But I prefer ‘used-by’ over ‘serves’.
In my experience, the term ‘used-by’ actually has a beneficial effect. It helps the programmer-types from a programming-mindset towards an architect-mindset. The frustration it brings for some is actually a good thing. It is part of the learning effect 😉
I’ve had comparable discussion with software-engineers about interface being an active element. In their world, active meant ‘taking the initiative’. They are constantly busy with behaviour of systems, so their set is active/reactive, whereas in ArchiMate it is active/inactive.
There is nothing that can be done about these kinds of differences, unless you want ArchiMate to become more like UML. I think what really helps is explaining this better.
LikeLike
We will improve the explanation in the next ArchiMate release, and probably also change “used-by” to something more active. It’s just ugly they way it is now. But a neutral term that doesn’t put the initiative at one or the other end of the relationship is difficult to find.
LikeLike
Pity.
I think it is unnecessary to change the name of used-by, it covers the role perfectly. It is also not ugly, it is very normal speech, but that is a matter of taste. Maybe it is ugly for the software engineers among us. They should get a life 🙂
Thinking that way you may also say that Assigned-To is problematic. What is Assigned-To? Between actor and role it is ‘fulfils’, between role/application component and business behaviour it is ‘performs’ and between node and artefact it is ‘deployed’ (but not quite). All these terms are better. Should we rename these too? I think not. An explanation is enough.
There are more important things that can be improved (but I guess my wishes will not be granted…)
LikeLike
I was thinking about ‘supports’, but I still like ‘used-by’ better. ‘Supports’ is too wide to my taste and it also is not neutral in the logical versus technical approach to modelling.
LikeLike
I think Gerben hit the core of the issue in saying that the relations, all, stand for (causal) dependency. Dependency is an asymmetric relation. The arrows that depicts it generally points to the dependent, and leaves from what it depends on. This immediately explains the direction of the used-by arrow.
This issue has nothing to do with business versus technical. The difference is that one paradigm differentiates between static and dynamic (the logistic/plumber’s paradigm), whereas the other (the functional one) basically doesn’t. You may have both options on business layers as well as on technical layers, even if ArchiMate does not offer them all at all layers.
If you would nevertheless want to speak about “initiative” in the functional paradigm, then the initiative is always is with the user, in the end. The point is, this initiative may happen at design time, invisibly in the model. To explain:
– Consider a request-response service. Would anyone deny that the initiative is with the user here?
– Consider a notification service. Even here, the initiative generally is with the user, since he will have subscribed to the notification service before the first notification arises. The question then of course is whether this subscription service is included in the model, or is taken for granted (at design-time).
– Even if there is no subscription service, then at least the modeller has decided that the provider be used by the user. In this respect, the modeler inevitably acts *on behalf of the user*, because the modeler *defines* the user to be dependent on the provider. So, if the provider wouldn’t be there, that specific user wouldn’t either. The user is existence-dependent on the provider. The provider is included in the definition of the user, by the modeler. If the provider where to be removed, or even be replaced by another provider, the user would not be the same any more. According to the model itself.
It is always the user (whether or not represented by the modeler, and whether or not at design-time) that creates the “used-by” dependency, in other words, where the initiative originates. If one would define “initiative” as the first action to take place *after* design time, so within model scope, then of course the initiative varies with specific scoping choices, that is, about where design-time ends an the model begins. In this case, the initiative is a *variable* for the modeling language, not a constant, and should therefore not be used for deciding about the direction of the arrow.
Really neutral terms do not exist, of course, and I can live with “used-by” perfectly. The first almost-neutral alternative term that pops up in my mind is “constitutes”. This has the advantage of expressing both the “static” view on the dependency, as well as the “dynamic” view. But, since I guess most would find that term too abstract, I will not seriously suggest it.
LikeLike
For me this really is a fundamental thing about ArchiMate that I am still struggling with. So fundamental I would have hoped for more coverage of the “application interfacing with another application” in more depth in your book (this blog post would be useful introductory section). Currently I’m experimenting with showing Infrastructure Service being used by an Infrastructure Function to cover the technical “client-server / which side is initiating” part, but the corresponding Used By in the application layer can be in either direction depending on what suits. And then using flow and trigger in the business layer to show sequence. All this is touched on in your “real world example” chapter, but I would have liked to see more coverage of this topic in the book.
LikeLike
A book about a language can never be considered ‘done’ or ‘complete’. So, yes, this could have been added to the book. In fact, one could write infinite thick books about any language. I’m not criticising your remarks, I agree, but I am also aware that there will always be something that could have been added to make something more clear, but at the same time, adding too much makes it impossible to digest for others.
LikeLike