Enterprise Architecture- The Case for the Defence

• Introduction

Enterprise Architecture has been understood as a formal concept since before the turn of the millennium, emerging as a real-world discipline arguably with the publication of TOGAF 7 in 2001.

This provided a widely accepted basis for practice of EA and, as a result, we might imagine that it should by now be reaching a state of maturity and consistency. The case for EA is strong, and is becoming well accepted, at least in principle, across most large and medium sized organizations.

However, there remain significant concerns about its applicability and practicality, leading many inside IT and in the broader business community to question its long term value proposition.

Over time, we have dealt with many large enterprises as they endeavour to make good on the promises of EA, and have helped guide many along the road to sustained, successful architectural transformation. In this series of whitepapers we discuss the core issues faced by many EA functions in creating and maintaining their credibility, with particular focus on their ability to prove their worth to a wider circle of stakeholders.

Later in this series, we will examine the major anti-patterns leading to failure of EA efforts in large organisations, and discuss some of the practical ways in which EA can be made to fulfil its major promise to enforce the link between IT and business motivation.

In this paper we examine the strengths and weaknesses of the EA discipline, as currently practiced, and introduce ways in which the path to maturity can be made shorter and less risky. A critical factor in this more rigorous approach is an understanding of the need to configure the practice, from the start, as a business capability.

Enterprise Architecture as a Business Capability

Many organisations make a passive assumption that, whatever benefits EA can bring can be realised by a group of trained, intelligent and well-intentioned individuals, supported by comprehensive methodologies and software tools.

By contrast, viewing EA as a business capability implies that an organisation considers the PEOPLE, PROCESS, TOOL and KNOWLEDGE components, when building and sustaining a practice. In addition, serious attention must be given to the CULTURAL CONTEXT into which the EA Practice is injected, ensuring that full and appropriate support is in place, and that the collective behaviour of the organisation is aligned with an agreed ‘common good’. These five components must be considered in depth, designed and implemented in a consistent, mutually supporting manner to deliver the initial promise of EA.

Figure 1: Components of a Business Capability

The Benefits of Enterprise Architecture

Many whose working lives involve Enterprise Architecture would be able to list and justify the arguments for EA as a professional discipline. The arguments themselves are generally strong and well understood, but these same individuals often feel frustrated that, although the case for EA is a good one, the execution of EA in many organisations is flawed.

Observing the results of this poor execution (without considering the causes) has led to a widespread perception that EA (although a worthy idea) is often unworkable in practice. Unfortunately, this in turn has led many to question (misguidedly) the value of the concept itself, rather than striving to eliminate flaws in execution.

Organisations in this situation should start by examining the strength of the benefits which a well-implemented EA practice should bring, and determining what needs to be done in their own case to implement EA more robustly. A carefully crafted, agreed and communicated path to maturity – tailored to the circumstances of an individual organisation – is the key to long-term success for an EA practice.

The Case for Enterprise Architecture

Since the early days, the same common strands of argument have been used to justify investment in enterprise architecture. As we review them, it is noteworthy that most of these arguments have become even more significant to forward-thinking businesses in the intervening years. The case for EA should therefore be stronger than ever, and it should be incumbent on any organisation wishing to take EA seriously to ensure that the execution matches (and therefore achieves) the potential.

Commonly cited arguments for EA include:

Argument 1. Enterprise Architecture establishes and maintains a strong link between IT investments and business drivers. Formal, well-managed traceability ensures that, when money is spent on IT, there is a well-documented set of reasons for the expenditure, and a common understanding of the expectations for benefits that will accrue.

Argument 2. Enterprise Architecture supports efficient use and reuse of IT resources. By understanding where money is best spent to yield business benefits, allocation of scarce resources (manpower, money, plant) can be performed in an intelligent and optimal manner. Furthermore, by maintaining a comprehensive and authoritative picture of the IT landscape, the ability of the organisation to re-use elements in different but analogous circumstances is significantly improved.

