Bekijk Paper.doc

Improving Business – IT AlignmentTowards an Enterprise Architecture Maturity Model

Raymond SlotCap Gemini Ernst & Young

[email protected]://www.nl.cgey.com

20 September 2000

Enterprise Architecture Maturity Model 20 September 2000

Contents

1. Abstract 3

2. Introduction 4

3. The Enterprise Architecture Maturity Model 52.1 Level 1: Initial – Enterprise Architecture historically grown..............................................62.2 Level 2: Starting – Initial use of architecture....................................................................62.3 Level 3: Extended – Whole organisation endorses architecture......................................82.4 Level 4: Matured – Architecture developed and maintained............................................92.5 Level 5: Routine – All systems are rebuild under architecture.........................................9

4. Architectural processes 113.1 Architecture development primary process....................................................................113.2 Architecture maintenance processes.............................................................................113.3 Architectural support processes.....................................................................................12

5. Relationship between EA phases and architectural processes 15

6. Quality indicators for the architecture development process 175.1 Quality indicators of the architecture development primary process..............................17

7. References 19

2

R.G. Slot Enterprise Architecture Maturity Model

1. Abstract

Aligning Business Strategy and IT priorities is a top-priority for many information technology executives. Corporations feel the need to change existing systems and simultaneously extend there IT infra-structure by adding new, web-based systems. In this process the question of IT effectiveness and efficiency is important and, hence-forth, the question of how to align business strategy to IT. We present in this paper a process oriented approach to improve the business-IT relationship, based on the progressive introduction of ar-chitecture methods within an organisation.

3


2. Introduction

Aligning Business Strategy and IT priorities is a top-priority for many information technology executives. Many organisations – especially in the financial sectors – struggle to keep their (legacy) IT environ-ment up to date with fast changing business rules and distribution channels. Corporations feel the need to change existing systems and simultaneously extend there IT infrastructure by adding new, web-based systems. Consequently, many corporations see the IT cost as percentage of total revenues rising fast. In this process the question of IT effectiveness and efficiency becomes important and, hence-forth, the question of how to align business strategy to IT. The devel-opment of Enterprise Architecture is an approach to this alignment problem. Maes and co-authors (2000) argue that a unified business IT architecture framework is a valid starting point in elaborating the concept of business-IT alignment. In their paper, they connect an ex-tended version of Henderson and Venkamatran´s (1993) alignment model with the Integrated Architecture Framework from Cap Gemini Ernst & Young (Goedvolk, 1999). They define alignment as “the con-tinuous process, involving management and design sub-processes, of consciously and coherently interrelating all components of the business-IT relationship in order to contribute to the organisation’s performance over time."

Starting from this definition, we present in this paper a process ori-ented approach to improve the business-IT relationship, based on the progressive introduction of architecture methods within a organ-isation.

4


3. The Enterprise Architecture Maturity Model

Every organisation has to translate and convert business strategy and requirements to IT-related decisions. This translation creates a structure, which connects business vision & strategy to IT strategy and successively to lower level implementation details. This struc-ture is called the Enterprise Architecture (EA). In other words, the EA is the total of business models, IT models and the translation of

these models to the physical world.

Most organisations do not create an EA. Their high-level structure that connects business and IT is historically grown as an ‘automatic’ result of many different IT programs. This results in a structure that is inflexible, non-transparent and difficult to maintain, creating busi-ness IT misalignment.

In contrast with this approach, some organisations do pay specific attention to the construction of an EA. The use of an EA allows organ-isations to create more synergy between business and IT, by using a common framework for the meaningful exchange of ideas and, con-sequently, a better mutual understanding. These organisations dis-cover that, to exploit this benefit, they must change the way they approach IT. An EA at itself does not provide benefits; only the intelli-

gent use of this model by the people in the organisation produces benefits.

5

Figure 1. Elements of enterprise architecture


The approach chosen by organisations how to create and apply an EA, characterises the architectural maturity level of the organisation. The phases that an organisation passes through when building and applying an EA, have many common characteristics, which we present here in terms of EA maturity levels. We have identified five enterprise architecture maturity levels:

