A proposal for non IT-centric Enterprise Architecture layering
Enterprise architecture should not only focus on IT, but should concern itself with the organization in general to improve its performance. That is the main idea of my previous article about the scope of Enterprise Architecture. In shorthand EA should not be IT-centric.
Most of the architecture frameworks that I know of start with a ‘business’ layer and then from left-to-right, or from top-to-bottom it features IT-layers: information, data, application or technology are the most prominent (the BDAT-layering or BAT-layering). These layers are sometimes combined with other dimensions for example from abstract to concrete, of from vision to execution.
In this article I will propose an enterprise architecture layering that is not IT-centric. To make it more concrete, I use the ArchiMate language as a reference framework. This article will be somewhat more ‘technical’ than my previous article, however I hope it equally will be understandable for people who are not in the enterprise architecture field.
ArchiMate layering
First of all, a very short introduction to ArchiMate. ArchiMate is the de facto standard language for enterprise architecture modelling. Together with TOGAF, an architecture method, it is an architecture standard of the Open Group. With ArchiMate one can create visual diagrams to model organizations and its behavior. In the picture below an example is presented.
In this example a person applies for a job using the company’s “Hire service”. This “Hire service” is realized by a “Recruiting process” which is performed by a “Recruiting department”. A “Recruiter” works in the “Recruiting department” and in that sense also performs the “Recruiting process”. The “Recruiting process” is supported by a “Recruiting application” that is hosted on the “Recruitment application server”.
The ArchiMate language is designed using a layering framework, of which the core is depicted in figure 2. The ArchiMate layers are the standard Business-Application-Technology layers.
This standard layering has one peculiarity, namely the Physical sublayer of the Technology layer. Actually, ArchiMate started out with supporting the architectural modelling of information intensive organizations only. So, there was no support for modelling physical entities in organizations (apart from IT hardware). In version 3 of ArchiMate this omission has been repaired and physical concepts are added to the language as a sublayer of the Technology layer.
The TOGAF architecture method uses the same BAT-layering by the way. In contrast to ArchiMate, it does not (yet) have the ability to take physical entities in account.
ArchiMate layering remains IT-centered
As of version 3, the ArchiMate language supports the ‘broad’ modelling of organizations: not only the IT-part of an organization can be modelled but the non IT-part of an organization as well. While this is indeed the case, the ArchiMate layering remains IT-centered with the application layer as middle layer. Let’s look at the ArchiMate layering more closely for a better understanding how the language is designed.
First, the business layer is about business actors performing business processes and delivering services to the outside world. The business actors are humans or departments so one can safely say that this is about the ‘human’ side of an organization. The second layer models applications and its functionality and how it supports the business. The technology layer focuses on the IT hardware and system software, and upward of version 3 physical elements like Material, Equipment and Facility are included.
Criticism of the ArchiMate layering
To broaden the language with the physical part of the world, the physical concepts were added to the technology layer. The layering obviously still remains IT-centric: the physical concepts in the world have not become a first-class citizen in the ArchiMate language. The layers thus say: ‘In the business, departments and humans do the work. They are supported by applications that are supported by technology. And by the way, we furthermore have physical equipment and physical material within the technology layer.’
Gerben Wierda, who I also mentioned in my previous article about enterprise architecture, has done extensive work on ArchiMate. He has written a book on ArchiMate and in several blogs discusses practical modelling situations. Additionally, he regularly points out aspects of the language that should be improved. A lot of the issues that he discusses are caused by the layering of ArchiMate. He writes:
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 organizing 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.
Before the introduction of the physical elements in version 3, Gerben Wierda already underscored the importance of adding physical elements and philosophized how to introduce these elements in the ArchiMate layers, or possibly discard the layering all together. In the end he seems to opt for the latter strategy: do not use layering in an architectural modelling language.
Non IT-centered layering
The question is: can we come up with layering that is non IT-centered?
As a side remark. Shouldn’t we, like Gerben Wierda suggests, abandon the layering construct all together and create an architecture metamodel without layering? I do not think so. Probably layers will remain an oversimplification of our complex world. On the other hand a fully generic metamodel runs the risk of becoming too abstract and therefore will not be very useful. So, let’s not throw the child out with the bath water, and try to come up with layering that is not IT-centered.
I think by adopting a different perspective, a more optimal layering is possible.
Looking at it differently
Let’s start with the business layer again. Instead of the perspective that it only has to do with the human side of the organization, we interpret it as the behavior that is executed by the ‘organization’ as a whole. With that we mean not only the ‘humans’ but the totality of all the actors in the organizations that can perform behavior. Then, the business layer is about all the work done within the organization, i.e. a business process is the behavior that is executed by all the ‘actors’ in an organization, not solely by humans.
By the way, ArchiMate 3.0 has introduced such a grouping of different types of actors already by introducing the Capability concept in the strategic layer. Likewise, we propose the same grouping on the operational Business level.
Why not split up the business actor into the concepts ‘organization actor’ and ‘human actor’ or shorter ‘organization’ and ‘human’. The ‘business layer’ thus is about organizations (and not humans) and their behavior. Possibly, to prevent confusion, renaming the layer to ‘Organization’ would be better, nonetheless let’s just stick with ‘Business’.
The second layer is about applications in ArchiMate. We extend that to all the different types of ‘active structural elements’ (actors in short) that are able to perform behavior. The second layer then boils down to ‘how’ the organizational behavior is executed. What are the parts of the organization and how do they work together to produce the needed behavior? The human actors of the business layer move to this actor layer and even so the physical actor of the technology layer (‘equipment’). The ‘material objects’ end up in this layer next to the ‘data objects’, and physical behavior is added to this layer so for example we have an ‘Equipment process’. By generalization we rename ‘Application layer’ by ‘Actor layer’.
Finally, the third layer is about supporting the actors with technology or ‘infrastructure’. We keep it the same as in ArchiMate with the exception that, as explained in the previous paragraph, the facilities and material are moved to the actor layer. And we rename this layer to ‘infrastructure’ because its function is primarily to support the actors with general facilities.
An illustration of the new layering approach
Let’s go back to the example in the introduction of ArchiMate and see how it looks with our new layering. The revised model is depicted below, only subtly differing from the previous model.
In this model we have visually positioned the “Recruiter” on the same layer as the “Recruiting application” component. Now both “Recruiting component” and “Recruiter” have the same type or relation to the “Recruiting process”, namely the realization relation. The assignment relation would be a candidate to model this, however, in conformance with the ArchiMate language where the only allowed relations between layers are serving and realization, the realization relation is the better option.
To sum it all up
The new enterprise architecture framework I propose is easily explained as follows. Organizations execute behavior and manipulate objects. This is done by a variety of actors that perform behavior where physical stuff and data is manipulated. To support the actors of doing their work, the organization exploits and uses infrastructure.
In the end the change in the ArchiMate language is not very drastic. The most important change is to split up the business actor into an organization and a human (actor), and move the active part of the physical layer into the Actor layer. The perspective of IT ‘supporting’ the business, is replaced by actors operating the business. Besides, having one actor layer makes it possible to more easily model blended actors like robots or model the internet of things technology.
Above all, the most important improvement with this adapted layering is, that it promotes the perspective that organizations are about getting things done by a cooperation of humans, physical and digital technology.
To end with a philosophical reflection. The goal of this article was to come up with non IT-centered enterprise architecture layering. Again, likewise one may say that the standard enterprise architecture layering is human centric. It has humans on top of a hierarchy where they are supported by technology. This world view is called anthropocentric by the Greek word ‘anthropos’ meaning human.
The proposed layering model has the humans on the same level as physical and digital actors instantiating a ‘different world view’. This world view is in alignment with a ‘philosophical stream’ where humans are not in the center of the world ‘using’ the world, but where humans live in the world in a symbiotic relationship with their surroundings: animate and inanimate. More about this later.
[June 2nd, revision renaming of the Technology layer to Infrastructure layer.]
Originally published at https://www.linkedin.com.
