A little while ago, I was presented with a “solution” that started with an over-complex block diagram of a set of inter-related applications with a brief description of each below. This was followed by a description of the technical implementation of the “presentation layer” followed by “business logic layer”, etc. The problem statement was along the lines of "we need to be more agile in redeploying our sales force to address changes in the market”.
My response was to state that we need to explain the story of business change. Within that overarching story there will be an IT story. Both stories must show that we understand where we are today, where we want to get to, the imperative for change, the key decisions that we need to take and the major steps on the way.
At this point I am uneasy because I’m not sure whether I have made myself clear. Do they “get it”? Do they understand what an architectural story is. Yes, everyone is TOGAF certified. But I’m not sure if they have the hard won experience of a grey haired enterprise architect to recognise what is needed to get through the approvals boards and funding committees that will turn their hard work into reality.
My role involves creating, reviewing and often guiding the development of solutions. A question that I often ask to gauge whether they are on top of the solution is “what story are you trying to tell?” My idea was to explain how to tell a story…
Ruth Mallan quotes number 11 from Pixar’s “22 rules of storytelling". “Putting it on paper lets you start fixing it. If it stays in your head, a perfect idea, you'll never share it with anyone." The IASA blog takes this a bit further and relates several of these rules to enterprise architecture.
Why tell a story?
I found Kelsey Ruger’s site “The Moleskin”. Take a look at this article “Storytelling In Business: How Can It Benefit You?” Story telling helps people cope with change, it removes fear, it makes the complex simple, it persuades, and it creates a vivid picture of the future.
What is a story?
More from Kelsey Ruger… “Storytelling is fundamentally a collaboration between the teller and the listener. It helps you to connect with the message on a very personal level.” When an architect is presenting a solution, this is selling, the message needs to resonate emotionally. Only then do the facts become relevant.
A defining aspect of a good story is that there is tension, there is conflict, there is a level of discomfort that keeps the audience engaged. This is a defining aspect of architecture, there is typically a stress between long term and short term goals, between local agendas and the corporate direction, between the strategic and tactical.
How should I tell a story?
Kelsey Ruger again … “stories shouldn’t be just a string of events mashed together” they must have a structure. There a number of standard story structures. Using a familiar structure means that the audience are more likely to follow the story.
How should I structure my story?
In the first act we find out what the problem is, who the main characters are and what conflict there is. This is where we paint the picture of the As-Is, we recognise there is a better way – the To-Be, this is where we recognise there is an imperative to change.
In the second act, the complexity of the problem is presented, near impossibility of resolution, we need to make critical decisions to move forward or accept defeat. This is where we get to the root causes of the problems and start to identify possible solutions, but we discover there is no easy way out.
In the final act, we make key decisions to reach our goal, we make a plan and follow it to a successful conclusion. We make the difficult decisions, we make the compromises or stick to principles, we develop a roadmap, we develop a delivery plan and we govern it through to achieve the To-Be.
But this isn’t enough, is it?
We need something with a bit more depth. This is where Nigel Watts’ Eight-Point Story Arc comes in, it adds enough details to the story structure so that we can construct a story arc for architecture. This structure can be used as a checklist to ensure that a story is complete.
The 8 points, with an architecture interpretation, are:
- Stasis – The As-Is state.
- Trigger – Why now? What is the trigger event that means that we should act now? What is the imperative to change at this point?
- The quest – These are the problems with the current state that need to be addressed. What is our motivation to change?
- Surprise – This is where we determine the goals to be met by the change. We may wish to solve the problems or we may wish to go further.
- Critical choice – The key decisions that need to be made to achieve the goals, or to compromise on the goals. This is where we define our options for change, the change impacts and the decision principles that we will apply in making a decision.
- Climax – This is the big decision where we commit to a way forward with the resources necessary to get there and a change owner to drive the change through.
- Reversal – We reverse the problems and create an improved future state through a roadmap of coherent actions.
- Resolution – The To-Be state.
When I presented a diagram to a boss of mine some years ago, he said “I know that they say a picture is worth a 100o words, but if you can’t summarise message in the picture in a few words then the picture is worth nothing.”
When you want to present your architecture you should try to fill in each box with a few bullet points. If you can then you know that your architectural story is complete. If you cannot then you still have some work to do – you can still present it but you should be asking for guidance, help or time rather than approval.