1. Initial – Enterprise Architecture historically grown2. Starting – Initial use of architecture3. Extended – Whole organisation endorses architecture4. Matured – Architecture developed and maintained5. Routine – All systems are rebuild under architecture

We will describe these levels in more detail in the following para-graphs.

2.1 Level 1: Initial – Enterprise Architecture historically grown

The EA of many organisations is not a result of a conscious effort, but their EA has developed because of many different, often unrelated projects and has grown historically into a complex, non-transparent architecture with many interrelations. Such architecture is inflexible and difficult to maintain, resulting in high maintenance costs and an inability to follow the fast-changing business world. The absence of a coherent EA results in misalignment between business and IT results, at the enterprise level. Business and IT may be aligned within the scope of projects, but optimisations within projects leads to sub op-timisations across projects.

The challenge in this phase is to find a sponsor for starting an archi-tecture development program. Starting from scratch with architec-ture within projects will increase the perceived time and cost for pro-jects and, therefore, will often be seen as ‘unpractical’ or ‘useless’.

2.2 Level 2: Starting – Initial use of architecture

The need for more structure is felt mostly at the operational IT level. Growing complexity results in inflexibility and this forces imple-menters of systems to rethink their usual strategy of considering ar-chitecture only at a project level. Architects at the organisation feel the need for a structured approach to these problems and start to look at architectural methods, such as the Integrated Architecture Framework of Cap Gemini Ernst & Young. Training and education of new architects becomes important, to create a common frame of un-derstanding for architects.

6


In this phase, architecture projects are executed within the scope of existing change programs and projects. Architecture is in this phase largely an IT only exercise, although a limited number of business people may be involved. The program and project level architectures start to take broader view in account than only their own projects.

Activities, which fall outside the direct scope of the architecture de-velopment process, such as architecture maintenance and repositor-ies, have in this phase a low priority. The main effort is directed in defining architectures and to convince senior management and busi-ness staff that it is fruitful to put effort in developing them.

Advantages of the use of architecture in this phase are in the areas of projects helping each other with shared resources. Projects that can reuse shared resources will have lower cost and a shorter devel-opment time. This will not yet have effects on the IT spending at or-ganisational level.

Organisations face a number of required changes and challenges in this phase. An overview:

To improve the definition and the focus the architecture projects

Starting of the architecture repository process

Inclusion of patters and “best practices” in the architecture process

Inclusion of purchased components into the architecture

Learning and developing skills and the realisation of the importance of skills in developing architectures

Architect people management

Multidisciplinary, effective cooperation between people from differ-ent background

How to fit the legacy environment and standard packages with the projects that have been done under architecture

Behind these procedures and solution-oriented changes, a major cul-tural and mindset change is needed. From a detailed, fragmented look for developing IT, to a more comprehensive, holistic approach. People must learn to not only look at their direct needs within the boundaries of their project or organisational unit, but also need to understand what they can add to the whole.

7


2.3 Level 3: Extended – Whole organisation endorses architecture

Because of the successes of early projects, business staff and senior management become convinced of the advantages of using an ar-chitectural approach. Architecture training includes now business ar-chitects and they claim the ownership of the business architectures within the organisation. The need for senior architects, able to over-see business and IT increases. Senior management makes it obligat-ory to include architectural efforts in any significant development effort. Business and IT work together to create architectures for spe-cific organisational domains and a organisation-wide EA is developed. By now, the sceptics are convinced and the organisation under-stands that architecture is an essential role within IT. The fit with the legacy environment has been ironed out and rules and guidelines are available how to interface with the “old” environment. For new standard packages, one of the selection criteria is the fit to the EA.

The advantages in this phase are many. Many reusable resources are built and projects can re-use them. As a consequence, time-to-market will decrease for new projects which are build under archi-tecture. Business and IT cooperation is much more smooth as people are gaining experience and know better what is expected of them. Project costs will go down and operational cost will stop increasing.

The challenges in this phase are:

How to keep the focus within the architecture projects

Organisational learning and feedback from the projects that have been done

How to run routinely an architecture repository environment and the re-use of architectural patterns, business patterns and technical pat-terns

Including architecture career path within the existing HRM policy

How to handle architecture legacy

How to assess and measure the quality of the architectures

Develop training programs for senior architects

Purchasing of components at an enterprise level

