July 2010

BMT Hi-Q Sigma 2010

1.

Five Reasons for Architecture Failure... (and how to avoid them)
Introduction
In the realm of System of Systems Architecture, there are probably more examples of failures than there are
successes; indeed, anybody who has been involved in developing architectures would be lying if they had not
created what amounts to shelfware at one time or another.
This paper intends to highlight some of the pitfalls where, too often, architectures fail to meet their intended
purpose and what steps you can take to avoid them.
When setting off with an architectural approach to understanding complexity people tend to address the harder
aspects such as:
Selecting a suitable framework and methodology
Training the architecting team
Selecting the right tools
Architecture integration or federation
What are often overlooked are the softer aspects that, if not
addressed, will almost certainly result in your architecture not
living up to its intended expectations.
There are a number of soft issues that you need to consider
from the outset; or if you are already in the process of architecting, then you should stop and put the necessary
foundations in place. These issues are illustrated by the following reasons for failure:
1. Not realising who the true architects are
2. Not selling the benefits
3. Lack of governance
4. Not understanding what the architecture is for
5. Setting the goals too high
Reason 1. NOT REALISING WHO THE TRUE ARCHITECTS ARE
It's very common to find a small team of people who have been given a mandate to conduct architectural
modelling; however, they then quietly work away at defining the architecture without any, or with very little,
consultation with other dependent stakeholders. In doing so they make more and more assumptions or simply
gloss over what they do not know.
The resulting work may look very good, but is it right?
The architecting team may consider themselves as Enterprise Architects but there are a whole range of people
who need to be engaged in defining the architecture; in other words, it is not the Architecture Team who are the
true architects - it is those stakeholders who work within the business and solutions that the architecting team are
capturing who are the true architects. The architecting team are simply facilitators of architecture.
Right at the outset, it is important that you identify who the stakeholders are and their relationship to the domain
of interest. Its well worth doing a formal stakeholder analysis to identify the true owners and the beneficiaries.
July 2010
BMT Hi-Q Sigma 2010
2.

Reason 2. FAILING TO SELL THE BENEFITS TO THE STAKEHOLDERS
Benefits are realised through outcomes so don't get these mixed up with the outputs.
One of the first things you must do is get buy-in from the highest level of stakeholders who have authority over the
scope of your architectural domain - they are the architecture sponsor and must give you a mandate to conduct
the necessary architectural work. If you cannot achieve the necessary buy-in or secure the appropriate mandate
then do not even start.
Once you have buy-in from the top you must then proceed to sell the architectural approach to the lower levels -
again if you cannot achieve buy-in then it will be unlikely that the architecture will succeed.
Buy-in can be achieved through education. We recommend something like a one day familiarisation course for key
stakeholders. The training should focus more on why your stakeholders need to take an architectural approach
and less on how its done. More detailed training can be undertaken once the governance processes are in place
and the tool selections have been made.
Once the architecting work has started, get the stakeholders actively engaged. This can be done through
workshops where you should use the modelling to help focus the stakeholder discussions and reach consensus.
They will also start to understand how the architectural modelling benefits their day to day work.
Better still, get the stakeholders to undertake their own modelling - it may be a paradigm shift in the way they
work but one worth doing. Unless you get that cultural change the architecting initiative will be more likely to fail.
As the architecture scales up this becomes more crucial.
Once the stakeholders start to refer to and correct the models, they are starting to take ownership. If you start to
see the modelling plastered on their office wall then you know that you are on the road to a successful
architecture.
Reason 3. LACK OF GOVERNANCE
Lack of governance or poorly defined governance procedures and policies will result in inconstant and confusing
architectural products with poor traceability, gaps and overlaps. Once this happens the work will quickly lose
credibility and result in failure.
If there is more than one person conducting architectural work then a degree of governance is essential. The more
people involved and the greater the scope then the more attention to governance is needed.
It is important that you get your governance processes and policies defined at the outset and once defined they
need to be constantly reviewed to ensure that they are fit for purpose.
Once your governance structures are in place, then it is necessary to measure the progress and conformance of all
architectural work being undertaken to ensure that it conforms to the laid down governance rules.
A good governance regime should adhere to the following characteristics:
Discipline - A commitment by all of your stakeholders to adhere to the governance policy and procedures
Transparency - All of your stakeholders are aware of the rationale behind your policies and procedures
Independence - Your governance processes, mechanisms and decisions do not conflict with other
interdependent governance organisations and policies
Fairness - Your policy and procedures should not show a bias to any one department or sub-organisation
Responsibility - To act responsibly towards the organisations and stakeholders and not cause unnecessary
damage or distress
Accountability - There are clear lines of accountability covering all aspects
July 2010
BMT Hi-Q Sigma 2010
3.

