Architecture modelling and the Field of Dreams
I used to be a swimming coach, and didn’t always win any friends among my coaching colleagues by telling my swimmers to “challenge everything”. Swimming training tends to rely heavily on the extensive use of ‘drills’ – exercises designed to focus on a particular component of a stroke, but frequently neither the coach or athlete bothers to understand the purpose and desired outcome – they do it because they always have; I used to encourage swimmers to only do a drill if they knew exactly what the aim was. Can you see where this is going?
It’s common knowledge that Enterprise Architects build models, but like my swimmers blindly plodding through their drills, there isn’t always a clear understanding of what the purpose of the exercise is or who will use the information that has been captured.
Hence the “Field of Dreams” reference in the title. Just because you build it doesn't mean they'll come, in fact Catch-22 might be a more appropriate analogy. I imagine you’ll have experienced EA initiatives where “build a model” appeared to be driven by a whole variety of reasons, all of which are characterised by allowing the method to take priority over the overcome:
- Because having one is inherently felt to be “a good thing”;
- Because of some form of crusading zeal;
- Because your architects have just completed their TOGAF training.
So my recommendations for a successful modelling engagement are:
- Know your customer:
Are you supporting the CFO planning future IT investment, providing a design repository for an application support team or capturing a technical reference architecture to provide to suppliers? The approach will be quite different in each case ; - Know the questions you’re trying to answer:
Not only who your customer is, but what they’re trying to achieve. Don’t waste effort capturing viewpoints that nobody wants to use; - Become the fountain of all knowledge:
Make people beat a path to your door, confident in the knowledge that you have the information and that you’re happy to share it. I like this quote from Mike Rosen: “If you make it easier for someone to do their job using your architecture, they will. If you make it harder for them, they will fight against it.”); - Take ownership of the meta-model:
Slavish adherence to your chosen framework at the expense of effective communication with your customers won’t win you any friends. It’s not about the “framework” (UML, Archimate or whatever!) it’s about using whatever you need to to get the message across. - Build it incrementally and iteratively:
Create “just enough” architecture, initially focussing on one area where you can quickly deliver tangible results, and build it out from there; - Make it flexible:
You won’t get it right first time – your knowledge will improve with each iteration, so make sure your method/tools encourage continual refinement. - Focus on the outcome not the tool:
I know of cases where the selection process for the “correct” modelling tool took over 3years. By that time, not only have your stakeholders lost interest, they’ve probably left the company! More on this topic in a future blog.
