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.

Trigger

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.

The Quest

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.

Surprise

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.

Critical Choices

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?

The 3 act structure is probably most well known story structure.  What is the Three Act Structure?  How do we use the Structure & Plot to build a 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.

Climax

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. 

Reversal

The 8 points, with an architecture interpretation, are:

1. Stasis – The As-Is state.
2. Trigger – Why now? What is the trigger event that means that we should act now? What is the imperative to change at this point?
3. The quest – These are the problems with the current state that need to be addressed. What is our motivation to change?
4. 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.
5. 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.
6. 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.
7. Reversal – We reverse the problems and create an improved future state through a roadmap of coherent actions.
8. Resolution – The To-Be state.

Resolution

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.

Our profession has a very simple foundation of communication through pictures and words.  If we don’t get those right then we fail, so it is right, sometimes, to go back and ask yourself whether you are getting the basics of communication right.

I read a book called “101 Things I Learned at Architecture School” by Matthew Frederick.  It is about the basics of “traditional” architecture rather than enterprise architecture but I was surprised how much I could get of the book and find relevance to what we do.

The first of the 101 “Things” is “How to draw a line”.  Just as in traditional architecture, pictures at various levels of formality are critical for our communication. 

You need to buy the book to get the specific advice however this page prompts a number of questions:

• what does each line on your diagram mean?
• do the differences between lines – thick, thin, colours, dashes, dots, arrowheads, etc. all have clear unambiguous meanings?
• are you routing lines so they are easy to follow?
• are they crossing?
• are there too many?
• do they take from the “beginning” of the diagram to the “end”?
• when you sketch on a whiteboard, are your lines strong and bold showing certainty in your ideas or are they weak?
• do your diagrams leaving people nodding in confusion?

The most fundamental tool for an enterprise architect is the simple line.  Are you using it right?

About 10 years ago, I was engaged on a short assignment to review a new technology organization's customer service programs.  The company had grown rapidly in a new market that was now maturing.  They had 3 customer service systems.  They had 4 main customer groups served through 4 sales channels.  Each channel used different business processes to execute the same activities and accessed all three systems.  The IT solutions had grown organically with the business and were a mess!  But now, with the market maturing, there were mainstream solutions from major suppliers that could replace these systems that were starting to constrain the business.  However, the cost of resolving this, $15M, was seen as too expensive.

A few years later, the organization had lost its competitive position, had moved from number 1 to number 2 and was taken over by a foreign competitor entering the market.  With a more complex product portfolio, more customer groups, a more complex sales model, the customer services systems were now seen as a major constraint to business growth.  I happened to be engaged through another consultancy to look at the problem again.  This time the cost of sorting it out had grown to $80M.  Again the executive board decided that this was too expensive.

Recently, the organization merged with a major competitor.  I heard that they had embarked yet again on a program to replace their legacy customer service systems.  The market is now much more complex with many more products, it is also more competitive with tighter margins.  The systems have grown in complexity since the last attempt to sort them out.  I suspect the cost this time will be $150M or more.  A ten times increase in cost in ten years. More importantly, the organization was the market leader 10 years ago but now it is in 3rd position with a likely drop to 4th.

The key point is that everything that you build before good practice emerges is likely to be poorly designed and poorly built.  It should be thrown away and you should start over.  If you don’t you will inevitably perpetuate bad practice.  Future development will be compromised because time pressures to deliver tactical business change and the constraint of the legacy.  And the cost of replacing it to deliver strategic business change will grow over time.

Sometimes I wonder why there is so much legacy.  The answer is obvious if you overlay the adoption cycle with hype cycle…

So what are the lessons:

• It is never too late to sort out your legacy
• Don’t build on bad practice
• The so called first mover advantage can be a handicap
• Build knowledge before building solutions

Here are some points that struck me as interesting:

"77% report that they have architectural models representing their current state. Somewhat fewer, 56% report that they have models representing their future state. This could indicate that many organizations have more of a focus on managing complexity, which requires a good understanding of the current state and less focus on alignment/strategy."

