Why do we model?

Welcome to the first ever Cyma blog!

We’ve been actively providing consultancy around enterprise & solutions architecture in New Zealand for 4 years now, but have been reasonably silent when it comes to our online presence. As it’s our 4th birthday this week, we thought – what better time to launch a blog?

For our first blog we thought we start by talking about something that comes up from time to time – why is it that architects spend time modelling?

While sometimes it is about creating a diagram that can be used for communication purposes – but often it’s not. Sure we can model for the explicit goal of creating a diagram for communication, but that is often not the reason why, just because the languages we work with are visual (UML, ArchiMate etc), it doesn’t mean that every diagram we create needs to look good and be used for stakeholder communication.

So what else are we doing when we create models?

A lot of architecture work is about problem solving and thinking through a problem space. Many times the reason to model something actually has nothing to do with the diagram as a communication mechanism but is all about thinking through a problem space using the semantics of the language to help your thinking. ArchiMate is a language that supports this approach very well. It has a rich set of concepts to work with, but unlike UML which has a set of predefined views (e.g. Class diagram, sequence diagram etc), in ArchiMate you can just model whatever you want to model from the full set of concepts in the one diagram. You might not want to keep the diagram when you’re finished, or you might want to create a different view that you do want to use for communication, that’s not the point though when you’re modelling in this mode. Rather you’re using the semantics and features of the language to help you describe a domain. Once you’ve done that you can think about how to use that content for communication.

If you’ve got a good toolset to support you, you may also be modelling for the explicit reason of populating that toolset with information so you can then use that as a knowledgebase. For mature architecture practices this can drive a lot of modelling work. The diagrams used to create the content might never be used for communication purposes, but instead are used as the interface used to create the knowledge inherent in the model.

Hopefully the takeaway from this is the next time you start modelling and creating that diagram, consider what you’re trying to do. If you’re creating it for the explicit purpose of communication, fair enough, but perhaps consider a few questions:

Might it help if you created a non-communication based diagram/model first to work through the problem space?
Are you creating knowledge that might be useful in the future in that diagram? If so, is that knowledge accessible for future use?
Feel free to comment, we want to encourage discussion and participation.