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.

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.

Get out there!

Enterprise architects are often accused of “living in ivory towers”. They complain that their work is ignored. Architecture teams have their numbers cut, they are abolished, their staff are scattered around the IT function to “where their skills can be applied usefully”, and architects can be seen as an expensive luxury that adds little value. A good concept that fails to deliver!

A good enterprise architect invariably has significant practical experience at the sharp end of systems development, service delivery, or in the business. Good architects maintain contact with their roots and they develop new ones. This is critical to the execution of architecture work – and we must always remember “architecture is pointless without impact”.

An enterprise architect must have a range of practical skills covering data, applications, infrastructure and the business that they deliver to. The key here is practical. An architect achieves delivery through others. Those others must understand and respect the architectural insight. This means that architects must have credibility when they advise on decisions and implementation.

The foundations for achieving this are experience, sound understanding of the principles, up to date knowledge, well worked through advice and good communication skills.

However, there are other key activities that we have to work at continually:

  • Get out there in the business – I am out at the sharp end of the business at least once a month and I encourage my team to do the same. We need to see the reality of the people who make the money or deliver the service. We need to talk to them and understand their day to day problems. We need to understand the opportunities for improving performance where it counts. We need to observe the impact that our architect work has on real people. We need to see how we have succeeded or failed. Our conversations with business managers and in IT will then have more credibility.
  • Get out there in IT – What is good for the business is good for IT. But here the opportunities to get involved and help are much greater. As architects, we have information, skills, knowledge and tools that can help in development and service delivery. We can take complex problems away and let development and service delivery team focus on their core tasks. If we offer to take a problem away then we must deliver, we must deliver on time, we must deliver a solution that is easy to take on. If we fail then we lose credibility. If succeed then we have people willing to follow our guidance. We also have advocates.
  • Get out there amongst the managers – I want my architects talking to the Head of Internal Audit about business continuity. I want my architects talking to board directors about new operating models. I want my architects talking to the Strategy Director about new lines of business. I could take the credit; I could be in the meetings. But it is my team that deliver; it is my team that need the day to day relationships to be more effective. My team has a lot more bandwidth and capability than I have. My role is to facilitate their involvement, build their business and interpersonal skills, back them strongly when the going gets tough, help them to understand the politics, make sure that the whole team is coordinated, and to support and mentor them so they are effective.
  • Follow through to delivery – Don’t walk away when the concept, the options or the high level design has been communicated. If you do it will be misunderstood, corrupted, its integrity will be violated, or it will be discarded. However well you communicate, no one understands your ideas better than you do, and no one is more committed than you are. When you walk away and your advice falls apart, it is not because it was bad advice. It is usually because it lacked interpretation in the light of reality; it lacked a nuance that you could not have foretold. You needed to be there to make a small adjustment. You needed to be there to say “not in this situation”. You needed to be there to make sure that the job was completed properly. When your advice has been delivered to the business and is achieving benefits then you can move on.
  • Be available – You can schedule yourself into meetings, and take a formal part in projects to get you out there. But you also need to be available when other people want you. There needs to be slack in the schedules to allow informal contact, there needs to be a service culture amongst the architects. We don’t mind if you drop by any time, we are not too busy to build relationships. We have 30 minute “surgeries” every morning for anyone who wants to turn up and talk.
  • Be flexible – In order to get out there, we need to be flexible. Architects needs to cover for each other, architects need to shuffle the workload amongst themselves as a natural way of working. It is critical for me that the team is a self managing team. I set priorities, the team organise the workload to meet the needs without heavy planning.
  • No silos – I got rid of job titles such as “project architect”, “data architect”, “infrastructure architect”, we only have enterprise architects. Everyone has a focus and I try to align this with aptitudes, interests and capabilities. But I expect everyone in my team to be credible cover for everyone else, my role is to grow the skills to accomplish this.

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.