I get models and diagrams presented to me in many different forms and levels of quality. In this blog I want to look at talk at improving ArchiMate Model Quality by telling a story with your Archimate views, and covering some other basics.
Telling A Story
When I produce a new diagram I will tell a story with it – I will walk through the diagram and try to put it in a number of sentences, and I will think about the value that the view is trying to express to its stakeholders. I will show a fictional example of a motivational view that looks similar to what a junior architect may produce:
What it effectively says:
“We have a requirement for data protection, identity management, and ease of access. We are driven by a need for security services for Microsoft cloud. This has a positive effect on our goal to have end user identity and access.”
It doesn’t really tell me much – I had to look at the documentation for the elements hoping in particular to find if the requirements had rationales, and impacts defined. I was a little lost to what the author had to say. I normally start by looking at the drivers. Security service for Microsoft cloud didn’t make sense, as it is not a reason to do something. In strict terms I would question the value of this view. If I didn’t actually know a little of the subject matter may be really confused.
Finding Some Value In Confusing ArchiMate Views
The diagram above was easy to put into story because of its layout – it was easy to follow the flow of the thinking because the arrows went in a single direction from point to point, even though the actual story was a little confusing from an strict ArchiMate perspective. In some cases where relationships flow in many directions its hard to tell the story. As a disciplined architect its easy to get a little confused when you get a diagram of the quality i have shown – because its arguable that those requirements should be goals, etc… The usage of the elements is wrong. To get clarity we need to forget the strict definition of the elements a little. If you look at it below, a non-architect may actually find this easier to understand.
I could have taken the influencing relationships off the diagram; and start to think about reworking it. Sometimes when I get models from less experienced architects in my head I am doing exactly as above – trying to understand the thought behind the structure – it normally helps me get some kind of value. I of course do the same thing with the relationships as with the blocks. I am abstracting away from the modelling language So the diagrams above provide some value but not much – if we had strictly understood the usage of each element type and each relationship the diagram would look significantly different – and would fit into a larger architecture in a way that makes sense.
It wouldn’t make sense to reuse the elements in this because they are ambiguous and incorrectly typed – so the value to the overall architecture is greatly diminished – although we cannot make things better unless we have a starting point – and I would be positive towards the architect because this is a starting point for improvement and we can now start a discussion around the things that either the architect or the stakeholders find important.
Looking at a better view
With motivational layer diagrams I normally start by looking for the drivers – the reason why, add a few assessments – and work from there.
Lets look at another view:
CWAD Is Consumer Workspace Architecture Domain – a team I used to run. The story this tells:
A CWAD architect, domain lead, product manager and service delivery manager are assigned to do CWAD road mapping. this project will deliver a product level road map, concern and motivation views, and work package implementation and migration views. This project needs to ensure that each service work package is mapped onto a product level road map, is properly scoped, and that rational and related concerns are clearly identified;this will all give us improved trace-ability into CWAD workloads.
The story was easy to tell for a few reasons.
- the arrows clearly go down the page and flow the same way
- The different layers (business, implementation and motivation) are clearly grouped together
- The elements are well named and typed.
- The author is clearly telling a story in the views design – including everything that the reader needs to understand the scope of a project.
When I am trying to read a view in general I start with the business layer, or strategy layer and then work down following the arrows. Within each of the layers I look for the external elements and work inwards – so I will look for external behavior elements (services) and other external active structures (such as interfaces) – and will work from there. A good diagram will highlight those elements. In the diagram above its easy to see because the business layer active elements are at top – and flow downwards towards the other elements.
When creating diagrams I try to follow the order of things in the ArchiMate core model – if i have strategy elements they are on top – the Business, Application, Technology, Physical, Implementation & migration, going down the page with motivation elements on the right hand side because it connects to all layers. Sometimes it doesn’t make sense to do it that way, but as a rule of thumb, you end up with nice consistent models. Having relationships crossing over each other will sometimes push me to changing the order of things; ultimately we try to tell a nice clean story that makes sense. You have probably seen the Archimate Full Framework which has a nice diagram of the layers – I don’t publish it here because that image is under copyright.
It can be tricky to do take that approach on occasions, and you can be forced to do things very differently – This particularly happens to me whenever I do things with implementation and migration because you can be realizing elements in multiple layers, or with requirements realization views that have motivation elements everywhere. I still try to group layers together but its equally important to stop a spaghetti view with relationships crossing everywhere. Another reason that following the flow of layers in the full framework is a good idea is because of the way some of the standard viewpoints fit together – for example Service realization goes from Business to Application – Technology usage sits beneath it connecting application to technology.
People in the western world find it much easier following diagrams that go from top to bottom – or left to right. There are of course times that you cannot avoid to have arrows in different directions. Sometimes diagrams have to be complex. As a rule of thumb if a view has more than 30 elements i think about breaking it out into a separate view.
Some other miscellany
Some general things I do to keep things tidy and consistent:
- Avoid relationships crossing each other on the canvas – sometimes this will end up as a jigsaw puzzle and its not always possible. But mostly it is.
- Don’t use diagonals – I use right angled connections.
- Resize boxes to highlight importance – on a service realization view – I will make the service big.
- Resize boxes to make the line connections simpler. See figure 3 – i made the work package larger in order to avoid having to bend my lines. the association relationships now go straight down.
Summing it up…
These are more guidelines than rules. There are times where its not practical to follow all of the formatting suggestions i have put forward today, and that’s OK. The most important thing to remember here is that every view you are creating is telling a stakeholder a story. We need to do that in a way that makes sense, so we have a little creative licence.
Don’t be shy about getting your views peer reviewed by friends – or asking them to tell your story – it will help you improve your game. Ant view is better than no view.
The more we model and review – the better we get – there’s no one way to do things – but practice will improve your game.