Free Un-Evil Options Analysis Template
I started off writing a perfectly innocent little article about Options Analysis Templates (which I did) but then I also got entangled in the evil of templates, the perils of architecture via Word documents and complexity data modelling.
Life is full of peaks and troughs, right? Ebb and flow; and it never rains – it pours.
Lately, for me, it’s been absolutely pouring “Options Analysis”, which admittedly is to be expected when you’re a Solutions Architect - “Options Analysis” becomes your middle name.
As it so happens, this deluge of options analysis was accompanied by a recent revamp of the Options Analysis Document we use (or more correctly its template – we’ll call it OAD for short). So I thought I’d share it with y’all (that’s “you all” – it’s sounds a lot more authentic if you say it with a twang).
Here’s the template in MS Word and PDF. Please note, section 3 “Evaluation Criteria” isn’t complete – it will require you to include criteria you deem appropriate, or just remove it completely.
It occurred to me that we don’t always practice what we preach; here we were blindly filling out Solution Architecture Documents (SAD) and so forth – as documents (yes we also model the systems in a tool - for us it’s EA), but surely we can do a lot better – I think we forgot who we were. So I’ve started afresh – I’m taking the range of documents we produce completely apart, modelling the information captured in them (as well as any other artefacts and information we produce) and I’m starting to model them.
The first detailed result of this (still uncompleted work) is the OAD – which I’m basically presenting in this article.
I’m hoping that based on this work I can come up with a much more efficient set of documents; this may even lead to defining a simple Solution Architecture methodology. I guess my aspirations here would be to come up with a simple and easily defined methodology that was to Solution Architecture what SCRUM was to Agile / Project management.
As a aside - before we go any further: I’m not a member of the camp that says that the measure of success for an architect / project is the number or size of documents produced; nor am I convinced that a word document is the greatest medium for “doing” architecture. I don’t tend to open a 7528 page architecture document with an unsurpassed feeling of joy.
Getting an understanding of a design (as portrayed on paper) is not easy, and it’s even harder to keep abreast of changes when they are spread through a lengthy document. Modelling a system in a modelling tool is much better – more visual and you are able to establish actual links and relationships between entities (the model is searchable, potentially hidden impacts are more easily seen, and so on) – indeed proper modelling is more akin to development rather than novel writing. The drawback to “pure” modelling is that it’s not currently as accessible, understood or embraced by other stakeholders (i.e.: your average business user / project sponsor) who typically expect a Word document.
Having said that, the act of committing things “to paper” is often good for centring your thoughts – (I’d like to think that if you can write about something sensibly there’s a good chance other people will be able to understand it too.
The Evil that is Templates
Templates are often seen as evil, and with good reason. I’ve been exposed to a variety of situations where really good templates existed, with superb supporting material, but were ultimately let down by such things as cultural change / resistance.
But the real evil is that many people (unconsciously or not) turned it into a form filling exercise. Rather than let the template merely suggest useful sections and topics (which could be retained or removed as appropriate) users tended to blindly filling them in, which lead to extra work (chasing information that simply wasn’t that important), distorting content to fit the sections they didn’t need, and producing documents with an very low signal to noise ratio.
But the biggest crime was that the people filling out the documents forgot to do their job – rather than do any really useful analysis (which they then clearly and succinctly articulated in an efficient document) they became form filling zombies, where the object of analysis was to fill in a template (possibly in a similar fashion to those poorly skilled project managers who merely tick boxes).
Modelling the SAD and Options paper
The modelling work I’m doing (on the SAD, etc) is really interesting (or I’ve become really dull) – but it’s also incomplete. I want to do it justice when the times right, but for now I do want to elaborate a bit on the modelling of the OAD as its relevant to this subject.
Since I was intending to do some “real” modelling (of the data embodied in the Options Paper) I asked a Data Architect friend of mine to help me.
On the surface it seemed really straight forward. Basically you have:
- The ‘Area of Analysis’ (i.e. the problem) for which multiple potential solution options exist.
- Each option has Pros and Cons, Issues and Risks, Assumptions and Constraints.
- In closing you recommend a preferred option (and justify why) or you say what needs to be done in order to be able to make a recommendation.
So we started having a whiteboard session, modelling the different high level entities and their relationships, and we discovered that it’s actually a really non-trivial problem. This was quite gratifying as my Data Architect friend is no novice (he’s been doing Data Architecture for about 35 years – before it was even called Data Architecture, he’s taught at University level, and he has amongst other things a “PhD in data modelling stuff”), so when he said it was a really hard and interesting problem I felt quite impressed.
The problem is that there are many ways in which pros, cons, assumptions and constraints (etc) can be inter-related; naturally this gets worse the more there are, and it gets really complex when you have two or more “area of analysis” which are related to each other.
 
Please note these diagrams aren't definative - it's just to give you a taste of the initial whiteboarding we did.
We quickly discovered that you’d want to apply what we called a “degree of significance” to specific combinations of pros, cons (risks and assumptions, etc) to help control the complexity, because depending on how strictly / accurately you wanted to model it governed how complex the model became.
It was further apparent that a document really isn’t the best way to do this sort of thing – at least not if you had a relatively complex or in-depth range of options and relationships; a matrix would be much better.
Depending on how you modelled it you came up against an exclusivity arc:
Apparently the options analysis subject was also an example of the 5th Normal Form Problem:
Just on that subject, I asked my friend for his opinion:
“4th and 5th normal form are related really, you don't have to worry about them separately I don't think. Whilst the first article is OK, it doesn't really explain it in terms of how you come across it in designing a database. It makes more sense when it's explained and it only takes about five minutes. I'll do it for one of the fifteen coffees you owe me as it may be the only way to get one.”
More on that later, perhaps.
So, In Summary
- Have a look at the Options Analysis Document Template – I hope it’s useful to you.
- Remember to do actual analysis – not form filling.
- Don’t be afraid to go back to basics – what’s the information you’re capturing in your documents – how does it relate? You don’t have to model it with a view to building a new tool – just the act of modelling it can be enlightening.
|