The Open Group recently released an update to the enterprise architecture modeling standard, ArchiMate 2.0. What's new about it is that it aligns with TOGAF Architecture Development Method (ADM), a shift that makes the modeling language easier to use in terms of aligning what architects do with what the business wants. Marc Lankhorst, a principal advisor with Novay and an enterprise architect who served as project leader for the development of ArchiMate, explains to IT Business Edge's Loraine Lawson why this matters and what ArchiMate can do to help organizations with silos and integration.
Lawson: Explain ArchiMate for me and your work with it?
Lankhorst: I was the project leader for the development of ArchiMate, with a number of partners from industry and academia. Initially, we developed a language with the goal to help architects create architecture models, like UML is used for software modeling. So the idea was to have a language that's universal for all architects and helps them to share information without always having the architect present to explain his models.
You're surely familiar with the boxes and lines type of "PowerPoint architecture," and you always have to ask, what is this box and what does this line mean. The goal of ArchiMate was to clarify this, to make sure that you have a standard way of expressing architecture. There's quite a similarity already in the design of ArchiMate and TOGAF because we looked at the structure of TOGAF with its three layers of business systems architecture, information systems architecture and technology architecture, and ArchiMate has a similar three-layer structure, which you'll find in many architecture modeling and design methods. So there was quite a similarity there, but we only covered the core architecture of business and IT systems themselves, so the description of what the organization does is in terms of its processes, in terms of its applications, its infrastructure, but not yet the motivation behind what you do as an organization to get these things running.
The language itself, which was originally developed just to describe these architecture as design artifacts, has now been extended to cover the entire architecture development method (ADM) of TOGAF. Now we have the language to include the motivation behind it -- the stakeholders, the drivers, the goals and the requirements. The language has concepts for modeling those and it also has concepts for modeling projects, deliverables, plateaus, gaps, to also describe how you get from A to B. That's the important change from version one to version two.
It's also driven by what we see in industry, that architecture increasingly has a role in linking business strategy to operations. It's not merely a matter of designing applications. Increasingly organizations are using this to really show how they make their strategy more actionable and get it running in real life and not just on paper.
Lawson: Why was it important to bring the modeling into alignment with TOGAF?
Lankhorst: The main reason is that TOGAF in the process defines a number of artifacts that have to be produced. So TOGAF has a method, and defines which artifacts you want produced as an architect and, of course, if you use models to describe these artifacts, it's useful to have your method aligned with your modeling language. If you look at the concepts in the ArchiMate language version 2, I would say pretty much all of the artifacts defined by the TOGAF method can be expressed in these concepts. So you have the right concepts for describing your architecture deliverables, not only the set of designs of the architecture itself, but also the reasons behind it and the planning behind it; it can all rely on these architecture models. And the idea is, if you have a model that's coherent and binds everything together, then you can do all kinds of analysis, impact of change analysis, looking at where to implement certain requirements, what's the requirements' coverage, do I support my important business goals, do I have a conflict between different projects?
Lawson: Can you speak to how this might help companies deal with silos and integration?
Lankhorst: One important aspect is the language. If you look at the design of ArchiMate version 1.0, it's very much focused on services. And it's not just services, in a technical sense - so Web services -- the service concept is really central to the design of the language because that gives you a clean way of expressing how different parts of your architecture relate to each other without having to look at the implementation details of the application. You can really state what it offers to its environment.
We use the service concepts not only to describe the externally visible functionality of applications but also at the business level. A service is a business thing in essence; it's something you offer as a company to your customers, for example. And we use it at the infrastructure level. So the focus of ArchiMate itself is already focused on integration, initially mostly on these vertical integrations between your processes, your applications and your technology. But we also apply it in many cases in horizontal integration to model how applications relate to each other.
Since we're talking about enterprise architecture, it's not about the details of the technical interface between applications but it's much more on a business level of what this application offers in terms of services that are of business relevance and how you link that to other applications. So it certainly won't resolve the problem of integrating application landscapes, just by having these concepts, but it gives you insight into what these structures are and where you might want to link stuff or to separate stuff.
Lawson: Does doing a model help people identify integration problems? How does a model work for enterprise architects?
Lankhorst: These concepts force you to think about certain aspects of your application architecture. What I see in my consulting practice is that many architects are focused on the technical details of these applications and they see, "Oh we have all these interfaces and it's too complicated and it's linked to everything else," but they lack the means for expressing this at a slightly higher level and extracting from the technical details and focusing on the essence of the problem.
If you look at the applications at a detailed level of abstraction, you don't see the functional overlaps that easily and you don't see what can be the problem in terms of their services. So in rationalizing an application landscape, I also encounter in my consulting practice that organizations first need to step back from the technical details of their architecture to see what the applications do in essence and what their similarities are, which is much more on a functional level than on a technical level. The right concepts to express what kind of services an application offers to its environment can help you in identifying these overlaps, the similarities, the dissimilarities, maybe the gaps even. So that's one way of using it for integration purposes.
Lawson: Is this also packaged as a software? Are there competing tools?
Lankhorst: There are a lot of different tools for ArchiMate. I know of at least 10 commercial tools and several open source tools. So it's used by many vendors in their architecture tools and that's rapidly increasing.
As a language, I would say there's not really competition because there's no other standard in this same area. There are some tools of course that have vendor-specific ways of modeling architecture and you can see them as competitors. One of the main reasons of developing ArchiMate originally is our customers said we don't want to have a vendor-specific solution because then we can only buy their tools, hire their consultants, get their trainers, etc. So, I would say that as an independent language, as an open standard, there is no competition at the moment. Maybe in some limited areas people are using the UML for some of these purposes, but that's targeted at quite a different kind of use.