Used-By Redux

by

Link: http://masteringarchimate.com/2015/04/09/used-by-redux/

From Mastering ArchiMate

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 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).

TwoUsedByDirectionsThe 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):

ApplicationUsesApplicationDerivedSo, 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:

ApplicationUsesApplicationDerivedAllThreeAs 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:

AddingTriggerAndFlowStep1What 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:

UsedByTechnicalFullThe 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:

UsedByTechnicalWithFlow

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.

0