Starting again with TOGAF

Some years ago, my career became “managerial” and “consultative”. I was moving away from enterprise architecture. My TOGAF renewal came up and I decided I no longer wanted or needed it. My feeling was that nothing fundamental had changed in TOGAF, it was growing bloated and was serving the architecture training industry better than enterprise architects.

Things changed. I was asked to review a solution, did it meet the long and short term needs of a business. Should the organisation “bet the business” on the solution? Was the solution part of the organisation’s digital transformation?

It was a quick review but it re-awoke my inner architect. I was much more fulfilled by the mental stimulation of architectural thinking. So, I returned to an enterprise architecture role. And the client required that I was TOGAF certified!

Did this old dog’s ego get out of the way and allow me to discover some new tricks?

I decided to buy the TOGAF study guide. I must say that the Open Group website is uninspiring and unattractive, I like to think of enterprise architecture as creative and dynamic helping businesses understand how to change, how to grow, how to create compelling propositions. Did the Open Group website inspire me? No! Staid and old fashioned were the phrases that sprung to mind – I think a refresh was in order to help attract more people into the profession.

However, it was easy to find the self study pack.

A bunch of documents arrived in a zip file. I unzipped it and guess what … two of my pet hates (this isn’t going well, is it?) … the files were in a set of nested directories and the files had names like B180p and N181p. Seriously, have the authors of this study guide ever used a computer? It is painful to navigate up and down a file hierarchy with 18 files in 12 directories where each file has a cryptic name requiring every file to be previewed in order to discover the file you want to view.

Oh and 18 pages of preamble that I don’t care for before I get to Chapter One!

I bought the 505 page study guide so I was determined to study it but I was a little irritated.  Yes, yes, my complaints were trivial and I got over them in seconds but why not make it easy?

I must be positive! I must be positive! I must be positive!

After several weeks of trying hard to read this stuff, I abandoned it and went on a crash course at Firebrand because the client was getting impatient. The course was excellent, I came out with the certificate, I could look the client in eye, the presenter was someone that I vaguely knew and suitably pragmatic rather than a zealot.

Seven Rules of Business Alignment

This article originally appeared in the The Cutter Journal on 30 November 2008.


In this article, I describe an operating model for business alignment drawn from 27 years of experience, working for both consultancies and major end-user organisations in a variety of industries. The key points that come out of this experience are:

  • Alignment among all parties involved in business change is the issue: the business consists of multiple parties that need to be aligned; IT is just one of these parties.
  • The start point for alignment is communication.
  • Enterprise architecture is a vehicle for facilitating alignment.  It provides an information base that shows us where we are and allows us to assess potential futures.
  • Enterprise architecture as an approach has a part to play in business strategy, business change, and its traditional home in IT.
  • Enterprise architecture provides tools to understand, plan and govern change but for  effective delivery it must be integrated with program management
  • The information, stakeholders, and processes used to manage alignment through enterprise architecture are different but related for business strategy, business change, and IT.  Our change management organisation must draw on people from across the organisation at all levels.
  • Whereas alignment must be driven from “the Business”, it may not always be best equipped to do this, in this case it may need support in the form of “Business Architecture as a Service”


Anglo-American business communication has evolved a terse and concise style that is accepted as conventional wisdom.  I am guided by the editorial guidelines to adopt that style.  However, I will not fully comply.


I have learned both through instruction and experience that to communicate with those of differing backgrounds and cultures that saying the same thing in multiple ways, providing additional context and painting rich word pictures are essential.  If I do it and equally if those that I am communicating with do it then there is a greater prospect of mutual understanding.

This point is relevant in the discussion of alignment.  Alignment is a personal thing influenced by background and previous experience.  Misalignment is caused by misunderstanding.  Business effectiveness is better served by waffling to mutual comprehension than by adopting the cultural norm of clipped, brief and cryptic messages that are misunderstood.

The first rule of alignment is effective communication.


Before I get into the core discussion, I need to set out some definitions to try to avoid misalignment of understanding and expectation:

AlignmentThere is alignment between different areas of an organisation when they are working to towards mutual compatible goals and their actions to achieve those goals are coordinated and compatible.
Positive AlignmentIn addition to the actions being coordinated and compatible, the actions and activities that different areas of the organisation carry out are synergistic; they reinforce each other and create additional value.
ArchitectureArchitecture is the process that ensures you do the right things right.
IT ArchitectureIT architecture is the process that ensures that the right IT systems (i.e. they meet business functional and non-functional needs) are implemented in the right way (i.e. they make effective use of technology and resources).  It is requirements management and solution design at the enterprise level.
Business ArchitectureBusiness architecture is the process that ensures the business has the right internal and external boundaries, has correct governance, effective processes and capabilities to deliver its customer propositions, appropriately managed risk while meeting its financial targets.  It operates at the strategic, transformational and operational levels.
Enterprise ArchitectureEnterprise architecture is an encompassing governance framework that ensures that all areas of the business, including IT, operate in an aligned manner.  It negotiates between each area and balances the constraints that one area puts on another with the enablers that one business area puts on others.
Macro ArchitectureMacro architecture is concerned with the grand design of things.  It ensures that we have defined and agreed a conceptual solution.
Micro ArchitectureMicro architecture is about the implementation of our grand designs.  It ensures that we have dotted all the I’s and crossed all the T’s.  We have removed the straw that will break the camel’s back and we have found the devil in the detail.

The second rule of alignment is develop a shared vocabulary.

Problems of non alignment

In all cases where I have been involved in setting up the control functions to ensure alignment during business change, it has been a clear and vividly communicated statement of the impact of failure that has persuaded the organisation to invest.  Key participants in the changes have understood, from their own or others past and painful experience, huge potential for serious error.  The following examples are taken from major organisations that did know better but did not act.

ScenarioUnintended consequences
Functionality in a customer service system is de-scoped in order to reduce timelinesThe functionality that was de-scoped would have saved 2 minutes per call in a call centre with an average call length of 5 minutes.  This issue was not identified until go-live.  However, call centre staff had been made redundant in line with the expected productivity improvement and call centres were understaffed for several weeks until functionality was completed.  Customer service was adversely impacted in this period.
Functionality in a back office system is de-scoped in order to reduce timelinesThe functionality removed was required to automate back office validation of high value distributor orders to support straight through processing for new B2B web channel.  Retaining the manual step would have meant that contractually agreed SLAs with distributors would have been breached.  Organization went live without any checks of high value orders in order to achieve SLAs and avoid losing the confidence of new distributors.  This put the organization at risk from fraud until the functionality was completed.
Go-live for a new eCommerce site was scheduled just after the peak trading for a retailerThis resulted in key user inputs being scheduled during the planning period for peak trading. These key users could not be made available resulting in major schedule slippage which damaged the business case. The consultancy carrying out the delivery work did not understand the business calendar and its implicit timing constraints in sufficient detail and did not communicate the implications of the schedule at a detailed level.
Operational business readiness was considered as a “business-as-usual” activity and not tracked by the project delivering and a new customer service systemThe delivery of new procedures, procedure manuals and training for call centre and back office staff was managed as part of the delivery project.  There was no budget available to pay overtime or bring in temporary staff in order to free up key staff to carry out these activities.  No-one was made accountable for business readiness.  The outcome was that at go-live the business was only part ready. Services targets were missed resulting a backlog of cases which took several weeks to clear through working extended hours in the call centres.
Business partner communication was considered as a “business-as-usual” activity and not tracked by the projectA financial services company was launching new products through its distributor channel.  The marketing function ran roadshows with the distributors based on the originally planned capabilities to be provided to distributors and delivery schedule unaware that both had been changed.  To its embarrassment, the company had to realign expectations through an additional communication program.
A customer service application was re-platformed in a change that was supposedly “transparent” to the business. Therefore the business were not informed of the changeThe performance characteristics of the new IT platform were markedly different to the old platform under real operational conditions.  Response terms were very poor at peak times resulting in staff resorting to manual paper operations.  A backlog of cases built up which was cleared over six weeks in overtime.  IT could be criticised for poor testing but, by not informing the business of their plans, they did not allow the business to assess the risk and put in place contingencies.
An IT supplier outsourced its B2B website delivery to its incumbent static website developerEarly releases were successful.  Then a release failed, the developer did not have a roll back plan and the web site was out of action for nine weeks resulting in a major revenue loss.
A call center system that had been upgraded to support a product launch.  The system was allowed to run with a number of problems for a weekThese “teething troubles” resulted in a large and growing backlog of cases and it was decided to roll back.  The roll back was cancelled when the huge scale of manual processing that would be required to support the new product was understood.  Instead the organisation hired temporary staff to process the backlog cases over several weeks.

Some of these examples, which are based on real issues within real organisations, should help develop an understanding of how small actions deep inside the organisation can have major impacts. They show that it is essential to have micro-level controls to deliver macro-level changes.

