Reusable Ideas and Archimate in Practice

Communicating an enterprise (or solution) architectural vision to a group of business stakeholders is a non-trivial activity. This is due to several reasons

  • The architecture is attempting to bridge the IT/ business divide
  • There may be significant pre-existing positions and points of view that need to be overcome to ensure a successful adoption
  • Often the concepts that the enterprise architecture is attempting to communicate are esoteric, ethereal or just plain old complicated

Pictures and diagrams help a lot, and a common language or set of symbols improves matters greatly- I am currently using Archimate in Visio to create these diagrams and it seems to work fairly well. But the real challenge comes in dividing up the diagrams to uniquely convey a single point that can be re-used.

What exactly do I mean by this? Well, for a number of years the IT world has attempted to create reusable objects of code- first in procedural functions, then in object oriented programming, now as web services. Whatever technique was used the idea was the same: Invent once, reuse many times. It can be debated how successful this has been, personally I can point to at least a couple of successes where I created or used existing web services and many, many times where the reuse was difficult or  flat out impossible. As we move into ‘higher’ areas with tighter turnaround times, the need to create reusable things becomes ever more important.

I have given up counting the number of times I have read documents created in the business environment that simply consist of cut and paste from other documents. Now that is fine if the purpose of the two documents is exactly the same and the idea that is being conveyed is exactly the same (though this does then beg the question, why are you recreating the same document again? But that is a discussion for another time and place) but most times the purpose of the document is different. At this point you need ‘atomic ideas’: Atomic ideas are difficult to create in words, but diagrams that convey a single point are slightly easier to create as long as you don’t try to overload the picture.

And this is where Archimate starts to come in: It is a rich language and set of symbols that can describe a wide range of architectural scenarios- this is good as the typical enterprise that is attempting to create an enterprise architecture is a complex beast. However, the very richness available through Archimate means that, very much like the UML that it is largely based on, it is very easy to confuse the message a diagram is trying to show by adding in more and more details or fogetting to be entirely consistent in what types of objects you associate on a single diagram.

The rigour necessary to create these truly reusable diagrams can be implemented in a tool- if it creates a set of underlying data, rather than just creating the diagrams. This is what I mean by ‘architecture by model’ as opposed to ‘architecture by diagram’: In a model a Component ‘knows’ that it can connect to another component, it can be accessed by a role or an actor but, for example, it is not possible to connect a component to a department.
Unfortunately, most of the time the reason for creating the diagram is to communicate. And in order to communicate we overload the diagram to help explain things. This would be fine if the diagram were built up of these atomic ideas- the idea could be reused in many diagrams, and a different view on the same set of data would allow the atom to be used for different purposes. But if you are truly creating a diagram then you aren’t using atomic ideas, you are creating a complete picture.

I just think that most people don’t think in terms of atomic ideas: making people think inside a rigorous, formal structure is difficult. Maybe it is because thinking in this way requires a large learning curve and needs you to leave your preconceptions at the intellectual door or maybe most people just aren’t wired in such a structured way. I don’t know what it is, but the ability to create and then use fundamental ideas as part of a structured system is going to be crucial if we are able to build consistent, stable solutions. Archimate helps in this matter, as does UML, but the real leap is an intellectual one: We need (as an IT profession) to be able to create atomic ideas that can be reused as fit for purpose communication to all interested parties (and even a few uninterested ones too) until then we will be stuck doing things by diagram instead of by model.


  1. Hi maguffyn,

    I’ve been using Archimate as modeling language for some time now, and I have found the same limitations and applicability as you.

    There is, however, something else I had to make a somewhat arbitrary decision on: the cutover point between Archimate and UML.
    This becomes most obvious when modeling all the way from the business view towards technical views. UML is clearly geared towards technical semantics but not so rich on business modeling, and vice versa for Archimate.
    My current practice is to do business structure and behaviour all in Archimate, doing high level information entities in Archimate too, and information systems at a conceptual service level. From there, I recreate the IS services as UML compoments and do UML from there.

    This is more pragmatic common sense than rule-of-thumb however. What’s your view?


    1. Bart,

      You make an excellent point: the divide between the ‘enterprise’ architecture (Archimate) and the ‘system’ design (UML) is not clear.

      I have worked in a company that attempted to enforce this separation through the use of separate tools to model business activity and system details. You can guess how sucessful this approach was (Hint: It wasn’t)

      So now, like you, I have a rule of thumb that I (internally) apply to determine if I will create the diagram in Archimate or UML. Unfortunately, this rule of thumb is like much of my data modelling- I do something one way or the other because it ‘feels right’ rather than having any hard and fast rule that I have decomposed a Process Model to the 3rd Level or I have broken the systems down to components, so now it should be a UML model.

      And yes, I do find myself occasionally recreating objects in both Archimate and UML, but until we get a single tool that will support both seamlessly that is just the price we have to pay.



  2. This is an excellent observation on a focused problem space of communicating architecture… I’m currently using Archimate as a tool to communicate the conceptual linkages of my enterprise’s integration technologies. So far its going ok, and I’m finding that it takes multiple architectural viewpoints to paint a complete picture of the problem space.

    I agree it’s absolutely essential to enforce the meta-model of the modeling language when modeling. Furthermore, it seems that Archimate has a more ubiquitous medium of communicating ideas. It would seem any architectural model requires an architect to walk a business person through it. However I think one of Archimate’s selling points is that the models become a heck of a lot simpler, at the cost of sacrificing low level clarity. Having multiple views of the same problem existent in different layers of abstraction also helps.

    I guess my point is that it doesn’t quite matter so much if your audience is clueless about the meta-model as long as the model’s author has conformed to it. We don’t have to understand quantum physics in order to behold the beauty of a rainbow.


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