This post is part of a series about the “How and Why of ArchiMate”.
When I am asked the question “What is ArchiMate?“, I usually provide the same simple answer: “A (foreign) language for Enterprise Architecture“. But the real question people should ask is “Why ArchiMate?“. And here is my answer…
Before even starting to speak about ArchiMate, we have to widen the scope to the practice of Enterprise Architecture. Enterprise Architecture is about understanding the complexity in which an organization evolves, and helping this organization to manage changes. In this context, “Enterprise” is not a synonym for “organisation”, but is the purpose (some would say the story) of this organisation. Thus, as Enterprise Architects, we have to first understand this purpose and share it with all stakeholders. Then, the preparation work can begin and, again, we have to share it with all stakeholders.
Simply put, communication is more than half of the work of an Enterprise Architecture practice.
But if communication is such a big part of our job, then how can we make sure we are understood? How can we find the best way to communicate?
Telling stories with visuals is an ancient art. We’ve been drawing pictures on cave walls for centuries. It’s like what they say about the perfect picture book. The art and the text stand alone, but together, they create something even better. – DEBORAH WILES
In our practice, communication is embedded in what we call “architecture description”. This architecture description should be as effective as possible and mix both visuals and texts. But as it targets multiple stakeholders we, in effect, often end up describing the same architecture using multiple “stakeholder-related dialects”.
And here is the start of the answer to our question: ArchiMate® (a standard maintained by The OpenGroup) has been designed from the very begining to support effective communication. ArchiMate is not about standard boxes and lines, it is all about a common language that provides the foundations for a good architecture description. In addition, the ArchiMate standard also provides some guidance on this topic (that’s the purpose of the “Stakeholders, Viewpoints and View” chapter of the standard).
Using this “language” analogy, and simplifying a bit:
- ArchiMate contains a rich vocabulary that covers most domains of Enterprise Architecture (Strategy, Motivation, Transformation, Business, Application and Technology).
- ArchiMate is based on a grammar similar to natural language (subjet|verb|object) to describe what people or “things” do, and adds an external, service oriented, view of those activities.
- ArchiMate (default) notation is very similar to spelling as it provides a way to “save ideas on paper”.
Using the language without its notation is already of great value as it allows people to understand each other. By “each other” I mean people from the organization you work in, but also people from other organizations you interract with. Should you have a need for some external help for your architecture work, you can simply ask for people who know ArchiMate.
Of course, using the notation is another value increment as it will allow you to mix visuals and texts. However, some stakeholders may be unsure of such a formal notation, so don’t hesitate to simplify it as much as possible, or even use an alternate notation in some cases. You should always keep in mind that ArchiMate is not the goal, but simply a means to achieve it. The real goal is to make your architecture easy enough to understand so that people can make the right decisions, and decide which moves are the correct ones.
Of course, one could simply use pen and paper (or drawing tools) to work with ArchiMate, and this would already be of great value. I personally almost always use whiteboards to discover a new topic, elicit discussions with stakeholders and first draft an architecture. But at some point, the volume of information to keep at hand requires a tool. In the context of ArchiMate, such tool is known as a modelling tool. A good modelling tool (such as the open source tool Archi) simplifies the work and limits the burden of maintaining an architecture description. A good modelling tool helps you to maintain the coherence inside your model.
But as soon as you move from drawing to modelling, you can also start exploring and analysing gathered information. This is an often overlooked feature, but provided insight is another great value of ArchiMate modelling.
So, is ArchiMate a one size fits all language? Is it the perfect solution for any problem you might have? Of course not!
As with any solution, ArchiMate has been designed to solve a specific problem. In our case this problem is the (in)ability to describe an architecture in a way that makes it understandable by most stakeholders. So as soon as we move out of this scope, then ArchiMate gradually becomes inappropriate.
The best way to understand it is to see a typical architecture work as Damien Newman’s “the Squiggle”. When first confronted by a new topic to work on, we then start to understand it. This “research” forces us to go back and forth with one simple goal: finding the right question to answer. Then we slowly move to the “coherence” phase in which we can explore possible answers to our refined question. Once this is done, we can then move to the “details” phase in which we dig deeper into the details needed for implementation (whatever “implementation” means in our context).
For each of these phases, we need to rely on different methods and tools:
- “Research” mostly relies on note taking tools in whatever form (pen & paper, mind mapping…)
- “Coherence” mostly relies on common language and high level modelling. This is the scope of ArchiMate.
- “Details” mostly relies on domain specific language such as UML (for software design) or BPMN (for process modelling).
A good architecture description should of course contain all this, but at the minimum, we should make sure we have a good and coherent overview. It’s ArchiMate’s role to support such overview, but also to provide “links” to other phases through some well thought overlaps (high level concepts like Capability and Ressources, but also Grouping to link with “Research” ; Business Process, Application Components and Nodes to link with “Details” in UML and BPMN…).
Time to wrap up?
Let’s summarize:
- If you work in the field of Enterprise Architecture, being able to communicate with your stakeholders is key.
- When dealing with architecture, communication is achieved through an architecture description.
- An architecture description that targets Enterprise Architecture’s stakeholders must rely on a common language.
- ArchiMate has been designed with this exact goal in mind: providing a common language for Enterprise Architecture.
- ArchiMate provides value in increments: common language, common notation, ability to analyse gathered information.
- ArchiMate is not a silver bullet.
- ArchiMate should be used to create an overview of an architecture with just enough details (and if needed those details can then be described using other, more suited, domain specific languages).
So, a question for another post: How to quickly create value with ArchiMate?
One thought on “Why ArchiMate?”
Comments are closed.