"organizations with a disdain for agile (no integration) report the highest percentage of overall EA effectiveness"

"37% of EA organizations have no way to measure EA success"

"6%, have a mature and well-established program"

There are many more interesting insights into the current state of EA but I think I would get in trouble if I relayed more of them...

The first is “nick picking” – identifying an apparent issue and then drilling down into it to minute detail.  It appears to be an exercise in demonstrating how clever the architect is and how dumb the project team is.  The effect often is the reverse.  It tends to destroy the credibility of the architect as a business steward that is safeguarding the interests of the enterprise.

Architects do develop a set of useful instincts that allow them to “sniff out” issues embedded in designs.  But unfortunately, some architects act like the dog in the park that gets a whiff of food and very shortly afterwards is seen tucking into a stranger’s picnic hamper. 

The second behavior is "panicking about nothing” – hearing a rumor of non-compliance and initiating large scale projects reviews, post-mortems and escalations.  Often the scale of the intervention is excessive leaving the architect having to justify why it was so important to “cry wolf”. 

This behavior is a symptom of architects being disconnected from delivery.   The solution architecture will be wrong because it is based on limited information, the project will discover awkward facts that change the original solution.  Formal and informal feedback are necessary.

A disciplined approach is necessary to avoid these anti-patterns…

The first rule is focus on what is important – architectural governance must begin with a triage process that identifies high risk activities.  Restrict governance to those activities.  Yes, you will miss stuff but it is the less important stuff.

The second rule is advise.  You have seen the issue coming through the triage process, so give the project the right advice up front so they don’t make the mistake.

The third rule is support.  When the project team gets to the critical activity, be there!  Make sure they understand your advice and, equally important, that your advice is still fit for purpose.  From a process perspective, there needs to be a mechanism for projects to provide feedback on their decisions.

The fourth rule is communicate.  Write it down - an architect’s instinct should be captured as a principle, a policy, a guideline or  a standard.  The triage process should be documented.  You must get the knowledge out there, continually – do you have an ongoing communications plan?

The fifth rule is be humble!  There is never a need for arrogance.  The project team are the people that give architecture worth because they are the ones that deliver.  You have succeeded when you have helped them deliver business value.  You need their goodwill.

Anith observes that "an application can trespass on the field of data management" and that developers sometimes "treat the database as being a mere component of the ‘application domain’".  Particular skills and experience are required to manage data and to create and maintain databases.  Data management differs on at least two levels:

1. At the programming level, being able to write an SQL statement is not the same being able to design a database.  The set based thinking required to develop design a database effectively is very different to the procedural thinking required by most programming languages.
2. Databases have a different life-cycle to applications and they are often shared between applications.

In my previous blog, Vive la différence, I stated that we do not train people in design.  I think this is a illustration of this point.  We often don't teach an understanding of data management and its approaches.  This results in designers and architects having a poor understanding of the role of databases in the application landscape and people like Anith having to pick up the pieces.

An architect as Tom states "faces towards strategy, structure and purpose, towards the abstract", the role is about ensuring we do the right thing.  The designer "faces towards implementation and practice, towards the concrete", ensuring we do it right.

In 1990, Mitch Kapor delivered his Software Design Manifesto.  He appealed for "design" to get the recognition it deserved as a critical profession in the creation of software solutions.  I thing we have gone part way there.  We have recognized, even if often misunderstood, the discipline of enterprise architecture.  We recognize, but have little formal method, the act of solution architecture.  But we still do not really recognize or train people in design.  In my opinion, we seem to have gone backwards in training people in the logical technology independent fundamentals of good software design.  Rather, we have encouraged technology obsession and limited the careers of good designers and architects.

For those who don't remember or don't know, Mitch is one of the fathers of the modern computing era, he was a founder of Lotus Development Corporation and the designer of Lotus 1-2-3, the "killer application" which made the personal computer ubiquitous in the business world in the 1980s.