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.