Part of my day-to-day job consists of providing analysis and modelling support to IT projects. That usually means documenting the status quo and the target architectures in the form of “functional diagrams”. I put this in quotes because there seems to be no single standard for what constitutes a functional diagram.
“Function” in ArchiMate refers to a grouping of internal behaviours, both at the business level and the application level. In theory, ArchiMate functions are not intended to be directly exposed to other layers; functional behaviour should be exposed through an interface.
Gerben Wierda discusses this very topic at length on his ArchiMate Musings blog. He shows how processes can be related by a hierarchy of functions, which probably reflects the reality of many implementations.
To me, however, the ArchiMate notion of “function” contradicts somewhat how function is typically understood and drawn outside of ArchiMate. Most of the functional diagrams I have seen relate actors to some expected application behaviour.
So instead of using business or application functions, I often find myself speaking in terms of a business service that is realized by one or more processes, themselves related to applications that everyone knows. Actors can be added to delineate user roles (see comment below on this).
Here is an example of how I modeled a contact center process for reporting network outages. In this simplified view, a Customer contacts the call center and speaks to a Technical Service Representative (TSR). One of the business services offered by the contact center is Outage Reporting, and the only way to access that service is through a telephone call.
The realization of the Outage Reporting service involves multiple business processes. These are modeled as fairly fine-grained processes because I wanted to show how only part of the overall service was automated.
Note the use of Actor icons instead of “roles” that the ArchiMate specification encourages. I find the notion of “role” to be a little abstract for some people. That’s why I often skip it and depict actors instead. Everyone understands a stick figure.
In the real life there are significantly more details than are presented here, but this view (which was part of a much larger overview of call center processes), captured enough detail to satisfy the project team.
Obviously, much more could be added to this diagram, but I kept it fairly simple. In fact, another set of diagrams describe the applications and their interaction with data and hardware. That’s for another blog post, though.
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!
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.
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:
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!