ArchiMate 3, at first glance, looks like a very orthodox IT-oriented enterprise architecture modeling langage. It can show how the business is supported (‘service-oriented’) by applications which are supported (‘service-oriented’) by infrastructure. This has been the Core of ArchiMate’s view on the enterprise since the beginning. Physical processes and materials have been added to ‘infrastructure’ (which has been renamed to ‘technology’) but even with that we still are in effect talking about a classic BAT-stack (Business–Application—Technology).
From ArchiMate 3 on, however, this strict layering has been loosened in an important way. This is an important improvement, because it was always a rather difficult puzzle to model complex stacks, because of the strict one-way layering. I’ve illustrated this in the following diagram (in the Mastering ArchiMate colour scheme):
On the right hand side, we see our classic BAT-stack of the ArchiMate 3 Core. There is a Business Process performed by a Business Role, the process and the role are supported by an Application Service and Application Interface which are the visible parts of the application. The application itself is supported by a Technology Service and Interface (runtime environment, file shares, database, etc.). Everything that is part of the normal classic stack. But in this diagram, something has been added on the left hand side.
Two things have been added.
First, there is a Business Process that checks the infrastructure every day and that restarts the server if certain criteria are met. The scenario here is that we do not want to restart if we can avoid it but sometimes we have to. This is done by an infrastructure engineer. Now, instead of modeling that the infrastructure engineer also uses the infrastructure (is served by it, in ArchiMate 3 lingo), we have modeled that the infrastructure depends on the engineer’s process directly (to perform well). This is shown in red. Let’s stress this: instead of a human — the infrastructure engineer — using the infrastructure, it has been modeled as the infrastructure using the engineer (to remain operational). If the engineer would have been some automated infrastructure, we would have modeled the dependency likewise. Since ArchiMate 3, we can now express that same sort of dependency regardless of the layers. Many people feel that as IT engulfs society more and more, they become victims of IT instead of masters and they have to do what It demands. ArchiMate 3 is now able to depict that state of affairs.
Second, I have also modeled in the above diagram that the engineer uses an application to manage the infrastructure. The engineer’s application is in turn used by the infrastructure (in blue).
Have a look at this depiction:
In this diagram, you see the blue route from the previous diagram, and it illustrates that the stack in ArchiMate 3 is not only BAT, but also TAB. And it nicely shows how, via applications and technology) the primary business process depends on the infrastructure maintenance process, a dependency that even survives ArchiMate’s derivation mechanism.
There is a disadvantage to this way of modelling, though. Can you spot it? The first post ever on this blog (from May 2011, which actually addressed the issue of operations supporting IT infrastructure) holds a clue.