A cultural issue is how to handle the “loss of freedom” that will be experienced by business analysts, information analysts, project managers and builders in projects. The architecture will impose rules and give guidelines, which will prevent designers and developers from “re-inventing the wheel” and from creating designs that do not

8


fit well in the architecture. Of course, exceptions will exist and the organisation will have to balance business needs with architectural needs.

2.4 Level 4: Matured – Architecture developed and maintained

In this phase the architecture process is well defined and used throughout the organisation. The EA is firmly in place and architec-ture maintenance is an important activity. Re-use of patterns is standard practice and the efforts for new projects will greatly be re-duced to that part which adds new business functionality. The legacy environment will be wrapped en being rebuild. The architectural de-velopment efforts are aimed at improving the correlations between domain architectures and the EA. Furthermore, the organisation will have to re-architect earlier architectures and will start to replace part of the existing (pre-architecture) infrastructure with architec-ture-based systems. Purchasing of component frameworks will be routine.

The main advantages in this phase is that the overall IT cost will de-cline, that the IT will not be in the critical path for new developments anymore and that, consequently, organisations will be more flexible and agile, although – simultaneously – the dependency on IT may still be increasing.

The challenges in this phase are:

How to prevent architecture legacy

How to run effectively and efficiently the architectural administrat-ive housekeeping, without stifling new projects and the change man-agement process in bureaucracy

How to comply to international architectural standards

Focus on the re-design of early architectures

How to increase the efficiency of the architecture projects

How to set up quantitative architecture process management

Furthermore, IT architecture styles will develop and the elegance of the solutions will become subject of consideration.

2.5 Level 5: Routine – All systems are rebuild under architecture

This phase will take place when a organisation succeeds in (re)build-ing their complete IT environment under architecture. This will mean that architecture is routine, it is “business a usual”. The architectural processes are firmly in place and rebuilding the legacy environments

9


will have needed comprehensive efforts. At this point, IT will not be an issue anymore; the technical angle of IT will disappear, because it is structured in procedures in standard business, architectural and technical building blocks.

Advantage is that IT costs will much lower than today and that IT as such will be a non-issue.

The challenge is not in the architecture or in IT anymore.

10


4. Architectural processes

The enterprise architecture maturity model phases delineate a growth model for IT architecture. Every phase is supported by sev-eral architectural processes. These processes describe the activities that need to be carried out during the phase, but also characterise the phase. For example, the activities of phase two will be quite dif-ferent from those in phase four. Therefore, creating an EA implies the creation and the use of architectural processes. We can identify three types of architecture-related processes:

1. The architecture development primary process2. Architecture maintenance processes3. Architectural support processes

3.1 Architecture development primary process

The architecture development primary process describes how archi-tectures are developed within the organisation. Architecture devel-opment is a complex process and a description thereof falls outside the scope of this paper. See Goedvolk (1999) for a description of the architecture development process IAF1 that is used by Cap Gemini Ernst & Young. The choice for a particular architecture development approach is irrelevant for the application of the EAMM. However, this paper gives a list with quality indicators for this process. See Chapter 6 (page 17) for an overview of these quality indicators.

The quality and the use of the primary architecture development process is one of the discriminators, in determining the EA maturity of an organisation.

3.2 Architecture maintenance processes

Architecture maintenance maintains the architectural designs that have been produces by multiple architecture projects. This includes high-level enterprise architecture designs, intermediate level do-main-architecture designs and low-level, project-related designs.

Architecture maintenance encompasses the archiving of these designs and the appliance of small changes to these designs. Large changes to an architecture design will be the subject of a separate project, of course, but small, non-essential changes in the design will

1 Integrated Architecture Framework

11


be handled by architecture maintenance. Therefore, two mainten-ance processes are identified:

Architecture design archival and retrievalThis process archives the resulting designs of architecture pro-jects and provides search and retrieve mechanisms to find back the results.

Architecture design change managementIf architecture or implementation projects change non-essential details in existing architectures, the change management pro-cess updates the archived architecture designs, so they keep re-flecting the actual situation.

3.3 Architectural support processes

Besides the architectural development and maintenance processes, organisations need to create several type of support processes. These have to do with:

