In a previous post, I discussed the first ideas that came from thinking about modelling the physical side of an enterprise, things like printing presses, steel mills, etc., something not directly the domain of ArchiMate (nor EA in general for that matter, it is often all about Business-IT). We can take some of the ideas of that post for a spin and see what happens. Weird stuff, indeed.
Serious Warning! Weird thinking in progress! This is not really ArchiMate! This gets crazy pretty quickly!
One of the items raised in the previous post was that if you look at tools, you quickly notice that it is quite normal to think of the business directly using the physical world. A Saw is something quite physical and so the business is apparently using the infrastructure layer (where physical concepts reside in ArchiMate) directly.
This is not the first time I have encountered the question about the business using infrastructure directly. One is (as described in the book) the issue of for instance Excel, where I find it most illuminating to see the spreadsheet as an application that runs in the Excel (infrastructure) platform, but that leads to the question how you model using Excel directly (e.g. for creating spreadsheets in the first place). In the book, the solution is to turn Excel into a ‘complex’ application stack that contains both infrastructure (Excel used to ‘run’ a spreadsheet) as application (Excel used to ‘edit’ a spreadsheet). See Section 14.1 Low Level Data Entry in the book. The other is when using BPMN where there is no layering at all and where people are perfectly OK writing process descriptions (ArchiMate: Business Layer) that directly manipulate files (ArchiMate: Infrastructure). See Section 25.7 Processes handling Artifacts in the BPMN and ArchiMate chapter of the book.
So, if we step away from the standard thee-layer approach, and we assume that business may use both the application layer as well as (directly) the infrastructure layer, we get a triangle model instead of a layer model. That structure looks like this:
Direct Access from business ‘layer’ (from now on I am going to use the term ‘domain’ instead) behaviour to the passive objects in the other domains has not been modelled, instead, the Artifact can directly Realise a Business Object. Anyway, this way you have the choice, the business may use ‘applications’ (as a special case for IT-related Enterprise Architecture) but it may also directly use ‘infrastructure’ and one of the tools used may be an ‘Instrument’. This, you will say and I agree, is far from complete. For one: how does the business behaviour access infrastructure passive elements without using a tool?
Thinking about this a bit more, if the business can use software from the infrastructure domain, what then is the difference with using software from the application domain? We could say that it is software that itself uses other software. But we already have that, don’t we? Even in today’s ArchiMate, software from the application domain can use other software from the application domain. In fact, on a discussion on the ArchiMate LinkedIn Group, Thomas Barnekow proposed this perfectly valid approach as an alternative for modelling software platforms. I showed that alternative in Section 18.3 A completely alternative platform approach in the book.
In fact, the whole idea of having two types of software, depending on the business’s perspective remains questionable from a ‘logical’ perspective. Everybody who knows anything about IT understand that it is a whole network of software using software, and labelling some as infrastructure and some as application is not supported by any technical difference. If you come from software, you recognise the pattern as recursion (mostly at abstract class level, to be precise). In IT, from a technical perspective, we do not have an ‘application’ domain, or an ‘infrastructure’ domain that are clearly delineated, we have a software domain that uses elements from itself, labelling it as application or infrastructure depends on your point of view. Only at the lowest level of hardware do we turn from software to another type of active element.
Taking it yet another step further: we humans are tool users. Other animals may use tools too, but our level of tool use sets us apart and can even be used to define us. We are the tool-using animal: ‘homo utensili utens’. Everything we use is a tool. An application is a tool, a saw is a tool, a programmable lathe is a tool. So, why not start from the basic principle of tool use (which defines us) and go from there? And if we say that in general we have tool use, but there are just many variations of tool types, we get something like this:
We humans use tools and we access artifacts. And tools also access artifacts. So, the printing press is a tool that creates (Access) physical (hardware) Artifacts, namely books or newspapers. But we as humans can read books and directly Access that Artifact. We might even do without the concept of a business object altogether:
And if we add automated processes according to the idea that was described in Section 28.2 Automated Processes in the book (we do not assign tools to business behaviour to signify automation, but we let tools Realise Roles) we get:
We are still able to model with layers, it is just that layers re-use the same basic stuff underneath. Both the ‘application layer’ and the ‘infrastructure layer’ are modelled using the ‘tool domain’. For instance, like this where we model creating and using an Excel spreadsheet:
I warned it would get weird and I’m going to make it weirder still. Because, to be frank: what’s so special about us? Suppose our ‘tool’ is an animal, say a horse or a dog? And aren’t we used to even talk about humans as being a resource these days? So, what is we say that we are also a tool to be used by others? It is not as strange as you think. If you are legally bound to fill in a web site for your tax returns, the government is using a system which is using you. It happens more and more that people come into situations that they feel they are there for the benefit of computers and not the other way around. And it is sort of true.
Anyway, if you follow that line of thought you may get this as a ‘single layer’ metamodel:
I’d like to end all this modelling mayhem with a slightly more serious observation:
Our standard Enterprise Architecture layering approach (business-application-infrastructure) is a construct that has long not been based in reality anymore, it is based on perception. If you ask me, this layering approach is rooted in the early origins of IT, times when we had ‘hardware’ that was capable of being programmed with ‘software’ which was being used by ‘people’. The layering was unambiguous, then. But the concept ‘hardware’ evolved into ‘technical infrastructure’, the concept ‘software’ evolved into ‘applications’ and the concept ‘people’ evolved into ‘business’. We kept the organising principle from that simpler time, but we changed the meaning of the concepts when they evolved. But todays ‘hardware’ (infrastructure) includes software. And today’s business includes software as independent actors (that phone menu you hate so much is a very simple robot employed by the business).
So, we kept the layers, but the clear distinction has long gone. We are talking about modern enterprise architecture, but we still employ thinking that is ancient. And ArchiMate has been built with that structure at its core.
It’s a testament to people’s ingenuity that they can still make very good practical every day use of ArchiMate even if it is so ‘horribly’ broken… 😉