Argument 3. Enterprise Architecture underpins an organisation’s ability to respond to business change in an agile manner. Once again, because the IT landscape is widely and deeply understood, the effect of externally-imposed change is understood more quickly and reliably, leading to higher responsiveness and lower attendant risk.

Argument 4. Enterprise Architecture provides a strong, disciplinary backbone to IT deployment, based on a common, well-understood context for varied stakeholders. Because of the breadth and depth of knowledge encapsulated in a well-constructed EA environment, there is a stronger likelihood that all impacted parties will be talking the same language. Two beneficial corollaries of this are that:

a. less resources are used in communicating and re-communicating ideas that were only partially understood (or understood in different ways by various parties);

b. the trust in the professionalism of the IT community on the part of the remainder of the business is strengthened.

Argument 5. Enterprise Architecture allows complexity to be understood (and thus risk to be controlled and reduced where possible). Typically, complexity causes additional resources to be consumed and risk to be increased. If any part of the complexity can be eliminated because it is unnecessary, the costs and risk are therefore reduced. Achieving these reductions relies on the organisation’s ability to recognise and analyse complexity and, as a result, to design it out. Enterprise Architecture brings the knowledge to support and enable this in a reliable, scientific manner.

The Case against Enterprise Architecture

Despite the undoubted strength of these arguments, the fact remains that a substantial proportion of EA efforts fail. Many of those that persist get (at best) a mixed press from the wider business community.

Some of the arguments most commonly used when raising critical concerns about enterprise architecture are:

Argument 1. Enterprise Architecture costs a lot of money. Well, yes it does! But a more appropriate way to look at this is in terms of the benefits it brings for that cost. A well-run practice needs to have established and implemented metrics to measure and demonstrate the worth of EA. In organisations where EA is successful, a culture shift has taken place which recognises and accepts the inherent worth of the discipline (in much the same way that people do not generally challenge the need for sound financial management or legal compliance as a matter of principle).

Argument 2. Enterprise Architecture is complex and arcane. Once again, this is undoubtedly true. Care must be taken when exposing this complexity to a wider audience, to ensure that it is relevant to their communication needs, their appetite for knowledge and that it is packaged to be as digestible as possible. Even more fundamentally, care and effort should be spent on demonstrating the relevance of EA, and the benefits it brings. As a rule, once people

a. understand how something relates to the problem to be solved in general and

b. recognise that it is being dealt with competently,

they worry about complexity less. The architects are then trusted to do their job, recognising that their role is important and contributes to the organisation’s success.

Argument 3. The precepts of EA often conflict with the priorities of projects and programs in the IT community. Architecture has a very significant role to play in transformational activity (e.g. projects and programs). In the early stages, the focus is on analysing business needs, recognising the benefits related to them, shaping and scoping projects/programs to deliver features addressing these needs. In general terms, the reasons for architectural thinking are clear at this point, and there tends to be less concern raised regarding the role of EA. Later, however, the architecture function is charged with ensuring that the project/program remains architecturally compliant and that it realises the benefits originally stated. It is at this point that conflicts of interest arise with the default priorities of implementation projects – budgets and timelines. Again, the reasons for EA intervention and involvement need to be constantly reinforced and supported by senior management. Design of the practice operating model and organisation model (embodying roles and responsibilities) needs to take careful and explicit account of this.

Argument 4. Enterprise Architecture practices have a high failure rate, as borne out by surveys conducted by market intelligence companies and consultancies. There are two significant questions which need to be addressed with respect to this failure rate:

a. Do these failures result from adjustment of internal priorities? In some cases, resources (money and manpower) were reallocated to other areas judged to be of higher importance. This in turn begs the question of whether the previous EA organisation failed to deliver, or failed to demonstrate that it delivered.

b. Was the EA practice which failed actually performing Enterprise Architecture, or was involved in some other related activity under an EA banner (see Disguised EA, below)?

