Pictures paint a thousand words
We make great use of pictures in all types of architecture work, whether it is in the form of component diagrams in detailed solution architectures or core diagrams in the more abstract enterprise architecture domain. These diagrams are the first thing that people look at in a document, and they put a lot more effort into ‘reading’ a solution diagram than reading the written details of the design.
Done well, a solution diagram can become a trophy diagram or project meme, reproduced and replicated over and over again on whiteboards and notepads. Some great examples of such memes would be the OSI 7 Layer Model or even the Periodic Table - diagrams that have taken on a life of their own, and are even used in other contexts such as XebiaLabs’s DevOps Periodic Table.
But it isn’t easy to draw these diagrams. They are the by-product of a lot of deep and structured background work that we call modelling.
Models or diagrams
So how is a solution diagram different to a model? Is a model better than a diagram? When is a diagram all you need?
The problem with trying to answer these questions is that models and solution diagrams are not really similar enough to compare in this way. It is better to step back a bit and provide a definition for the two and illustrate the differences between them.
Models are abstract representations of a particular solution or domain, whereas solution diagrams are specifically graphical representations of a solution or domain. A model will contain a lot of information, not all of which can be graphically represented. Solution diagrams can be used to illustrate aspects of a model.
Of course, you can create solution diagrams without an underlying model. This might be entirely appropriate for smaller projects. But as the scope increases so too does the complexity, and more experienced solution architects will choose to develop a more formal underlying model to help them manage the volume of knowledge and decisions that they are wrestling with.
There are other influencing factors that lead architects towards models, and ultimately modelling tools. If they are working in a large team then modelling supports sharing and collaboration. For example, you can search through a model in a suitable tool, but it is not so easy to search through a folder of Visio diagrams. Version control is another driver towards modelling. Yet another is the pot of gold at the end of the rainbow that we call re-use.
Good diagrams are invaluable
So modelling is clearly important. But the model is irrelevant if the solution cannot be understood, and that is where the architect’s skills are most important. Creating good diagrams is a skill and modelling tools are not very good at producing diagrams - especially diagrams that are consumable by a wide, non-technical audience.
Good architects are naturally good modellers. They understand that without the model, in whatever form it might take, too much is left to chance, interpretation and assumption. However, while their solutions are sound, you might not understand them from the outside.
Really good architects are those who can also create the key diagrams that capture the essence of a solution, such that everyone can understand it.
We are modelling specialist at Cyma, with years of experience on many different tools in many different industries and sectors. We can also draw some pretty good diagrams. If you want to know more about modelling and how to use it effectively and efficiently in your environment, then fill out this form and we will contact you, or if you are interested in our online training programs from our partners at Good-eLearning you can click here.