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.
R&A IT Strategy & Architecture 
I’m not sure of the disadvantage that you’ve mentioned, but I do have a question regarding the example you’ve put together. You’ve decided to model this using the Yellow of Business components and the Blue of Application, yet you’ve referenced “Technology Services” and “Nodes”. I am a little confused as I would have expected these to be in the Infrastructure/Technology Green colour, potentially using the Technology Process notation?
LikeLike
ArchiMate 3 is officially colourless. Colours thus have no meaning in ArchiMate. You can use any colour you like.
I am using my favourite colour scheme, which is in fact a variation on the original pre-TOG ArchiMate colour scheme, with blue for active elements, yellow for behaviour and green for passive elements. I use different colour intensities to express the layers (‘vague’ for business to ‘hard’ for technology — appropriate I would say :-)). This is explained in this (very old — from the ArchiMate 1.0 days) post and in the book. Normally, I put somewhere in the text “In Mastering ArchiMate colour scheme” with a link to the original article, but I forgot to add it this time. I have just adapted the post and added the link.
LikeLike
Funny…
A “BATTO” stack ??!!
– Business
– Applications
– Technology
– Tooling
– Operations
The question is, if “Operations” is equal to “Business”. They have in common that one most often thinks about human beings having the active roles in those layers, but on the other hand, business never asked in first instance for operations*) they rather wouldn’t spent any euro on it if that would be possible. The operations layer is just a result of technology choices.
The same for Applications and Tooling.
So my main question is: “Should check server status” be seen as a business process?
Should we think like “BATTO” or “BATAB” ??
Many questions, don’t know the answer… what do you think?
(I’m fairly new to archimate)
Regards, Remco
*) An exception is of course a managed services company whose primary business is to manage IT.
LikeLike
One might wonder if ‘stack’ is a good way to look at it. A ‘web’ is probably better. I do know that from the start I’ve been of the opinion that everything that happens in the enterprise together makes up the enterprise. Hence, you should be able to model everything in what is thought to be an enterprise architecture modelling language.
With respect to business rather not spend a dime on ‘operations’. That’s like a general not wanting to spend money on logistics. I think it was Eisenhower who strongly argued that logistics is of prime importance. Without the logistics, soldiers have no food, get no sleep, have no weapons to fight with, etc. and they lose. Without operations, the business has nothing to do business with. And to make matters more interesting yet, these days, sometimes the business is the IT, no humans involved except as customers (or merchandise, when it is data about people that is being bought and sold) in some way.
LikeLike
I agree with Gerben’s “web”. I’d add that we should now better see the enterprise as a web of capabilities supporting each other, then when going into deeper details and trying to understand what makes those capabilities, we start to see (e.g.) business that supports technology because that business is the visible part of a capability (e.g Operations) that supports technology from another Capability.
LikeLike
Regarding the disadvantage Gerben hints at, I would foresee it in the consistency of pattern application in a full landscape model. Management functionality can be an add-on, but also be embedded. Modeling embedded functionality would lead to problematic modeling with respect to the inverse layering example at hand because of circular relations (service is both used-by and realized-by component, e.g.), or because it would lead to multiple patterns for the same modeling purpose, which in turn complicates model analysis.
LikeLike
I don’t really understand this (my bad, and as we know you’re smarter than I am 😉 ). What is ’embedded’ here, and how would you get circular relations?
LikeLike
My apologies and not your fault, Gerben, I should have added an example. Sometimes I’m too concise – funny that leads you to think I’m smarter than you, but even you can be wrong sometimes :-). In my opinion, your ArchiMate knowledge and your contributions are unrivaled.
Back to the nice pattern you drafted. I’ll take an example from the application layer, if you don’t mind.
What if the (Application Component) and [Maintenance App] (Application Component) from your example would be the same. Practical example of what I mean by ’embedded’: the settings menu, or authorization panel in a packaged application. Modeling from a construction perspective, there is no reason to consider them differently from primary functionality the application delivers. So, (Application Component) has-assigned (Application Function), and also, (Application Component) has-assigned [Maintenance] (Application Function). Modeling from an a-priori differentiation between primary and supportive functionality (authorization would be the latter, in my example), one could choose the pattern you show here. Now suppose that authorization is first seen as an application management function, but over time shifts to a more functionally oriented employee, or even self-service by line managers. Such a situation could lead to a shift in perception on where the line is drawn between primary or secondary functionality – the modeler needs to choose which is the ‘right’ model, but that line becomes more blurred when the business ‘is’ the IT. Then what? Use both patterns? Remodel? Using both patterns in the same model would introduce the circular relations I referred to: (Application Component) has-assigned [Maintenance] (Application Function) but also (derived) [Maintenance] (Application Function) is used-by (Application Component). Not a problem per se, but it excludes analysis options on your model because it could lead to unwanted results in queries.
I wondered if I could find a good infrastructure example as well. What we see in university research, is an increasing importance of data management. The functionality required there is very close to infrastructure: maintaining data integrity, providing auditability, secure and permanent storage (data vaulting and archiving). The generic infrastructure functions built for this are directly used by the researchers. Data management is becoming an integral part of the research processes, rather than a separate support process.
LikeLike
This is indeed where a disadvantage lies. I was myself thinking about sort of another side of this. If an Application Function or Technology Function is Served by a Business Service, how would you model the Application or Technology interface that is in reality being used by the Business Role? You can’t really. So, the ’embedded’ or even the ‘non-embedded’ interface that in a technical sense serves the human maintenance role can’t be modelled (there are ugly workarounds, I suspect). That is not deadly, but if you want to model to make clear what has to be delivered (e.g. you are building that system) that is a disadvantage.
This all comes back to a truly unsolvable conundrum: if A serves B in a technical sense, but B in a way serves A (e.g. by providing data, ‘push’), the language cannot show both clearly at the same time with the Serving relation. See also at the end of this post over at EAPJ. You can make it clear by choosing Serving for ‘behavioural use’ and Flow for ‘data use’, but then in this case you will run into the limitations of Flow in ArchiMate: you cannot Flow from a Business Function to the ‘lower levels’. It is a point where the layering has not been dismantled.
LikeLike
Occam again: why looking for complexity when there is some consensus about simplicity ?
Whatever the name, there are three levels to consider: enterprise (organization), systems (functionalities), and platforms (technologies).
https://caminao.wordpress.com/2014/10/04/empathy2abstraction/
LikeLike
I might regret this reply for the back and forth that might come from it, but the simple idea that simpler is by definition better is not always true. It might be a useful and practical instrument for the buildup of scientific explanations (Ockham’s Razor) but that doesn’t make it true for design. I kind of like Sydney J. Harris’ remark:
Especially the — generally left out — second part. See this post. Or have a look at Chess and the Art of Enterprise Chess where the uncertainty of the future and the use of scenario planning leads to more complex (but as a result, more robust under uncertainty) architecture.
LikeLike
Right, but Occam’s edge and optimum simplicity can be estimated by the ratio between the number of questions answered relative to the number of primary (asserted) concepts necessary.
https://caminao.wordpress.com/community/building-bridge/
LikeLike
The question if there is an ‘optimal simplicity’ cannot be answered without taking use into account. Different uses require different concepts and lead to a different ‘optimal simplicity’ and there is no single ‘architecture’ use. Also: since all our concepts and uses are part of the real world (and thus: almost always without exact definitions) the analysis is almost by definition a theoretical exercise. In the end, trying to perfectly model the world invariably fails. Using perfect concepts requires an infinite amount of them when applied in the real (not rational) world. So, many people might come up with many different sets of concepts and relations. All ok. Having said that, ArchiMate could be simplified without becoming less powerful.
LikeLike
It seems to me your example is making the false assumption that “business=humans” and “technology=machines.” I consider the infrastructure engineer rebooting the server to be a technology function performed by a human, using a technology level interface. I can’t imagine seeing this in any “business process model,” since this is strictly a function performed to support the technology underlying the application.
However, I will say that this could prove valuable to show IT as a “supportive line of business” like HR and Finance. In this case, technology does become dependent upon the business of IT.
LikeLike
It is not the example that is making that assumption, it has been in the language itself from the start. ArchiMate specifically places the Human in the Business Layer (as a Business Actor, together with more coarse entities like ‘Department’ or ‘Business Unit’ as other examples for use.
I agree with you that this (orthodox EA ) human-application-technology layering is poor, and I’m not a fan of it. The Business Layer in ArchiMate is a bit of an unclear mix of ‘an abstraction layer’ (the business process being Realised by an Application Process for instance) and ‘the human layer’ (Humans, performing Roles, being Assigned-to Business Processes that use Applications through their GIU’s for instance). I would not design an EA language that way myself. But that is not the issue.
Your second paragraph is a good example of exactly why this is useful in actual modelling.
LikeLike
Looking into the ArchiMate Framework I stumbled on this post. Actually I think the Architecture ontology, and the ArchiMate framework is flawed or as you say it: ‘poor’. I think the BAT-layering is better changed in an OAI or OAT layering which I explain.
O is Organisation (~Business) but it confines itself to an abstration or grouping together. In the Organisation layer one looks at the organisation by its processes, functions, organisational entities; so a grouping of actors and behavior. The second layer then I call: ‘Actor’. In this layer the more abstract concepts and layers are detailed to the specific actors (human actors / system actors) that perform the behaviour. Equipment which performs organisational relevant behaviour is also part of the A-layer. And also a human actor is part of the Actor-layer and not the Business layer. Material or information objects are also in this Actor layer. The lowest layer is Infrastructure / Technoloy which is equivalent with the ArchiMate layer but only for begin infrastructural (the other concepts have migrated in the A-layer).
I hope this is somewhat understandable. The goal is to have an architecture framework which encompasses IT but does not confine itself to IT. The ArchiMate language itself does not have to be changed (much) for being in sync with this vision although some changes to concepts I think are logical.
LikeLike
What I do not understand:
Maybe you can model the “support function” this way, but I would never do it this way: My fundamental believe is that for most modern enterprises operations and operations services are part of their business. Why do we have SLA then? Maybe some business people do not see operations at their primary capability, maybe operations is outsourced to someone else, but it is always part of their business. So we have the BAT style for those functions as well. That’s why I think the example maybe possible now, but it’s nonsense or ignorance to do it this way.
LikeLike