Modelling Physical Enterprise Architecture with #ArchiMate

Enterprises are not just about IT, and though EA started because of the chaos and complexity in IT, many real enterprises are not just about information. An ‘Enterprise’ Architecture that cannot describe the entire enterprise is not worth its name. So, how would we address this in ArchiMate or how should ArchiMate be adapted to make this possible? Thinking about this led me weird places, e.g. some fundamental issues about the assumptions of ArchiMate (and EA) in general and their origin.

Warning: thinking in progress! (BTW, does anybody recognise this particular sign? If you do, we share something in our past…)

Anyway, let’s start with a small fragment of Business using IT, the basis of what EA modelling in ArchiMate is generally about. An example is something like this:

 

I’ve added both standard Access relations to the Data Object as this is meant to illustrate the metamodel. Now if Business can use IT it can also use non-IT instruments which produce physical products, say a lathe. And if business can use or manipulate information (data) it can also manipulate or use physical objects. If business uses it, in ArchiMate terms we are in the application layer, so we might start there to model the physical as well. As a first very simple example we model a carpenter who creates a book shelf, in analogy with the above IT example:

A warning about simple examples and large conclusions is in order. Later we should look at more complex examples to see if anything we think of remains feasible.

Before  moving on, let’s ask ourselves if we are OK with something as simple as a Saw performing ‘behaviour’. I am OK with that. After all, my manipulation of a GUI of an application changes my behaviour into quite something differently too. In the same way, my moving my hand with a saw in it, turns that movement into quite a different behaviour: sawing. With that in mind, I’m willing to assign behaviour to something as ‘dead’ as a hand saw. It remains a tool I use and it provides a service. It is not operated upon (passive structure) it is used.

So this setup looks very logical, but we do have a problem: what about the infrastructure layer in ArchiMate? Plank is a physical object and it seems more appropriate to have something like a plank modelled in the infrastructure layer, which is more of the physical. We can do that, but it means we have to allow the business layer to use the infrastructure (physical layer) directly.

It looks like this:

Now we can be satisfied that Plank is a (physical) Artifact, but we need to adapt ArchiMate that the business can directly use the infrastructure layer. Yes, these relations are already allowed in ArchiMate, but they mean something else. As is, these relations mean that some (not modelled) application is between the infrastructure and the business. The relations are derived.

We could, of course, just as we do with IT, have the Plank appear in both layers. The Data Object in IT is Realised by an Artifact (e.g. a data base), but everyone who has any knowledge of software and systems knows that the difference between Application Component and System Software is pretty artificial. Imagine the architects at Oracle: for them, the table, the row, the lock, etc. are Data Objects and the RDBMS is an application they build, while for most of us it is System Software, a platform we use for deploying applications. This is an important issue and we’ll get back to that later. Still, if we also accept physical EA such a dual-representation, we would get something like this:

 

So, are we OK with Plank being both an Artifact and a Physical Object? Frankly, it feels far less acceptable to have an abstraction like this if both are so obviously identical. As I wrote in the introductory chapter of the book (Section 5.6 Why two types of software?, part of the free syntax excerpt), the difference between two types of software is technically nonsense as well, but there is an understandable reason for this: from a business perspective the application that is directly used by the business has a different status than the RDBMS that lies underneath. This perspective has strongly influenced EA, but it seems even more nonsensical when modelling the physical this way, to the point of it being downright silly. Of course, we can imagine situations where it does make sense: that printing press is a tool used by the business, but the electricity generator is seen as ‘infrastructure’. We clearly need to pay more attention to the question of what we see as ‘infrastructure’ and what not.

There is a small issue that remains generally hidden in IT but is relevant in the physical world. When the Data Object is Realised by a data base Artifact, changing that Data Object normally does change the Artifact, but there is not a new Artifact. In the physical world, this generally different. If you sell wood to the carpenter and he or she builds a table from that wood, the table is assumed to be a ‘new’ Artifact. E.g. when the carpenter does not pay for the wood, you cannot claim the table as ‘your wood’ (old), as it has been ‘converted’ (the Dutch legal term is ‘zaaksvorming’, the English legal term is ‘specificatio’) to a table (new), and your wood is ‘gone’. Such scenario’s do not really happen in IT. If you sell a data base to someone and he or she creates something else from it, the original data base is not ‘gone’ at all. If we want to model the physical enterprise, we need to support this scenario. It could look like this:

 

Here I have introduced a new relation ‘conversion’ (with the double arrow head) that means that one object is converted into another. Another option (possibly better, given that it stands for some sort of behaviour) would have been to make conversion a relation that comes (as an alternative) in the place of Access. Or we could have the option to link the behaviour that does the ‘conversion’ to the Conversion relation just as we would like to link a passive object to an ArchiMate Flow relation — but I’m digressing (as usual).

Now, where does all of this so far lead us? We need to make a fundamental choice: do we represent ‘physical EA’:

• In the application layer (and ignore infrastructure)?
• In the infrastructure layer (and add direct access between infra and business)?
• In both layers (and accept the double appearance of de facto identical elements)?

I am leaning to the second one at this stage in the story. The disadvantages of the first and the third are too big for my taste. But the example of sawing a plank to make a shelf is extreme simplistic and that should put us on guard. Certainly on the tool side there are more complicated tools used by businesses, sometimes they may be tools that produce physical objects but that can be programmed, e.g. modern lathes or more robotic tools. What does that make the tool: a platform? How do we represent the program that has been loaded in a modern lathe and that describes what needs to be produced? Or what about a 3D printer?

I’m clearly not done yet. As I wrote in the beginning of this post: this exercise has led me weird places. These weird places will be discussed in a follow-up post.