(1) Improving the quality of architecture designs(2) Process improvements for the architecture development process(3) Processes that address organisational and HRM aspects

We make a clear distinction between the architecture design, which is the result of an architecture process. Support processes of the first category aim to improve the architectural design (of a particular architecture project), while support processes of the second cat-egory aim to improve the architecture development process.

(1) Support processes to improve the quality of the architecture designs

An overview of the processes needed to support the primary archi-tecture development process, by improving the quality of the archi-tectural design.

Architecture project management & planningIn principle, standard project management techniques are ap-plied here. The first phase of architectural projects, tend to have less predictable lead times, because of the high levels of inter-activity and interdependency with the organisation. Architec-tural planning methods should these effects take into account.

AS-IS Configuration managementArchitects need to have a high-quality, high-level overview of the existing situation.

Multidisciplinary, intergroup coordinationMulti-disciplinary cooperation and coordination is required within architecture projects. An organisation needs to have standard approaches to facilitate this cooperation.

12


Peer ReviewPeer review and the ability to have fast, efficient exchange of ideas and solutions between (senior) architects is essential for the quality of an architectural design.

Architecture repository managementAn architecture team needs to have fast access to previous ar-chitecture solutions.

Pattern recognition and reuseInclusion of patterns in the architecture design, improves the speed and quality of the solution.

(2) Support processes that improve the architecture development process

A number of support processes address the improvement of the ar-chitecture development process. An overview of these processes:

Architecture process change managementChanges and experiences from architects need to be incorpor-ated into the primary process.

Architecture project tracking and reportingTracking and reporting of the results of architecture projects. This process should track common indicators like cost, results, lead times and main-hour consumption. Detected trends in these results can be used to improve the primary process.

Architecture results quality managementDevelopment and use of a standard measuring method, to judge the quality of architectural designs and decisions.

Adherence to international standardsCurrently standardisation of architecture processes is still in its infancy. See IEEE 14712, attempting to bring more clarity in the definition of architecture.

(3) Support processes that address the organisational and HRM aspects

An overview of the processes needed to imbed architectural activit-ies in a organisation.

Architecture people managementOrganisations need to define career paths for architects. It must be attractive for people to act as an architect.

Feedback and organisational learningWithin architecture projects, people learn a lot about the pro-cess, about feasible architecture solutions and about the mind-set of doing architecture. Relevant experiences should not only

2 Recommended Practice for Architectural Description

13


be confined to the involved architects, but should also be used by policy makers, general management and IT management.

Architecture education, mentoring & coachingOrganisations need a strong architecture learning-program. This learning program needs to include: training for to-be architects, mentoring of junior architects by seniors and ‘on the job’ coach-ing.

14


5. Relationship between EA phases and architectural processes

The processes as they are defined in the previous chapter, link to the EA phases described in chapter 3. Figure 2 gives a concise over-view of the relationship between EA phases and the corresponding processes. The presence and/or the maturity of architectural pro-cesses within the organisation, indicate the EA maturity phase of an organisation.

For a more detailed overview of the relationship between processes and phases, see table 1, on the next page.

15

Figure 2. Overview enterprise architecture phases & processes

Architectural processes are undefined

Primary Process• Architecture

development

Support processes• Architecture project management• Multi-disciplinary, intergroup

coordination• Peer review

Support processes• Architecture project tracking and reporting• Architecture design quality management

Support processes• Architecture process feedback quantitative management• Adherence to international standards

Maintenance Processes• Architecture design archival and retrieval• Architecture design Change management

Support processes• Architecture repository management• Architecture people management• Architects education, mentoring &

coaching

Support processes• AS-IS Configuration management• Architecture repository management• Pattern recognition and reuse• Architecture people management• Feedback and organisational learning• Architecture development process change management

1. 1. InitialInitial

2. 2. StartingStarting

4. 4. Mature Mature

5. 5. Routine Routine

3. 3. ExtendedExtended

Architectural processes are undefined

Primary Process• Architecture

development

Support processes• Architecture project management• Multi-disciplinary, intergroup

coordination• Peer review

Support processes• Architecture project tracking and reporting• Architecture design quality management

Support processes• Architecture process feedback quantitative management• Adherence to international standards

Maintenance Processes• Architecture design archival and retrieval• Architecture design Change management