These examples show the consequences of poor management of change.  In summary,

  • At the strategic level, getting the macro structure wrong may mean significantly higher costs of operation, longer process execution times, longer time to market, and reduced competitiveness.
  • Similarly, with poorly defined business processes, there are likely to be higher costs of operation, longer process execution times, longer time to market, and reduced competitiveness.
  • Without a clear view of current business processes, target processes, and progress of all solution elements, delivering business change is likely to be very painful.
  • If business change is not under close control, then it will be near impossible to ensure that IT releases are coordinated with business change.

The third rule of alignment is understand the consequences of failure.

Alignment scenarios

Having defined alignment as an abstract concept, let us now consider some situations where is a necessity:

Scenario TypeScenariosIntended outcomes
Strategic change planningDivisional reorganisation, change in market structure or conditions, exploring new market propositions, reacting to competitor activity, major regulatory change, international expansion, merger/acquisition organisation design, channel strategy.A new operating model and change program has been designed that has commitment from all key stakeholders.  The model has been rigorously tested to ensure it will deliver its objectives.  The program has been tested to ensure it is deliverable.
TransformationMajor computer package implementation, customer service program, execution of merger, shared services, business process re-engineering, business process outsourcing.Closely choreographed set of activities by multiple parties potentially inside and outside the organisation.  Risk, issues, deviations and exceptions identified early and controlled.  All aspects of change remain aligned.
Business as usual changeBusiness process optimisation (e.g., handheld device store scan routes, call centre computer telephony integration), management information, data quality improvement, introduction of new communication approaches.Close coordination of activities within the project.  Full understanding of impacts and dependencies on other projects and vice versa. Coordinated scopes, deliverables, dependencies and timelines among projects
Technical changeOperating system, hardware, storage, network, software, telephony version upgrades and patches, re-platforming,Full understanding of the business impact of failure or poor performance, rollback plans, communication of the benefits and risk to the business, agreed scheduling and acceptance of the risk with the business.

These examples are again based on real situations within real organisations, and the view of success is what was used by those organisations. The examples start to indicate the micro-level controls required to deliver change successfully.

The fourth rule of alignment is understand what “good” looks like.

Strategies for delivering alignment

In my examples, I have emphasised alignment of delivery rather than alignment of objectives.  My experience is that many large organisations concentrate on getting the goals right and getting “buy-in”.  The follow-through is often weak or missing.  Agreeing to conceptual corporate goals is easy, developing delivery plans is harder, and maintaining those plans and delivering alignment is more difficult still.

We need an end-to-end change delivery process that ensures alignment of goals, investment, plans, solutions and delivery.  So what is the process that we need to go through?


The strategies to be adopted are:


The first key question that we need to answer is – Where do we want to go?

Once we know this, we need to do some due diligence. We need to be able to model various operating model scenarios against business objectives.  We need to bring these models to life in a way that enables key stakeholders to visualize operations, run scenarios and consider intangible dynamics such as customer satisfaction and brand awareness as well as the hard numbers.  We also need to understand the numbers, our prospects of success and our capability to deliver.  We need high-level operational models to validate the assumptions in the spreadsheets.

If IT have the correct profile within the business to be invited to the strategic table, then they have a role.  How will IT support the proposition, the capabilities, and the internal and external organisation models?  If IT are not at the table, then the probability of a failure of alignment is magnified.


Once we have a direction, we need to understand our destination, determine the route, agree the investment, plan the actions we need to take to get there and shape a program to deliver them.  This is simply a standard approach to program planning.  But I am describing it here because experience tells me that often this stage is done extremely poorly.

What does the future look like?  To plan a large-scale program, we need to understand what we are building.  To motivate people to change, they need to understand their future and the part they play in it.  We need to create an initial “business roadmap” which describes the key changes to processes, organisation and IT systems over time.  This is a core enterprise architecture activity which is a key driver for the structure of the change program.  It provides a sound basis for understanding risks, issues and dependencies, and it provides a baseline for managing change.  It ensures that all change activities have plans that are in alignment.

What do we need to do to get there?   Each stage of the roadmap dictates a coordinated set of changes to processes, organisation, locations, and IT systems.  The projects that need to be delivered, the major milestones for aligning projects, the key resources, the stress that the organisation will be put under all emerge from the plan.

