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:
There is only one ‘layer’ left and with recursion (re-using that domain over and over again) we can model everything. Take our Excel example:
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… 😉
R&A IT Strategy & Architecture 
Gerben,
I like the way you fundamentally look at the value of ArchiMate and check whether it fits it’s need. And your last post to me was very insightful. You gave some very interesting examples of how ArchiMate can be extended to model the physical world. However, I tend to disagree with your conclusion in this post.
What you propose is to raise the level of abstraction. I think there is an end to that. Every consultant that has seen many projects, should have run into a project where somebody designed a kind of metasystem, a system where almost all differences and choices were abstracted away. The best example I know is the database with just four tables (“TABLE”, “COLUMN”, “RELATION” and “VALUE”). With that you can model and store any kind of data, without ever needing any data model change. However, performance is generally an issue (and often dramatically bad) and application maintenance is hard.
So, there are good reasons to go down in levels of abstraction, What I value in ArchiMate is the fact that in general it helps me to detail an architectural landscape in elements people recognize and understand. Because the level of abstraction chosen it generally proposes and allows about the right set of allowed relations (although I have some serious issues with some of them). But it is a view of reality and never reality itself. So it always isn’t 100% correct and complete. It shouldn’t be either.
On your last comment: I tend to agree that the current three layered approach that are fundamental to ArchiMate and TOGAF are increasingly hard to fill out, especially in environments where there is a mix of mobile and cloud based systems and services. Maybe another perspective would fit better, but for now I’ll stick with the current best practice. It isn’t horribly broken, it’s just one way to view the world, one model that helps and is recognized by many people. As the person that built the bridge to BPMN, I guess you are aware that there are more ways to model reality ;-).
LikeLike
I am tempted to point at the warning at the beginning, but I must admit that at the end I am touching upon a slightly more serious issue.
If I take all this mayhem seriously, then I would say that having a more abstract metamodel does not stop you to still model in the layers you like, as the last example illustrates.
“Horribly broken” is of course meant with a firm tongue in cheek.
LikeLike
I just read this excellent post with a big smile on my face. I love the way you turned things upside down and inside out. I am a sucker for philosophy, and you mixed that in as well. Well done!
It reminded me of a graphic I saw years ago (alas, I couldn’t find it anymore). It demonstrated the classic multi tier model by mapping it onto breakfast preparation. In the Data layer, you saw all the raw ingredients: oats, nuts, raisins, sugar, yoghurt… In the application layer, these ingredients realise muesli. The service layer contained, I believe, a bowl of yoghurt, topped with a heap of muesli. And finally, in the presentation (UI) layer, there was just a single spoon. And there you have your tool again, representing the user interface for interacting with the served breakfast. I haven’t tried to make an archimate model out of that, but I just might!
So a tool is a UI. And a UI is a user-system-interface, a means for a user to interact with a system. And a system can be anything. All we know is that it is organized in such a way that it shows behaviour as triggered by certain events, such as a user stirring it in some fashion with a tool.
Ah well, you made me smile AND think, and for that, I am grateful. Thanks!
LikeLike
Thank you. More philosophy on the way (post in the pipeline)…
LikeLike
Thanks for saying it out loud I look forward to a “perfect” EA language. Meanwhile let’s see how we can tweak Archimate some more.
Just so you know, I purchased and downloaded the fresh Ed. II of Mastering Archimate the other day. I’m a fan
I have a few ideas that so far at least make sense to me personally when I think of “reframing Archimate”. This is so far still in an experimental stage located in the right side of my twisted mind.
I’m not afraid of layers or abstraction. Since decades, the seven layers of the ISO OSI model worked excellently. Each higher layer uses the next lower layer, from application layer down to the physical layer. On the other hand, the three layers of Archimate may be hard to grasp as you have pointed out.
Here’s an outline of my main ideas, for what it’s worth:
1. Introduce the idea of “Archimate framing”on top of standard Archimate so that we can develop custom extensions and conventions within industries/communities (preferably in coordination with The Open Group, but I don’t think they will approve my rather drastic approach just like that).
2. Keep the three layers, but redefine! Redefine layers so that you allow non-IT components along with application layer and infrastructure layer components. At the business layer, you already have that with the Business Object construct. I don’t see any problem with modeling a conceptual Saw as a Business Object. If we’re interested in the infrastructure layer Saw objects, they could be represented as artifacts (saw instances). Another example: The other day I decided to model Letter (aka snail mail) along with email as an application interface (aka communication channel). This works well with business interfaces (business channels like e.g. direct marketing) and infrastructure interfaces (transport protocols like e.g. SMTP or POP).
3. Be true to layers! Processes exist at all three layers, so make a distinction between business processes, application processes and infrastructure processes. This is already partly recognized by the Archimate standard, where you can model e.g. an application layer process by Application Functions with triggers, flows, data access and junctions, exactly like a regular business process – except for one: The missing Application Event. I find Archimate and even BPMN being used to model solution designs by drawing business processes on top of very low level technical components. I’m proposing a distinction because these low level processes most of the time are not significant when it comes to understanding the business processes. To make it consistent across all layers, I would like to see Application Process and Infrastructure Process elements added to the standard, but we could tweak it and use Function elements for “process step” at all layers instead – and rely on the upcoming Capability element (work in progress within The Open Group) to identify functionality (I hope they will define separate capability elements at each layer, but I don’t know what they’re cooking). After all, we have aggregation and composition as general mechanisms, so we don’t need a different element like Business Function to group Processes, do we? Now, what about processes that are a mix of manual and automated processes? No problem, because we now have a slightly modified definition of “business”: Business is about concepts. Business processes are performed by conceptual roles, not physical actors or logical application components. Always. Business processes access conceptual Business Objects. Always. Business Products aggregate Business Services and nothing else. Having a super clear distinction between layers enable super easy discussions with business people;-) Personally I don’t find “business people” stupid – they are people just like “IT people” and can tackle abstraction just as well (I know business people who read books, and I know IT people who don’t). Our problem as architects is that we make it too complicated – and too little abstraction is guilty, I think. Here’s a good reason why business will listen when you say abstraction: Self-service with Omni channel support and adaptive processes… Customers should be able to switch from mobile to web or sms or telephone or letter in communication with a web service or a customer support agent or a business partner between any two process steps of the same business process. I believe the only way to make this happen is by designing conceptual business processes where the decisions about “channel” and even manual vs. automated process steps are left until runtime. OK, we don’t need this for documenting as-is processes, but I imagine we could find a way that satisfies requirements for as-is modeling as well as to-be – and so the conventions would be easier to learn.
4. Add a clear distinction between conceptual, logical and physical! The Archimate standard already has some constructs, like Business Object (conceptual), Data Object (Logical) and Artifact (Physical). I have played around with this for several other constructs, like e.g. conceptual reference models (say SOA MW) as generalization of logical reference models (say Oracle 11g SOA ), as generalization of physical models (deployed instances). Another example is a conceptual classification of business roles, as a generalization of logical business roles, assigned to physical Business Actors. By the way, you heard right – Actors with an email are just as physical as Devices with an IP address (or instances of a particular Saw) and I’m not sure if they belong to my business layer at all. Something to discuss? Meanwhile, maybe we should all listen once more to good old Zachman: http://www.zachman.com/ea-articles-reference/58-conceptual-logical-physical-it-is-simple-by-john-a-zachman.
Regards,
Erik
LikeLike