Support processes• Architecture repository management• Architecture people management• Architects education, mentoring &

coaching

Support processes• AS-IS Configuration management• Architecture repository management• Pattern recognition and reuse• Architecture people management• Feedback and organisational learning• Architecture development process change management

1. 1. InitialInitial1. 1. InitialInitial

2. 2. StartingStarting2. 2. StartingStarting

4. 4. Mature Mature 4. 4. Mature Mature

5. 5. Routine Routine 5. 5. Routine Routine

3. 3. ExtendedExtended3. 3. ExtendedExtended


16

Agenda

This process is routine and well understood. This process may still change as a result of planned process feedback.

This process is refined and feeddback from earlier experiences will change the process

This process is developed in this phase

The status of this process is inderterminate by the model. The company may have already done some work in this area.

1 2 3 4 5 Architecture development primary process

Support processeso Architecture quality & efficiency aspects

Architecture project management & planning AS-IS Configuration management Multidisciplinary, intergroup coordination Peer Review Architecture Repository management Pattern recognition and reuse

o Architect organisational HRM aspects Architecture people management Feedback and organisational learning Architecture education, mentoring & coaching

o Architecture process quality & efficiency aspects Architecture project tracking and reporting Architecture process change management Architecture results quality management Adherence to international standards

Maintenance processes Architecture design archival and retrieval Architecture design change management

PhaseCorrelation between EAMM Phase and architectural processes

Process

Table 1. Detailed relationship between architectural processes and Enterprise Architecture phases


6. Quality indicators for the architecture development process

As described in the paragraph “The architecture development primary process” (page 11), this appendix contains a list with quality indicators for the architecture development process. The indicators are in the form of questions. The more questions can be answered affirmatively, the better the quality of the architecture process. The content of this list is created from a list with “best practices”, based on the experience of Cap Gemini Ernst & Young´s architects.

5.1 Quality indicators of the architecture development primary process

General questions

Does the organisation have one uniformly used, enterprise architec-ture development method?

Does the organisation have a project management approach for ar-chitecture projects?

Does the method support a review process? Does the method support a selection, decision and escalation pro-

cess? Facilitates the method multidisciplinary, intergroup cooperation? Does the method support the inclusion of patterns, on the business,

architectural and technical level? Does the method support quality reviews and other quality improv-

ing mechanisms? Does the method clearly assign responsibilities among the parties

involved? Does the method make a distinction between architectural elements

and influencing factors? Is de process model clearly defined? Does the method make a clear distinction between process and de-

liverables? Does the method support clear scoping of the architecture project? Does the method support inclusion of both ‘ideal’ long-term and

realisable short-term goals? Is the method supported by adequate tooling? Does the method encourage the use of large pictures? Does the method support the creation of explicit assumptions? Does the method acknowledge the role of teamwork in defining an

architecture?

Requirements management

Are the business mission & objectives of clearly defined? Does the method support requirements analysis? Does the method support requirements modelling? Does the method support stakeholder analysis?

17


Does the method support AS-IS information gathering? Does the method documents rationales and sources?

Ideal solution modelling

Does the method support the modelling of alternative logical solu-tions?

Does the method support the integration of multiple viewpoints?

Physical modelling

Does the method support the modelling of alternative physical solu-tions?

Does the method support migration planning? Does the method support solution optimisation?

18


7. References

Henderson, J.C. and Venkatraman, N., “Strategic Alignment: Lever-aging Information Technology for Transforming Organisations,” IBM Systems Journal vol.32, nr1, 1993.

Maes, R., Rijsenbrij, D., Truijens, O., Goedvolk, J.G., “Redefining busi-ness – IT alignment through a unified framework”. Downloadable from http://www.cs.vu.nl/~daan/arch/publ.htm, 2000.

Goedvolk, J.G., “White paper Integrated Architecture Framework”, Downloadable from http://www.cs.vu.nl/~daan/arch/publ.htm, 1999.

19

http://www.cs.vu.nl/~daan/arch/publ.htm

http://www.cs.vu.nl/~daan/arch/publ.htm

Bekijk Paper.doc

Documents

information

integrated

align business

aligning business

matured architecture

architecture

change existing

process oriented