If you know ArchiMate, there’s a good chance that you know Gerben Wierda‘s post series “What is wrong with this picture?”. This blog post is both a tribute to his work and an attempt to explain the importance of why you should be aware of the difference between core relations and derived ones.
In his book Mastering ArchiMate, Gerben presents several beginner’s pitfalls and especially the (bad) use of derived relations. I can only recommend that you follow his advice, and I will explain why, but let’s start at the beginning…
Core vs derived relations
When reading the ArchiMate Specification you might notice that the relationship tables contain a lot more relationships than those described in the metamodel pictures (such as this one for the business layer). The latter are the “core” relationships. In a detailed ArchiMate model, you could just use only these ones. But in real life, you will certainly have to create some high level views hiding some elements and using derived relationships.
In general, ArchiMate tools implement all of the possible relationships based on the tables in the Appendix of the specification, but don’t tell you which kind of relation you are creating, core or derived, and this may lead to problems.
Infrastructure Service used by Data Object
Today I was working on a model for a new project. For this, I used our standard pattern for a database:
This pattern basically shows a shared server which hosts several databases. In order to be able to move one database from this shared server to another one in the future without having to reconfigure applications using it, each database is accessed though a dedicated DNS alias pointing to the real server name (for those who know Oracle, we assume the service name and the port will not change).
Following our pattern, I then added some additional elements from the application layer, notably a Data Object realized by an Artifact. As I am testing the Archi 3 Early Access Preview, I played with the new Magic Connector functionality and found the following possible relationship – Infrastructure Service used by Data Object…
Wait a minute! What does “Infrastructure Service used by Data Object” actually mean? In natural language it seems to be OK because, after all, my database is managed/presented through the “DB1 (Infrastructure Service)” and therefore relies on it, so I could use it. But let’s examine this situation more closely first.
The first question to ask is whether it is a core or derived relation. That’s the easy part, the Application-Infrastructure Alignment Metamodel clearly shows that it’s not (only Realization from Artifact to Data Object is permitted). So it turns that it must be a derived relation, and we need to find it.
In order to understand what this Used By relation means, let’s start at the endpoint – the Data Object. Only a few core relationships are defined – Realization from Artifact, and Access from both Application Function and Service. A Used By relationship can only be derived from relationships having a strength at least equal to Used by, so this excludes the Access relationship.
After some time checking the Infrastructure Layer Metamodel, I ended up with the following (derived relation in blue):
“DB1” used by “Shared DB server”? Not what I intended to show, and clearly false in my case (there’s nothing on my database server that make use of the DB service).
Conclusion
All this came about because I used a helpful and nice feature in Archi – the Magic Connector. This can really help you a lot and shows you all allowed relationships between concepts, but it doesn’t tell you which relationships make more sense in a given context. As it is, I know ArchiMate well enough to ask such questions, but what if I were new to ArchiMate? I would have kept the Used By relationship and never have understand its real meaning, a common beginner’s pitfall.
So what can we do? As an Architect, I can make sure that I really understand what I’m doing by learning (and Gerben’s book is perfect for that). As an Archi contributor, I can suggest to enhance the Magic Connector to show me whether it is proposing a derived relation or a core one. We could also envisage that Archi could warn me when I manually create relations or reveal their nature (as with the “Show Structural Chains” option). Adding such a feature would really help a lot of Architects master ArchiMate.
Just for fun, re-examine some of your models and take 5 minutes to see how many derived relations you use, and then check their exact meaning. Do you find some strange things?
Nice story, Jean-Baptiste. 🙂 I agree, it would be helpful to indicate to the Archi user what the core relationships are for any given context. This ties in with an idea I have of implementing an “Intelligent Modelling Agent for Archi” (IMAA). I tweeted the other day:
Well done!
Just one remark: it is not necessary that the Used-By runs from the Infrastructure Service to the Node that produces that same IS. It could be an entirely different Node et cetera. What the ‘allowed relation’ means is that some sort of route is possible, but not all of these syntactically correct routes are semantically meaningful routes in all situations.
Do I win a prize now? Free Archi download 🙂
Yes, you win. Please redeem your free Archi download using coupon code #WEWANTEVERYTHINGFORFREE
🙂
You’re right in general.
In this particular context, my Data Object can’t be realized by two Artifacts (it doesn’t make much sens) so the Artifact was known. For the same reason my Artifact can’t be assigned to multiple Nodes or Devices, so I also assumed the node was known.