Is our plan safe?  Major change programs are normally under huge pressure to deliver benefits and to achieve a return on investment.  Very often entirely foreseeable issues arise during the program that threaten the business case.  The enterprise architecture roadmap provides a good basis for understanding these threats, each element of the roadmap can be perturbed in such a way to test the effect on the overall plan – e.g. what if we can’t hire the right skills, what if a business partner pulls out, what if the technology doesn’t work, what if the new building is delivered late, what if key people leave.

Once we have a secure plan, we can ensure we have the skills, funds and time to deliver.  Unfortunately, too many change programs are launched with too little thought, they fail to deliver as much as they could and they fail the people involved.


Delivery is all!  We must turn our plans into positive operational business results.

A secure plan has to be executed; it also has to be changed to take account of changed needs and unforeseen reality.  A business change program requires complex choreography of many moving parts – suppliers, buyers, resellers, partners, customers, employees, sales, marketing, customer service, logistics, training, investment, processes, organisation structures, and IT systems.  All of these must be aligned.

It is difficult enough to ensure that all areas of a business operate in alignment when things are relatively stable.  When we are trying to change the business, alignment becomes very much harder.  The solution is an old one – it is a Program Management Office, a PMO.  But not a normal PMO, an enriched PMO.

An enriched PMO manages delivery alignment by managing the delivery of the “business roadmap”.  To do this it needs to be enriched by business and IT people who ensure that the roadmap is delivered at the detail level. The roadmap changes when it needs to change. A single vision of the future and a single plan to deliver it is assured.  The enriched PMO works at the detailed operational level; it manages the devil in the detail.


Transition of a change into successful business operations starts at the beginning of the change program.  At the start of the process, we were talking about bringing possible futures to life through models; we must continue to bring the future to life to test the future and gain acceptance of the future.  Acceptance is a process that takes time; there are techniques that bring the future architecture to life – conference room pilots, prototyping, model offices, simulations, etc.  These are typically used to explore the solution and improve it.  But they are equally valuable in helping people understand what the solution will look like when the roadmap is delivered.

The fifth rule of alignment is have a change management process that includes and integrates program management and enterprise architecture.

Information requirements

In order to deliver an aligned business change, we need to be taking several perspectives on information.  The pervasive IT-centric view of enterprise architecture typically has three core IT related views (applications, information and technology architectures) and a single business architecture view.

From an alignment perspective, this skew towards IT is not helpful.  The perspectives that we have looked at so far in order to drive alignment and the modeling capability required to achieve alignment are:

Strategic Planning
  • Balanced scorecards
  • Strategy Maps
  • Product / proposition models
  • Capabilities models
  • Organisational models
  • Business environment interaction models
  • Business unit interaction models
  • Risk models
Business Change
  • Process models
  • Procedure manuals
  • Organisation models
  • Training courses
  • Locations
  • Transport schedules
  • Product configurations and parameters
  • Product documentation and literature
  • Partner, supplier and customer links
  • Customer service scripts, FAQs

And lots more…

Business as Usual
  • Process models
  • Procedure manuals
  • Organisation models
  • Training courses
  • Locations
  • Transport schedules
  • Product configurations and parameters
  • Product documentation and literature
  • Partner, supplier and customer links
  • Customer service scripts, FAQs

And lots more…

  • Process models
  • Applications models
  • Information models
  • Infrastructure models

There are a several key points to note.  The point of commonality is business process; the critical point of alignment is around business process models.  The business change and business as usual lists are the same.  They are also the longest and they span the whole business, they are an expression of the detailed implementation of business process.

The sixth rule of alignment is develop a single shared business focused information base that shows where the business is, where it is going, and how it will get there.

Working structures

Now we have thought about a process and the information that we need to operate the process, we need to design an organisation to execute it:


The best people to manage change in a particular area are people who know that area.  However, they need coordination, process, discipline and support.  This is the role of the Solution Authority.

The Solution Authority, as well as providing ensuring rigor through formal structure and process, should provide support and guidance.  The traditional British “bobby”, perhaps now largely historical, is a good model for any sort of governance organization.  Out there, friendly and helpful but also carrying a short baton and handcuffs.  In line with the current propensity to adopt a services approach, this might be termed “Business Architecture as a Service” (BAAAS).

The seventh rule of alignment is build a change management organisation that utilises the skills and capabilities of people across the organisation at all levels, and support to ensure rigor.


This discussion is intended as a starting point for developing a comprehensive change management function that can control large-scale change and deliver an aligned organization.  It is critical that alignment not be seen as an IT issue, because that will skew governance and miss the bigger picture of aligning the whole business.


