Introducing Practical ArchiMate

July 22, 2011 at 9:34 pm 1 comment

The ArchiMate® language has emerged as a great way to illustrate high-level couplings of business processes, people (as roles), applications, data and infrastructure in an organization. ArchiMate is designed to be a visual “enterprise modelling” language, one which is intended to communicate ideas rather than implement them as code. You can view or download the specification here.

I started using ArchiMate about a year ago after hearing about it at an Open Group conference. Since then I have built dozens of models for the company where I work (in the cable television industry). Like everyone who learns a language, I have struggled with how best to express certain ideas. I have not found many examples of real-world world models. Much of what I have learned has come from the ArchiMate documentation and from feedback from fellow employees. I wince when I look back at some of my early models. But it’s getting easier.

At first, some of the other people in our department were a little confused by these new, colorful diagrams. At the time, our in-house standard consisted of “functional diagrams” with stick people, boxes, ovals and arrows. But no two functional diagrams were the same. Some authors included actors and use cases. Some included hardware, while others used only boxes for software. Sometimes lines indicated data flow; other times they meant dependency or interaction.

In my first six months on the job, I did three projects in ArchiMate. The first one pretty much sucked, but by the third one I had established the three-layered “process + function/service + application” design that I now use routinely. After that project, I got an encouraging comment from a project director who said she liked the clarity of these newfangled diagrams.

So to help others who are starting out in ArchiMate (and also to provoke some discussion) I have created this blog with the intention of publishing some of my models here. I think of these models as “patterns”, which may be a bit presumptuous, but I find myself referring back to them time and again. Please feel free to comment!

A word about color: There has been some debate in the enterprise architecture world about how to use color in ArchiMate. The specification uses colors in a way that I find counter-intuitive. Instead of using different colors for different layers (process, application, infrastructure) it colors behavioral elements yellow, while structural elements are blue. Informational (usually data) objects are green (which I like). The problem is that few people besides architects understand or care that a business service is significantly different from a business interface. They find it confusing that the service is yellow and the interface is blue, yet both are meant to be accessible to the business layer.

Forget that noise. I make everything “business” yellow, everything “application” blue or purple, everything “data” green, and everything that is infrastructure another shade of blue, depending on my mood. When the situation warrants it, I use bright red to highlight things users ought to notice. I would love to hear how everyone else does it!

So here goes with the first practical ArchiMate model: a simple case of a browser fetching a web page from a server. This example only includes the application and infrastructure layers, primarily because that is where I find it the hardest to navigate among the possible choices. It’s easy to reinvent the wheel in ArchiMate. Resist!

Simplest model for a web browser talking to a web application.

Simplest model of a web browser interacting with a web application.

In this simple model, I depict the browser and a fictional web time sheet application. No hardware, no browser versions, no HTTP server, no data, no interfaces. Despite its simplicity, this model aligns well with the high-level orientation of ArchiMate. A business-oriented person would have no trouble understanding what the model says.

ArchiMate generally discourages you from modeling two applications as directly interacting. After all, there really is no way to talk to an application except through some kind of interface. But interfaces are pretty low-level and not necessarily “business friendly”. Instead, I like to think in terms of services: what can an application give me? In addition to the obvious decoupling of interface from implementation, services offer a “hook” for relating to the business layer (not shown here). So without further ado, here is our model with a little service layer added in.

Browser using a web server application through a service

Browser using a web server application through a service

For most situations, this would be more than enough detail. But much more can be done. For instance, we can go down a layer, into infrastructure, and model the actual web server and its hardware. Here I am modelling the Apache/Tomcat server as a piece of system software, like a database. This is justified, I think, because of the near ubiquity of web servers today.

I also have added a HTTPS interface to indicate that the browser connects securely. I will admit some uncertainty with exactly how to use interfaces in ArchiMate. I have seen others assign application functionality to them. Personally, I use application interfaces as a way to distinguish paths of access to underlying functionality, e.g. SOAP web service vs. HTML vs.  JMS queue, etc.

Anybody have their own ideas on this?

Here is a more complete model with bells and whistles:

Browser interacting with web server including interfaces and hardware.

Browser interacting with a web server including interfaces and hardware.

I hope this has been some help. Future posts will target server-to-server data integration, business process interactions, weird stuff such as collaborations and interactions, and modelling data. Now go out model!


Entry filed under: Basic Models.

Function, Service, Process

1 Comment Add your own

  • 1. Steen  |  March 28, 2012 at 10:58 am

    I like your thought and ideas…
    Im struggling with same hurdles now but is going to try a real life modeling as I got some extra time in one project.
    Im normaly following Togaf ADM process in my design work (With some tailoring..) but mostly used Viso & PowerPoint for graphical models. But now I have to dive into the Archimate see with help of Archi as we dont have any budget for tools in this arena yet.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Trackback this post  |  Subscribe to the comments via RSS Feed


July 2011

Most Recent Posts

%d bloggers like this: