Five Reasons for Architecture Failure ... and How to Avoid Them

8/11/2019 Five Reasons for Architecture Failure ... and How to Avoid Them

http://slidepdf.com/reader/full/five-reasons-for-architecture-failure-and-how-to-avoid-them 1/4

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 thetrue 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. It’s well worth doing a formal stakeholder analysis to identify the true owners and the beneficiaries.



July 2010


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 it’s 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 theywork 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 otherinterdependent 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


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 - it’s 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. It’s 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

[email protected]

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 pr oject.

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 overmany 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 intendedoutcomes?

Documents

Five Reasons for Architecture Failure ... and How to Avoid Them