Dear TOG,
I hope this letter finds you well.
As shepherd of the ArchiMate standard, you are currently working on its next iteration. As I am not part of the ArchiMate Forum, I am going to send you a few open letters with suggestions for improvement of the language and what to do an not to do. I will be voicing some stern/harsh criticisms on ArchiMate in these letters, please don’t take it personal, I’m only interested in strengthening the language which I already find useful as it is. And I apologise beforehand for my language here and there.
This is the sixth of such a letter. The previous ones: fifth, fourth, third, second, and first.
Today, I want to write to you about the small issue of the names of a few elements.
I suspect that the Used-By relation will be renamed to an active verb form. I recall having seen this in a LinkedIn discussions a while ago.
If you’re at it, you might also change the names of some other elements.
A major candidate for this is System Software. 
This name has been carried over from before ArchiMate 1, when it was positioned as the behaviour of hardware (operating systems a long time ago were seen as the software that manages the hardware and makes it behave in a certain way).
In ArchiMate 2, the element became an active element (as a full sibling of Device) and Infrastructure Function was added to model behaviour in that layer. This was an improvement. Now, the standard says:
System software is a specialization of a node that is used to model the software environment in which artifacts run.
May I (as a first step) suggest that the best term for this is Platform (or maybe Software Platform — given that Device is a Hardware Platform)? It would really be helpful if the element was named away from the time that it more or less stood for an operating system. I now have to explain to people that a database system (or any other platform) according to ArchiMate is “system software”. That is awkward, to say the least, and though it is a small matter, things like this really have a negative effect on people starting with the language.
We should probably go a step further. Is everything that is considered ‘infrastructure layer software’ a platform? I suspect not. A database that does not support embedded programmer-defined logic is not a platform in the above sense, just a way to access passive data.
So, maybe it is even better to rename System Software to Infrastructure Software. And then it would be clean to rename Application Component to Application Software if you’re up to it. Given that you’re probably also going to add some way to model the physical side of enterprise and not only the data-manipulating side, this is well doable.
I think “Infrastructure Component” would be a confusing new name for System Software, as it kind of overlaps with Node. Maybe, it is better to rename Node to Infrastructure Component (so it is the infra-variant of Application Component) and rename Device too. That would give us the following cleaned-up set:
Infrastructure:
- Infrastructure Component (formerly: Node)
- Infrastructure Software (or Software Platform. Formerly: System Software)
- Infrastructure Hardware (or Hardware Platform. Formerly: Device)
- Infrastructure Function
- Infrastructure Service
- Infrastructure Interface
Application:
- Application Component
- Application Function
- Application Service
- Application Interface
Infrastructure Hardware would cover the basics of the IT world hardware: storage, network, compute and any specialised combination of these (such as a desktop PC, smartphone hardware, or a network router).
It all depends a bit on how you’re going to address the physical side of organisations which is the best fit (e.g. in some variants you may end up with Application Software and Application Hardware below Application Component, where the current Application Component has changed to Application Software).
But at least, drop the really outdated name of System Software.
Yours truly,
Gerben Wierda
Former Lead Architect of APG Asset Management and of the Dutch Judiciary
Team Coordinator Architecture & Design at the All Pension Group (APG)
Author of Mastering ArchiMate and Chess and the Art of Enterprise Architecture
PS. High brow enterprise architects seldom pay much attention to infrastructure. They’re busy ‘architecting enterprises’ and the infrastructure is way to far down in the muck for their taste. So, I suspect this part of ArchiMate is getting far less attention than the rest. Maybe that is why nobody ever made a problem of this last-century terminology. But I can tell you: infrastructure is hot, these days, cloud, software defined anything and all. The business and application layer, application rationalisation and such (note, the link gets you to a story on InfoWorld where ArchiMate is mentioned!), are so much yesterday’s news, really… 😉
R&A IT Strategy & Architecture 
You wrote *the* book on ArchiMate.
You are an expert on EA and ArchiMate,
You are not part of the ArchiMate Forum.
What does that say? Discuss.
LikeLike
Hi Phillipus,
Thank you for the kind words on the book.
But it doesn’t say very much, I think. Compare: not every expert on UML sits in on whatever OMG has as ‘ArchiMate Forum’ equivalent for UML. And I think there are people on the ArchiMate Forum who understand ArchiMate more than fine, even if we sometimes differ in our opinions, experiences and tastes with respect to EA.
LikeLike
Sure, but it can be good to have differing opinions that contribute to a balanced, open standard. All open standards need to be balanced between commercial and non-commercial interests. It would be a shame if an open standard was overly influenced by just one commercial vendor, for example…
LikeLike
Hi,
I can tell you that:
(1) You’re definitly right saying that infrastructure modeling using ArchiMate is a hot topic. I even had some discussion on this topic past week (and that’s what I’ve mainly done for the past 4 years).
(2) I know at least one (recent) ArchiMate forum member that read your open letters 😉
LikeLike
I disagree with the renaming of device. For example what if part of your solution involves a hardware licensing dongle or an attached high accuracy time source. How are these platforms?
LikeLike
Not. That is why my actual proposal says “Infrastructure Hardware”
LikeLike
Device means an object design for a purpose. It’s a specific label that is able to be applied precisely and widely. It is semantically correct from a supercomputer down to an RSA key embedded in a TPM module.
Infrastructure Hardware on the other hand is imprecise and vaguely tautological and doesn’t help a solution architect understand how to model in a world when more and more functions can be performed by a virtual or physical object.
I’m not actually sure with this letter what your purpose is with these suggestions beyond making the technology layer as equally confusing as the application layer. If these labels are to change they should become more accurate at a semantic level not less. We already know this is the technology layer, it doesn’t need another label (which isn’t the name of the layer) prefixed onto every element.
The current labels are also analogous to the same elements in UML deployment diagrams, changing them just adds a hurdle that architects have to get over when switching between notations.
LikeLike
I have no problem with Device, it can stay as is as far as I’m concerned. I only have a problem with System Software as not all infrastructure software is ‘system’ software.
Behind this there are, I think, two ways of thinking about what infrastructure is. One is, that infrastructure is (more or less) hardware with its embedded or otherwise necessary software such as an operating system. This is a view that is strongly wedded to IT where we have the clear distinctions between hardware and software (and thus fits UML and its software engineering origins). In this view, Device is a perfect name. But the other way is to think of infrastructure as ‘generic’. This fits with the role for (current) System Software as mentioned in the standard: Platform. As a case in point, if you take something like Database Software, it is clearly infrastructure from the latter point of view. It only has some sort of generic service to offer to the application layer. This is less an IT view (also very historical), but more in line with the business view on things.
LikeLike
I think the assumption that virtualised hardware is software (in the classic sense) is incorrect. The architects, SMEs, and engineers who are hands on this space don’t make the distinction. They’re able to cognitively move seamlessly between – for example – a physical switch and a virtual switch. The people who don’t are the older practitioners who now have less hands-on interaction with technology. We need Archimate to less of a notation for fossils, not more.
I don’t like the label “System Software”, but then I think there is a failing across all models and methodologies to define what terms like application, platform and system actually mean. Changing it to “infrastructure software” doesn’t help, if anything lack of definition of “infrastructure” makes it worse.
In practice, I find it easy to teach architects what to model with system software. We quickly end up with a reusable library. The problem we strike is not with the element itself, it’s that Archimate doesn’t support instantiation and all the things that inheritance gives us. From there we end using stereotyped UML components with tags and inherited tags. The frequency with which people ask how to turn tags and compartments on for Archimate diagrams on the Sparx forums makes me think this is a common occurance.
System Software needs to come to mean “any software that you are a) not writing yourself or b) isn’t a library you’re including in your own software. I don’t think the changes you’re suggesting is going to achieve that because of the failing of ICT Architecture to define what software is.
LikeLike
There are differences between virtualised and physical hardware, for instance when contention issues play up. And not always that what has to run on it works as well on virtual as physical. There are reasons for that that go beyond this space, but virtualisation does have its issues. There are also matters like there being new attack vectors for cyberattacks and so forth. For the users of virtualised hardware, the ideal is that they don’t see the difference. But this is not always the case and those are cases where for the ones responsible the difference starts to become important.
Maybe Infrastructure Software is not all that intuitive. But System Software suggests an outdated and wrong idea.
Also, not all software that you do not write yourself is System Software. There are applications you do not write yourself.
Anyway, I agree with the issue that ArchiMate could become more powerful if t at least had the option to be clear about classes versus instances and instantiation. E.g. see this post as a starting point.
LikeLike