Reason 4. NOT UNDERSTANDING WHAT THE ARCHITECTURE IS FOR
It is common to see organisations undertaking architectural work simply because it seems to be the right thing to
do. They end up modelling for the sake of modelling and not really know why they are doing it.
A common mistake is to place too much emphasis on the "as is" architecture. Probably the reason for this is that it
is relatively easy - its what we know most about. You must continually ask yourself - is this important, do I really
need to be modelling this?
Unless your intended outcome is to understand what you already have, then you simply need to model enough of
the "as is" in order to understand the "to be".
Document the purpose and goals of the architecture for example in the MODAF AV-1 Overview and Summary
Information. This is a viewpoint that should always be created at the outset of architecting but rarely is.
You may find that the BOSCARD mnemonic is a useful approach to thinking about the important things that you
will need to do at the outset of conducting architecting work. Its a term that comes out of project management
and is used to help define terms of reference:
Background - Provide the background information that includes the reasons for creating the architecture
and mention the key stakeholders (architects) who will benefit from the results.
Objectives - Describe the goals of the architecting work - it may be that you simply throw the work away
once the benefits are realised - think SMART (Specific, Measurable, Aligned, Realistic/Relevant, Time
Bound)
Scope - Provide a high level description of the viewpoints that will be created and the results that they are
intended to deliver.
Constraints - Identify any limitations or conditions that constrain the architecture
Assumptions - Specify the high level factors that are considered to be true
Risks - Identify the risks and their significance with regard to the architecture work
Deliverables - Define key deliverables (Views) that are required to deliver the objectives.
Reason 5. SETTING YOUR GOALS TOO HIGH
You must work within the scope of your mandate and don't try to define a large architecture in a single iteration.
Prioritise and start with limited goals then demonstrate that you are able to achieve them. You can build out once
you have buy-in from the necessary stakeholders.
Be realistic - you can only change those things that you are empowered to change. Even if it is within your
mandate to describe aspects that are outside your realm of influence, you need to engage with the stakeholders
that are responsible for that area; better still, federate with any similar work that they are doing.
WITH SO MANY FAILURES IS IT WORTH THE INVESTMENT?
Absolutely the benefits that can be reaped from an architectural approach are numerous. Simply being able to
understand the complex interdependencies that exist in a program or across a series of related programmes and
projects is enough to justify an architectural approach alone.
We believe that if you address all of these softer issues that we have discussed then you will realise the intended
outcomes of your architecting endeavours and not just simply create yet another piece of shelfware.
So really the question in a climate of austerity and cutbacks is can I afford not to do it!
July 2010

Contact: Robbie Forder
robbie.forder@hiqsigma.com
Tel: +44 (0) 1256 302270
Fax: +44 (0) 1256 302271

BMT Hi-Q Sigma Ltd
Taylormade Court, Jays Close
Viables Business Park
Basingstoke, Hampshire, RG22 4BS

White Paper - Five Reasons for Architecture Failure v2
4.

WHAT ARE THE CHARACTERISTICS OF A GOOD ARCHITECTURE?
At BMT Hi-Q Sigma we can help you with your Enterprise Architecture endeavours. We have a great deal of
experience in Enterprise Architecture and can provide an independent perspective on your programme or project.
As this paper shows, Enterprise Architecture is most likely to succeed if it is carried out within your own
organisation by your own people. We can help you by providing advice based upon our own lessons learned over
many years; we also can help setting up governance and providing independent audits.
We also provide a range of training, briefing and mentoring services that can help ensure that your stakeholders
buy-in to an architectural approach thus helping to ensure that your Enterprise Architecture aspirations are
successfully realised.
Remember to continually asks yourself the following questions and if the answer is no at any time then stop and
put actions in place to resolve the issue:





Is there is a clear and supported mandate to create the
architecture?
Is there a clearly defined scope and boundary?
Are governance policies and procedures in place?
Have all of the stakeholders been identified?
Are people involved and are they demonstrating buy-in
to the architecture?
Are the benefits clear and do they arise from the
journey or the resulting products?
Is the architecture used and is it realising its intended
outcomes?