Figure 2: Root Causes of EA Failure

Root Causes of Failure in Enterprise Architecture Efforts

This fourth argument (high failure rate) highlights the underlying risks of embarking on an EA effort, reinforcing the need to identify and deal with the factors behind these risks.

Any organisation establishing an Enterprise Architecture Practice should give careful consideration to the underlying causes of failure. By doing this, they can determine which of these causes are directly relevant to their own case, understand and mitigate the risks involved.

There are several common factors which contribute to the majority of these failures:

• Poor coupling with the business: A fundamental factor in successful enterprise architecture is the ability to trace the lineage of decisions about IT investment back to the business priorities which drove them. It is imperative that these reasons:
  • are well understood,
  • are well documented, and
  • demonstrably reflect the developments that actually occurred.
• If any of these links are missing, the chances of failure are significantly raised, since it becomes very difficult for EA to deliver on its real mandate of delivering the value the business needs (rather than what it says it wants, or what the IT department interpret this to be).
• Lack of commitment: This can be caused by lack of funding, lack of senior sponsorship or both, and manifests itself through short term priority setting (and thus a lack of architectural rigour).
• Disguised EA: Many enterprises set up an organisation under the EA banner which ends up performing a different function. When this practice fails to deliver on what they thought EA promised, it often fails – without any real EA having been performed.
• Lack of attention to Materiality: Significant risk results from EA practices dealing at too high – or too low – a level of detail. Some believe their remit stops at the strategic level, and do not therefore become concerned with aspects of implementation which are vital for long term architectural consistency. Others, by contrast, embark on immense programs of analysis and synthesis resulting in many diagrams and models, but little of practical value to the enterprise.
• Lack of Sustainability: Many of the factors mentioned above contribute to poor sustainability in an EA practice. Sustainability will not be ensured, however, without significant consideration of EA as a capability (embodying a rigorous, cohesive approach to the use of people, processes, tools and knowledge).

Expanding on the last point, it is worth examining how a capability-focussed approach can lead to greater sustainability in an EA practice. As we have already discussed, a capability comprises five components (people, process, tools, culture and knowledge) working together to provide some value. In order to design an effective capability, we must consider each of these components individually and in combination.

Each component has relevance to the others, implying that the capability should be designed as a cohesive unit. If an EA capability is built without this cohesion in mind (i.e. the components are functionally isolated), or if undue emphasis is placed on one component at the expense of the others (in extreme cases if components are missing), then problems will inevitably arise. Many of the underlying causes of EA failure stem from these two issues:

• If the PEOPLE components are isolated, the practice will typically exhibit anarchic behaviour, characterised by reinvention of the wheel, wasted effort and lack of consistency;
• If the PEOPLE components are missing or badly addressed (i.e. the practice is poorly resourced), there is a strong likelihood that the resource will be spread too thinly and ultimately that architects will (through necessity) fall back on elements of the job within their comfort zone – effectively revert to being ‘project’ or ‘solution’ architects.
• Isolated design of the PROCESS components will lead to poorly understood roles and responsibilities, impractical approaches being mandated, and ultimately loss of credibility;
• Lack of attention to detailed PROCESS design (such as would be embodied in a Practice Operating Model) leads once again to ad hoc approaches being adopted, wasted effort, limited re-use of knowledge (through lack of a consistent approach), etc.
• If TOOLS are designed or adopted without consideration of who will use them (PEOPLE), how they will be used (PROCESS) and what will be captured (KNOWLEDGE) they will clearly not be fit for purpose.
• If TOOLS are inadequate or missing, there is a strong risk of failure due to poor productivity and lack of consistency. Complex, multi-faceted disciplines such as EA are unlikely to be sustained as purely manual activities.
• A practice which treats the collection of KNOWLEDGE as an isolated activity is likely to be viewed as being irrelevant and as an ‘Ivory Tower’ within the business.
• KNOWLEDGE which is incomplete will be unfit for purpose, and will lead to loss of trust and credibility caused by demonstrated lack of professionalism in the practice.

