November 17, 2010

Modeling locations with Actors in ArchiMate

One of the issues that we bump into often is the question how to model a location in ArchiMate. Recently there was a long and interesting thread about this subject on the LinkedIn group for ArchiMate for example. Several options were suggested, including a suggestion that the ArchiMate language should be extended. In this blog post, I will set out my "solution" to the problem, as well as point out some issues with it.

First of all, note that the ArchiMate metamodel has three layers: business, information, technology. In this respect, it seems that location fits best in the business layer even though it can be argued that a node in a network can also be considered a location... For this post, I'll stick to the business layer. Even more, there are three columns. active structure, behavior, passive structure. Active structure concepts are able to beform behavior. Passive structure concepts undergo behavior. In my opinion, location doesn't naturally fit either, but I'm willing to accept the argument that an active structure concept fits best based on the fact that "in a location, certain behavior takes place". In my view, then, the best concept for location comes from the active structure part of the business layer and thus I select the Actor concept.

A simple example shows how this works. Assume that we are modeling a firm that develops tools and does consulting to support those tools. The company is based in two locations: Netherlands and Belgium. Typical behavior at a high level is modeled using Business Functions as these provide a nice stable basis for further develompent.

In this view, a labelview was applied to denote business processes that belong to certain business functions. It is easy enough to combine these processes into an "end to end" process for further analysis. For example, lets say we're launching a phone campaign to promote a new tool release where we offer clients advice (upgrade or not?), and do the actual deployment. Here's the diagram:

So far so good. Modeling becomes more interesting when realizing that the Actor concept is also used for other purposes. Most notably, the actor role is also used to denote who performs a certain role as illustrated in the following diagram

Here we see two things. On the one hand, the color view depicts that certain parts of the new campain can only be performed in the Netherlands whereas other parts can be executed in both countries. Another aspect that is visualized here is that the phone campaign is performed by a call center which can either be done by people from an external department or by people from the consulting department. The other parts of the process can all be done by someone from the consulting department.

Note that the Actor concept is used for two different "things" here. This works relatively well and in my opinion no new ArchiMate concept is required at all. It does seem that new ArchiMate users/readers might be confused by this double interpretation of a single concept. Therefore, some care should be taken to make sure that everyone is on the same page (i.e., by developing clear modeling guidelines). Also note that modern ArchiMate tools such as BiZZdesign architect have the option of using a profile to further stereotype model concepts which helps in analysis, visualization and communication with different groups of stakeholders.

3 comments:

Tom Graves said...

Nice 'solution', though I'd suggest that those quotes around the word 'solution' are quite important...

You'll know my opinion on this: it's a nice 'solution', but it's a kludge, forced on you by the IT-centric limitations and history of the Archimate language. (It's a good kludge - I think you've done a great workaround for the problem here - but it's a problem that shouldn't have existed in the first place if Archimate had been done in proper generic architectural form rather than solely for the IT-industry.)

I don't know who suggested in that LinkedIn list that Archimate needs a property or entity for location, but I would agree with them - and I would suggest quite a few other entities that are needed, too. And we need these changes now, before the existing IT-centrism of the language gets too far embedded in stone, and renders the language unusable for true enterprise-scope architecture other through a morass of inappropriate kludges like you've had to do here.

Dunno if this helps, because I'm well aware that you're largely stuck with Archimate as-is at present. I do believe though, that rather than putting our effort into inventing kludge-workarounds, we should be putting much more pressure on the Open Group/Archimate to fix these glaring gaps in the language in the first place. Anything I can do to help you that latter concern, please let me know?

Best wishes etc
- tom g.

Anonymous said...

Very interesting approach, even though we can feel that you are touching he current limits of Archimate. This is my gut feeling when reading you, maybe wrong, I don't use Archimate myself, but this is what I thought about first when reading you.

By the way, I really like this 2 color thing. Even if it can be messy if we start to add more color. In fact, I would like to use icons (same kind of setup as MindManager on what is called map markers if you know them). Icons with filtering capability will offer you additional benefits and clarity.

Best regards
Emeric Nectoux

Unknown said...

Thanks for the comments so far! I agree with both of you that we may be pushing the limits of "current ArchiMate" here. Once used to it, this solution actually feels pretty natural and I haven't seen a convincing argument yet to extend the language with a new location concept yet.

Having said that, I agree with Tom that the language does need further extensions. I like the whole motivation extension (stakeholder, concern, goal, etc.) that was recently developed. I think we should push that a bit more and extend the language with such things as:

- concepts to model people aspects more, such as "sense of beloging". Not sure if a full-blown open social-systems approach would work, I think we'd always be hammering away at it from a technical systems perspective but still, worth discussing

- concepts to model strategic considerations such as market positioning, competitor analysis etc.

With respect to what enectoux wrote: the color views are actually generated by BiZZdesign architect. Any property of any model object can be visualized this way. Since custom properties of model objects can be defined / stereo-typed, this mechanism is actually very powerful. If you need more info: please get in touch!