You may find the following useful if you want to make effective architecture diagrams more efficiently.
We got interested in this problem because we wanted to determine if there was a more efficient way to give guidance on which approach to take to document architecture, as there are many different valid ways to do it and people sometimes find it difficult to explain what they are about to do. You may be familiar with exchanges like the following:
“I’m drawing a diagram”
“What view is it showing?”
“You know, like an architectural one”
At that point you have to brace yourself and ask to see the diagram. It could be anything, and it could well be a mix of all sorts.
The solution concepts…
Stage 1 - Specify the Architectural Domain
When making a change, it’s important to know which view is affected, in the sense of which architectural domain is affected. It’s fairly normal to break this down into the standard four categories of business, data, applications and technology. It’ll fit in with TOGAF if you take that approach, but doesn’t make you look like you’re overdoing the architecture framework as it’s normal elsewhere.
This allows you to be clear if you’re keeping business, data and applications the same but you’re changing the technology for example as with changing the type of database, or if you’re keeping business, applications and technology the same but there’s some new data, or any combination of one or more of the above.
If we’re all familiar with this, then we have a more refined exchange:
“I’m drawing a diagram”
“What view is it showing?”
“Technology”
“OK! What type of diagram is it”
“You know, like a technology architecture one”
This is better, but we can improve further by being more specific, because within each of the architectural domains there is considerable choice.
Stage 2 - Specify the Diagram Type
Consider the following three assertions:
Because it’s possible to spend huge amounts of time documenting, we should think about what actions we need to influence rather than just how to document the truth of everything, and focus on the areas which support that.
Following the above, we mustn’t forget to make sure it’s actually true, otherwise we’re planting the seeds of disaster. Assuming we’re not pathological liars, our problem is more likely to be that we miss out some relevant information.
We need to be clear about which conventions we’re using, otherwise it’s impossible to know when we’re done, to have good consistency across the work on a project. or even to review work effectively.
Specifying the architectural domain gives considerable benefits for the above, especially for cases like technology changes where the other views really aren’t affected. Many people are familiar with the concepts of the four architectural domains, so with assertion 1 above, it’ll probably be feasible to get people to pay attention to your diagrams showing modifications to the technology architecture and not argue that it’s missing information about business processes.
There tends to be less consensus on choices within the domain, which is a waste because if we can align with the people with work with on what the conventions are for a “deployment diagram” (for example) then it’ll be a lot more efficient to collaborate on creating them.