What story does your architecture tell?

Stasis

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.”

Surprise

Why tell a story?

I found Kelsey Ruger’s site “Kenzie Creative”. Take a look at his articles on storytelling. 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… “ When you are dealing with complex situations, topics or people, stories offer a way to bridge the gap through the use of what is called universal truth stories.” 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 1000 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.

Drawing a line…

Early in my career, I was in a meeting where we were talking about a project. The lead architect drew a picture consisting of blobs and lines. The diagram was presented with certainty throughout and positioned the speaker as a key expert. Each blob and line was explained clearly except one…

I pointed at a part of the diagram and asked, “I think missed the explanation of one of the relationships, what does this line mean?” There was a disapproving glare and a sharp answer “there is a relationship!” The tone made it clear to me that the real answer was, “I was glossing over the fact that I don’t know and now you have embarrassed me!”

Perhaps I could have asked the question in a less challenging way. However, that aside, presenting certainty when there is none can cause serious issues as a project progresses and create and build on unacknowledged assumptions.

Sometimes, however experienced you are as an architect and however “strategic” you are in your work, sometimes it pays to get right back to basics. The issue often is how effective is our communication? In the communication of ideas through pictures and words are we being clear? If not 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 relevant 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 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?
  • is the labelling meaningful and informative?
  • are you routing lines so they are easy to follow?
  • are they crossing?
  • are there too many blobs and lines?
  • do they take the audience from the “beginning” of the diagram to the “end”?
  • does the diagram tell a story?
  • when you sketch on a whiteboard, are your lines strong and bold showing certainty in your ideas?
  • are the lines weak indicating your lack of clarity?
  • do your diagrams leaving people nodding in confusion?
  • could your audience use your diagram and explain it to someone else accurately?

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

Complex diagrams = bad architecture

A pet hate of mine is complex diagrams that I cannot read on my laptop without zooming in and out and scrolling around. They may be fine for posters that are put on a wall but they are not generally useful architectural artifacts.

I am going to state the obvious – most people look at documents and diagrams on screens or on printouts that they carry around. The size of these is pretty consistent at around A4 size. If you cannot read and understand a diagram that is that size then the diagram is a waste of effort. So, please have some consideration for your audience when creating diagrams – it is a simple and common courtesy.

But I said it is “bad architecture”, surely this is bad presentation. First, since communication is critical for architects, then poor communication is bad architecture. However, the point is deeper than this…

Good architecture is well modularised. It is separable logically. A large complex domain can be decomposed into multiple simpler domains with clean simple interfaces between them. This implies that a set of hierarchical diagrams can be created to represent the architecture each of which can be understood on their own and with sufficient contextual information. So, going back to the communication point. If the architecture is good then it can be presented simply. Is there any benefit in making simplicity appear complex?

What about the as-is? If the current architecture is a mess of spaghetti then how can this be represented simply. Well, this is a core part of the architecture skillset! Logical partitioning is a critical step towards resolving the mess. In short, you must partition it logically as you would a good to-be architecture and what you will be showing is that interfaces are not clean and the components are not well formed. This gives you a start point for refactoring. Showing a mess by producing complex diagrams highlights the problem but does not help solve it.

Please don’t produce complex diagrams, there is no need, ever! I do not want to waste my time trying to understand another diagram with 200 blobs and 500 lines on my laptop again. The person who produced this diagram had the knowledge and has singularly failed to transfer it effectively. That is bad architecture and failure for an architect!

It’s not about numbers

Some years ago I was appointed as an interim manager to be Head of Architecture for a FTSE 100 company. The scope of my role was applications and infrastructure – business and data architecture was under another manager.

I had a team of 16 architects who had over the last nine months produced numerous architectural artifacts. They were very clever documents explaining all the options that had been evaluated, the evaluation process, the decisions made, and the reasons for each decision.

The team had lost its direction; it had done a lot of abstract architecting but nothing (zero, ziltch, nada, nix, diddly, zip) had been delivered. There was no plan to achieve delivery. Now was the time to get active and use this stuff to shape the IT service delivered to the business. We needed to get the application and infrastructure implementation teams to deliver the architectural vision that had been so painstakingly developed.

How did we get there?

  1. Get the right people
  2. Understand your customer
  3. Get a process
  4. Get some architectural artifacts to support the process

The Right People
I wanted architects who had the following traits:

  • Understanding of the business
  • Rapport with managers, users, developers and infrastructure staff
  • Verbal and written communications skills
  • Technical knowledge
  • Pragmatism
  • Bravery
  • Ability to operate with minimal supervision

I interviewed the team and I moved 12 out of 16 out of the team. Yes, that’s right I was left with 4 team members. I now had a strong core team capable of being a high performance self managing team.

Who is the customer?
As enterprise architects we have a complex customer base. Our aim, like all people working for the organization, is to help achieve the aims of the board of directors. An effective architecture team is visible at this level and has to be mindful of the impressions created at this level. For example, expensive resource that cause delay to business change will not last very long.

The business middle management implement change, applications are just a part of the change they are delivering. Sometimes they are parochial, narrowly focused, and often highly political. They have the ear of the directors and can make or break architecture and architects. You have to play the long game, sometimes compromising on minor details to ensure that the major gains from architecture are not lost.

The users experience the results of architecture. They have the ear of their management, they too can make or break architecture. It is absolutely essential that solutions are usable when they get into the hands of users. You cannot blame the developers for poor implementation, you cannot blame managers for cutting the budget. If the solution doesn’t deliver for the users then the architect is to blame.

Architects don’t implement, other IT staff or contractors or consultants or outsource partners do that. They consume architecture and deliver applications and infrastructure solutions that should meet the needs of the business. Get architecture right and delivery is quicker, cheaper and higher quality.

Get a process
The keys to the process are:

  • Put the most effort where there is the most risk to the business – you need a triage procedure.
  • Get in at the beginning (or before that if you can) of a project
  • Understand project requirements
  • Ensure that the project is aligned to business goals (if you don’t do this then you are not an enterprise architect)
  • Guide the design so that it fits as best it can with the enterprise IT direction – make rational compromises, make sure that IT and business management understand the compromises (this also builds credibility as business aware pragmatists)
  • Keep tabs on delivery in a non intrusive, non obstructive, non policing way e.g. be available to give advice throughout delivery, be a “free” additional project resource
  • Be present at the post implementation review and benefits review (if your organisation doesn’t have them then organise them!)

Get some artefacts
In this case, we had more artefacts than we needed. We had to make them digestible, intelligible and interesting to our customers who were not architects. A three inch thick document making technical recommendations can be reduced to a single page with the decisions. Our work was finding the relevant facts for each of our customers at each stage of the process.

In other organizations, I have started with no artifacts. That didn’t stop us working with projects, we just delivered the key artifacts that we needed as we went along. You may have to work long hours but you don’t waste your time producing superfluous documents.

However many architectural artefacts you have there will always be a job to identify what is appropriate for your audience and to create or customise a deliverable to meet their needs.

How did we do?
We moved from academia to providing value to projects and securing service delivery inside 2 months. Five of the right architects were delivering more value than a team of 17 had previously. It’s not about numbers; it’s about the right people doing the right thing.