It’s been a while (Oct 8), but the answer for the Quiz Question had to wait for the release of this renewed website. I put out a quiz question and received various answers. The best answers were by Samuel Rinnetmäki from Finland who wins a prize (free PDF of Mastering ArchiMate Edition III).
Let’s start with the original question:
A company has two applications: TradingApplication and ReportingApplication. During the day, each trade is entered into TradingApplication. Trades have a cycle and are only definitive if the whole cycle is complete (e.g. payment received, goods sent). At the end of the working day, the TradingApplication sends the complete details of all trades to ReportingApplication that needs these trade details to be able to create important reports for the management. For this ReportingApplication offers a RESTful API (Application Service / Application Interface) that is used by TradingApplication.
Model the application-relation (no infra, no business) between TradingApplication and ReportingApplication in as many different ways as you can. Note, you can choose to either use behavioural (Application Function/Process & Service) or active structural (Application Component & Interface), I am not looking for all the different combinations of active & behaviour you can make there. Trivial variations (that can be derived) do not count as separate solutions. The easiest is to just use Application behaviour and Data Object.
The replies
Some answers I received used Collaborations and/or Interactions. These are of course grammatically correct solutions, but I do not think they are the best way to use ArchiMate in a case like this. It is the ReportingApplication that independently produces the report, even if it got the data from TradingApplication. TradingApplication has no knowledge of reporting at all and letting it share in the responsibility for it is incorrect in my view. I can extend the meaning of Collaboration to make it completely overlap Serving of course (if A Serves B then there is obviously some sort of ‘collaboration’ between A and B), but reasoning that way would eliminate all use of Serving and everything would become Collaboration and Interaction. It is in my view best to limit Collaboration for real ‘interaction’ between the partners who perform some behaviour together (the obvious examples being ballroom dancing, launching a nuclear missile from a submarine, maybe anything with a 4-eye principle if not modelled in detail) and model the actual behaviour by a process. Interaction as an element is superfluous in ArchiMate.
I also received answers that used just Triggers from one to the other. This doesn’t really tell you that the applications have some sort of ‘content’ dependency (which they have). But those were valid answers.
I got one reply that told me that what I suggested with the API was just wrong: if the ReportingApplication used the data from the TradingApplication, the TradingApplication should offer a service to the ReportingApplication (and not the other way around) so that the ReportingApplication could pull the data when needed. There are two reasons why this isn’t a valid critique. For one, it is perfectly fine to have a TradingApplication push completed trades to another system in an STP manner (potentially via publish-subscribe and an ESB), or even in a batch at the end of the day. And frankly, even if it were the case (which it is not) that the ReportingApplication should preferably pull the data from the TradingApplication when needed, we may not have the choice: we often buy systems and this ‘canned architecture’ decides for us how the landscape is. It is not helpful to answer “how to model X” (where X can exist) with “X should not exist”. Maybe in a world of alternative facts, but not in our daily reality.
Having said that, what would people have modelled if I would have left out that TradingApplication is calling ReportingApplication? Suppose I would just have said “The data from TradingApplication is used by ReportingApplication”, leaving out the details? After all, that’s what architecture is about, right? Leaving out the details? Chances are that people would have modelled this:
And we could have added the data like this (note: I am using Mastering ArchiMate style colouring, so the green is not technology but still application layer):
But if we add the API to the story, people tend to model this:
And if we remove the interface and create a derived relation, we get this:
Which is the perfect opposite of the first diagram. So, which is it to be? If we choose the former, we see a dependency in our landscape that is true: ReportingApplication does depend on TradingApplication in some way, whereas the latter would wrongly suggest TradingApplication somehow using results from ReportingApplication. Of course, when we add the data, it looks like this:
and it becomes clear that while TradingApplication depends on ReportingApplication, data-wise ReportingApplication depends on TradingApplication.
It is a drag, though, to have to model all these Data Objects (or Business Objects or Technology Objects (Artefact, Material) in your models. Still, thanks to ArchiMate 3 (everything above is still ArchiMate 2 compatible) we can come to a new pattern. First, instead of using Access relations, we use a Flow relation with an Associated Data Object (the payload):
In fact, the simplest alternative for a Serving relation (either way) would be a simple Flow relation from TradingApplication to ReportingApplication:
which is true. regardless of where the API is offered and who initiates contact. And you can add the payload if you want or not.
Analysis
Samuel sent in a large set of possible models. In the first bunch, there were no solution that had a Serving relation from TradingApplication to ReportingApplication, but later he added this pattern too in another set, labeling it as an ‘invalid’ solution because it would “basically state that the purpose of the TradingApplication is to serve ReportingApplication”. I don’t think ArchiMate says anything about ‘purpose’. What it does say, though is:
The serving relationship models that an element provides its functionality to another element.
and
The serving relationship describes how the services or interfaces offered by a behavior or active structure element serve entities in their environment.
Though I know that many people would say that Serving can (should) be interpreted regardless of technical implementation (we’re architects after all) and I also know from private communication that originally the ArchiMate idea of a service was more like an interaction. But ArchiMate 3 talks about offering functionality (in ArchiMate terms: behaviour) to the outside world, not (the flow of) data (passive structure). So in ArchiMate 3, it is best I think to use Serving for modelling the offering of behaviour from the one offering to the one using. In our case, the behaviour offered is “receiving trade data” and it is offered by ReportingApplication.
With ArchiMate 3 and the improved Flow relation, we can now effectively use Flow to model the dynamic aspect (data moves) and even be specific with a payload, while we can use Serving to denote the behavioural dependency (and a note for UML people: the arrow means Serving and not Calling, so it is opposite to what you are used to in UML).
What I would like is for a Flow relation to be (potentially) bidirectional as I sometimes have two entities exchanging information and creating two Flows is a drag.
And as a result, these days I generally only use Access relations to Data Objects if we are talking some sort of ‘permanent data’ such as what is stored in a database (an Artefact). I would thus model two applications exchanging data through a database with Access relations, but two applications exchanging data with services with Flow relations (with payloads) and Serving to denote the technical dependency (who is called by who). Or, we could indeed leave the whole Serving out and use a Trigger and a Flow. The Trigger also implies that the one triggered offers a service/API.
Finally: ArchiMate 3 calls Serving (together with Access and Influence) dependency relations. A Serving from A to B means B depends on A. It is clear that in our example ReportingApplication depends on TradingApplication, it is only technically that TradingApplication depends on ReportingApplication. Both dependencies exist, so both can be modelled with Serving. But I think it is best to reserve Serving for the technical dependency (providing behaviour/functionality) and use Flow for the Flow of data/material.
More in the book. Of course 🙂
R&A IT Strategy & Architecture 