Alan Inglis is a seasoned CTO and Enterprise Architect with over 10 years’ senior management experience.  His  career has been characterised by roles operating on the boundary between the business and IT in business strategy, IT strategy, enterprise architecture, and business transformations.  He has headed the architecture functions at 4 London Stock Exchange listed organisations.  He has advisory consultancy experience in the retail, insurance, utilities and telecommunications sectors.

Alan is a delivery oriented strategist who has developed business focused and practical IT strategies for a variety of major companies. He is a change manager who has led large complex business change programs, including ERP implementations, creating shared services customer services functions and outsourcing / offshoring.

Alan has developed productive commercial relationships with top industry suppliers enhancing value and quality of service through joint action to improve processes and exchange business information achieving cost reductions of up to 50% on multi-million dollar contracts.

As a passionate and committed leader, Alan has driven improvements in development and operations.  He is an enthusiast for the growth of others who has developed and led high performance teams that have a passion for their work and have fun doing it. He provides mentoring on both a formal and informal basis.

Alan is recognised as an industry expert in IT effectiveness (Effective IT Judge & Conference Expert Witness – 2007) and a thought leader in enterprise architecture.  His blog, Chief Architect (, is listed in the Datamation Top 200 Tech Blogs

Alan has a broad technical background in development, support and infrastructure roles in IBM Mainframe, Windows, UNIX and AS/400 environments. He is a Chartered Member of the British Computer Society, MBCS CITP.

the stress ball market is on the rise

Just as the state of the construction industry can be used as a proxy measure of a country’s prosperity, the state of technology can be judged by the number of stress balls in circulation.

I went to an exhibition in London recently and was overwhelmed by the number of stress balls that I was given. I couldn’t collect all tee shirts, bottle openers, pens, flash drives and mugs on offer. I couldn’t enter all the competitions to win drones that I was asked to enter. The technology suppliers obviously have some money available for marketing.

Another interesting feature of this and other exhibitions that I have been to is how relaxed the salespeople were. They were waiting for prospects to approach rather than aggressively grabbing every passerby. Does this shows a level of confidence in their offer? The established suppliers seem to be putting their more junior staff on the stands – I guess the senior staff are busy closing deals.

It was the small companies that had the most interesting technologies. They were creating products and making the latest technological trends into something that you can touch and create value from.

A slightly worrying comment from several of these small innovative companies was that they felt shut out of major organisations. Their procurement policies sometimes favour the larger established suppliers. Partnering with these large suppliers often made things worse by closing routes to market rather than opening them. However, the small companies were determined to “find a way to build the business”.

The follow up of the companies that I spoke to has been excellent – timely, informative but not pushy or intrusive. I had one highly professional 15 minute online product demo that generated a number of ideas that I will now pursue. I feel these guys will get a lot of business.

There seemed to be an abundance of small companies from outside the UK trying to break into the UK market and looking for partners. Brexit was worrying some of them slightly but most were not particularly concerned – “people find a way to trade no matter what the politicians do”.

I came away from the exhibition feeling positive about the UK technology market. Innovation and entrepreneurship were being displayed. There may be a lot of stress balls out there but high levels of stress were not evident. The little guys were determined to overcome any obstacles – “we will find a way”!

The danger of passion…

Like many enterprise architects, I am extremely passionate about my work. I like to work with and employ passionate people. But the passion that creates drive, which causes them to push through when others would stop, is dangerous. It can override sensitivity to other people’s feelings. It can mean poorly thought through action prevails over a considered plan.

If you are about to employ a passionate person then think it through. Get them to work through tough scenarios. When they miss out on a promotion or pay rise because they upset a key person who doesn’t understand passion, how would they deal with it? When a colleague actively obstructs them, how will they handle it? When the strategy that they have worked on for six months is rejected by the board, what will their reaction be? Can you help them think things through without stifling their power? Can you protect them? How would they avoid the situation? How would they reduce the damage caused to other people and themselves? How will you look? How will you deal with the problems that a passionate person can cause? You need to understand how you will use and direct this passion for positive effect. You need to understand how you will manage the risk to yourself and your passionate employee.

As a passionate person, you need to understand that how ever much your employer talks about wanting people who are passionate, this is usually a myth. The job adverts and person profiles are mostly written by “dry old fish” who wouldn’t recognise passion if it came up and kissed them. They are writing to attract staff, they may be half copying someone else’s work, they are selling. You are buying, you need to make sure it is not a con. Can your new manager cope with you? Will they protect you? Is the political situation one where you will be easily provoked into rash action?

Take a walk around the office — it is easy to spot passion — there should be raised voices, there should be people standing around talking animatedly about work. If there is quiet, if people are huddled in their own cubicles with little interaction then there is no passion. A passionate person communicates and shares. If there is quiet then you will be a misfit. Are you willing to be a pioneer and create some, at least initially, unwelcome noise? Does your new manager really want you to disrupt the current peaceful working environment? Is your new manager prepared to take a risk? Is your new manager prepared to have some fun?

The hype cycle vs legacy…

I am going to talk about a consequence of the hype cycle that seems to be missed by many. I will use an anecdote to illustrate the point…

Some 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

Architecture Is …

Architecture is about connections.

Architecture is design.

Architecture is science.

Architecture is engineering.

Architecture is creative.

Architecture is future gazing. 

Architecture is making the future real. 

Architecture is art.

Architecture is questioning.

Architecture is thinking. 

Architecture is understanding.

Architecture is sense making.

Architecture is being outside and looking in. 

Architecture is being inside and looking out. 

Architecture is play acting. 

Architecture is waving your hands in the air. 

Architecture is passion. 

Architecture is drawing pictures. 

Architecture is story telling.

Architecture is performance.

What story does your architecture tell?


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.

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


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.


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:

  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.


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?

Enterprise Architecture Migration Planning – Timing is Everything

Architects will often think of their work as having 4 major phases:

  1. Develop the As-Is model
  2. Develop a To-Be model
  3. Develop a migration plan
  4. Govern the plan delivery

I am interested here in the third phase, migration planning. Let’s define a migration plan…

There are two primary types of migration plan:

  • A formal transformation program – this will typically be a major replacement or upgrade of the IT landscape that underpins major business change
  • A set of policies that steers IT change

There will always be business and IT changes that fall outside formal change programs. These will require governance to ensure that they do not derail the program. A light touch approach to smaller changes avoids diverting scarce resources unnecessarily. The light touch is a set of policies managed into projects supportively (I have covered this approach elsewhere). I want to focus on transformation programs.

The original Zachman framework had columns for data, function and network – the traditional IT domains. It was later extended to include people, motivation and time. The importance of time dimension is often overlooked, particularly the top two rows which cover business cycles and business events.

It may seem obvious that the time dimension is critical when planning large scale change but I have seen on several occasions that no attempt is made to understand this. The result is that an otherwise well formed plan is rejected and the authors condemned as having no business knowledge. A devastating loss of credibility for an enterprise architect.

First, business cycles…

Pretty much all organizations have an annual financial cycle. This will include start and end of year, budgeting, budget revisions, internal and external reporting. There will be periods within this cycle in which the finance department and potentially some managers throughout the business will be no go areas for business or IT change.

Running alongside the financial cycle and closely related to it will be the business planning cycle. Again this puts load on certain managers and creates management stretch which reduces the capability of a business to adsorb business change.

Many organizations have seasonal sales cycles. Retailers, for example, will have peak sales in the run up to Christmas – changing retail systems or making business change during this period will not normally be allowed. To be fair, this is usually picked up, what isn’t always understood is the upstream effect of the peak period. The supply chain is full before the peak period as product is stockpiled ready for the trading rush. Therefore, the supply chain change freeze will start earlier than the retail change freeze.

Other industries will have their own cycles which need to be understood in order to create sensible migration plans. And there are other cycles such as recruitment cycles e.g. organizations that take on large numbers of graduates or schools leavers will have business cycles driven by school and university term times.

Next business events. Many businesses will have schedules of events such as price changes and marketing campaigns that cause localised stress on particular business areas and their supporting systems. These create what are effectively informal mini-change freezes throughout the year.

The next mistake that is often made is scheduling delivery too close to the change freeze. Changes must have time to bed down in the organization and systems often need to be stabilised. This should occur when processes are not under stress. Any fixes should not be severely time constrained.

The net result of considering business cycles and events is that the time periods when major changes can be released into the organisation can be very constrained. In addition, bringing in change before a peak in the business cycle can result in major benefits over bringing it in after. This means that we need to design releases carefully into the organisation’s calendar in order to drive maximum benefits. In turn, this means that we may need to compromise the solution from the technically ideal in order to ensure timely delivery. This compromise is best done in a planned way rather than as a reaction to schedule drift – i.e. rational compromise is far preferable to emergency surgery.

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!