Cohesive EA Practice Design

The cohesion of these four elements is critical to avoiding functional isolation, designing a sound capability and significantly reducing the risk of failure. A cohesive approach to capability design implies that people, process, tools and knowledge are recognised as interconnected and interdependent in a well functioning practice. Specifically:

• People should be competent in following the process, using the tools and understanding the knowledge;
• The tools should help in executing the process and in gathering, controlling, using and sharing the knowledge;
• The process should explicitly define how the people interact, and how the knowledge is gathered, controlled, used and shared;
• The knowledge should underpin the execution of the process, and support the people in fulfilling their roles.

Figure 3: Mature EA Capability Landscape

In order to design capabilities in this way, a practice builder should have a clear and accurate idea of what the target state should be. This will allow them to construct a catalogue of capability components, and define a transition plan for gradual progress towards a mature EA practice. An example of this type of target state is shown in Figure 3, above.

There are three core components to this mature Enterprise Architecture capability:

• The means to perform effectively as an architect, when dealing with the rest of the enterprise (Architecture Engagement Operation). This involves executing prescribed processes and gathering/using defined knowledge to make architectural decisions;
• The definition of these standard operating practices, and the management of the organisation to perform them (Engagement Management);
• The toolset to ensure, consistency, accuracy, completeness and sharing of knowledge during the course of architectural engagement (Practice Support Environment).

In addition, further components are included:

• to ensure that the practice is built up effectively, that tools and people are made ready, and that the impacts of change are understood and accounted for (Practice Building) and
• to guide the practice direction and strategy longer term (Practice Direction and Strategy)

Defining the Path to Maturity

It is apparent that, for an EA practice to function well in the long term, many factors need to be actively considered from the start. The path to a mature practice involves keeping a balance between conflicting priorities within the enterprise, maintaining constant vigilance to ensure that the real value proposition of enterprise architecture is being addressed, and presenting a realistic picture of what can be achieved with the resources available.

Organisations often find it useful to map out a progression towards this target state, based on standard maturity assessment categories (such as are used in the TOGAF Architectural Capability Maturity Model):

1. None
2. Initial
3. Under development
4. Defined
5. Managed
6. Optimised

They should then consider the way in which various parts of their landscape will be deployed as they move through this sequence towards maturity, e.g.

• In the INITIAL state:
  • early awareness of the benefits of EA have been raised and accepted;
  • agreement to proceed with design work has been secured;
  • training plans for the architect community have been defined and agreed
• In the DEFINED state:
  • architects are trained and in place;
  • an initial operating model is in place, including defined roles and responsibilities;
  • a prototype practice support environment has been designed/procured and installed
• In the OPTIMISED state:
  • all aspects of the mature landscape are in place;
  • the current and future state architectures are well documented and place under ongoing governance;
  • horizon scanning for architectural opportunities and challenges is performed as routine;
  • all landscape elements are subject to active continuous improvement.

Conclusions

The reasons originally put forward to justify EA as a discipline are still as valid as ever. Strong EA organisations are built on the recognition that individuals certified in EA techniques are not enough for sustainable, value-adding practices.

A realistic target state for the practice should be established, based on the value that it will add to the rest of the organisation. Building towards this target state capability will require consideration of changes to organisations, processes, tools and techniques used, establishment of a sound cultural context, and effective use of technical knowledge. Failure to address any of these components, or the way they fit together, can be catastrophic.

Strong transition planning will be required, incorporating emphasis on change management, risk mitigation and benefit realisation.

Fundamentally, enterprise architecture is not for the hobbyist or the theoretician. It is successful when it is deeply integrated with (and held accountable to) the lines of business. Understanding and reacting to their ever-changing needs is fundamental to success. We must not forget that every aspect of the tools, skills and knowledge available to an EA practitioner is intended to serve this end.