ArchiMate defines a set of 11 relationships between elements. How these relationships can be used is also defined in the specification in the metamodal diagrams and in a table of allowed relationships given in an appendix.
Here’s an example of a metamodel diagram for the business layer:
And here’s an excerpt from the relationships table in the appendix:
If you’re creating an ArchiMate tool one of the first things you want to do is represent the ArchiMate metamodel and the rules for the allowed relationships (core and derived) in code. So it’s probably best to regard the tables as provided in the appendix of the specification as the single point of truth, right?
Wrong. For the past few years these tables have been incorrect and there have been inconsistencies between the rubric and the metamodel diagrams. But that seems to have been fixed now with the latest 3.0.1 version of the documentation. Good news. But surely there’s a machine readable format for the relationship rules to ease the burden of the developer? Wrong again.
When I developed the first version of Archi I had to read each line of the relationships table and manually type every “a”, “f”, “t” and so on into an XML file. I’ll never get those dead brain cells back…
Fortunately, this time round I was saved by Ed Roberts of Elparazim who has generated the relationship tables in an XML format with some mysterious Prolog scripting voodoo.
Taking the example table above we can read the first cell as “an Assessment element can connect to another Assessment element using the Specialization (s), Composition (c), Aggregation (g), Influence (n), and Association (o) relationships”. So what’s the best way to represent this in a tool?
I use an XML file that, in its simplified form, looks like this:
<relationships version="3.0">
<source concept="Assessment">
<target concept="ApplicationCollaboration" relations="o" derived="" />
<target concept="ApplicationComponent" relations="o" derived="" />
<target concept="Assessment" relations="cgnos" derived="cgn" />
It has a “source” section for each of the ArchiMate elements and a “target” line for each element. The allowed relationships are denoted by a single letter as in the table, above. The “derived” attribute declares those relationships that are not core relationships. This is not currently used in Archi, but I have plans for this in a later release. You can read up on derived relationships here.
The whole XML file is available to view here.
When I first designed Archi I pondered the best way to do this. I knew that it had to use an external file so that it could be easily updated, and it also had to be human readable. I thought about using a CSV file but scrapped that idea when I tried to edit it. So I went with the XML file because it fulfilled the following requirements:
- Has to be an external file
- Easily understood by end users
- Favour verbosity over conciseness
- Easy to maintain and edit by end users
- Order of elements doesn’t matter (that ruled out CSV)
- Common format (CSV, XML, JSON, whatever…)
So there it is. An XML based, verbose file format. Could it be done better? Perhaps. But it’s worked for the last 7 years in Archi.
All we need now is for an agreed open format that The Open Group can publish with the official ArchiMate specification. Once again, this is being crowd sourced, but I can’t say whether the XML format that I use will be adopted. It might be in CSV format. But, to be honest, anything is better than nothing.
(Oh, if anyone wants to check the accuracy of the XML file against the published table, please feel free to do so!)
