Bekijk Paper.doc


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Bekijk Paper.doc

  1. 1. Improving Business – IT Alignment Towards an Enterprise Architecture Maturity Model Raymond Slot Cap Gemini Ernst & Young
  2. 2. Enterprise Architecture Maturity Model 20 September 2000 20 September 2000 Contents 1. Abstract 3 2. Introduction 4 3. The Enterprise Architecture Maturity Model 5 2.1 Level 1: Initial – Enterprise Architecture historically grown..............................................6 2.2 Level 2: Starting – Initial use of architecture....................................................................6 2.3 Level 3: Extended – Whole organisation endorses architecture......................................8 2.4 Level 4: Matured – Architecture developed and maintained............................................9 2.5 Level 5: Routine – All systems are rebuild under architecture.......................................10 4. Architectural processes 11 3.1 Architecture development primary process....................................................................11 3.2 Architecture maintenance processes.............................................................................11 3.3 Architectural support processes.....................................................................................12 5. Relationship between ea phases and architectural processes 15 6. Quality indicators for the architecture development process 17 5.1 Quality indicators of the architecture development primary process..............................17 7. References 19 2
  3. 3. R.G. Slot Enterprise Architecture Maturity Model 1. Abstract Aligning Business Strategy and IT priorities is a top­priority for many in­ formation technology executives. Corporations feel the need to change ex­ isting systems and simultaneously extend there IT infrastructure by adding  new, web­based systems. In this process the question of IT effectiveness  and efficiency is important and, henceforth, the question of how to align  business strategy to IT. We present in this paper a process oriented ap­ proach to improve the business­IT relationship, based on the progressive in­ troduction of architecture methods within an organisation. 3
  4. 4. Enterprise Architecture Maturity Model 20 September 2000 2. Introduction Aligning Business Strategy and IT priorities is a top­priority for many in­ formation technology executives. Many organisations – especially in the  financial sectors – struggle to keep their (legacy) IT environment 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 import­ ant and, henceforth, the question of how to align business strategy to IT.  The development of Enterprise Architecture is an approach to this align­ ment 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 extended version  of Henderson and Venkamatran´s (1993) alignment model with the Integ­ rated Architecture Framework from Cap Gemini Ernst & Young (Goed­ volk, 1999). They define alignment as “the continuous process, involving   management and design sub­processes, of consciously and coherently inter­ relating all components of the business­IT relationship in order to contrib­ ute to the organisation’s performance over time." Starting from this definition, we present in this paper a process oriented  approach to improve the business­IT relationship, based on the progressive  introduction of architecture methods within a organisation. 4
  5. 5. R.G. Slot Enterprise Architecture Maturity Model 3. The Enterprise Architecture Maturity Model Every organisation has to translate and convert business strategy and re­ quirements 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 structure 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.  Figure 1. Elements of enterprise architecture Most organisations do not create an EA. Their high­level structure that con­ nects 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 business IT misalignment. In contrast with this approach, some organisations do pay specific atten­ tion to the construction of an EA. The use of an EA allows organisations to  create more synergy between business and IT, by using a common frame­ work for the meaningful exchange of ideas and, consequently, a better mu­ tual understanding. These organisations discover that, to exploit this bene­ fit, they must change the way they approach IT.  An EA at itself does not  provide benefits; only the intelligent use of this model by the people in the  organisation produces benefits.  5
  6. 6. Enterprise Architecture Maturity Model 20 September 2000 The approach chosen by organisations how to create and apply an EA, char­ acterises 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 grown 2. Starting – Initial use of architecture 3. Extended – Whole organisation endorses architecture 4. Matured – Architecture developed and maintained 5. Routine – All systems are rebuild under architecture We will describe these levels in more detail in the following paragraphs. 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 main­ tain, resulting in high maintenance costs and an inability to follow the  fast­changing business world. The absence of a coherent EA results in mis­ alignment between business and IT results, at the enterprise level. Busi­ ness and IT may be aligned within the scope of projects, but optimisations  within projects leads to sub optimisations across projects. The challenge in this phase is to find a sponsor for starting an architecture  development program. Starting from scratch with architecture within pro­ jects will increase the perceived time and cost for projects 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. Grow­ ing complexity results in inflexibility and this forces implementers of sys­ tems to rethink their usual strategy of considering architecture 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 &  6
  7. 7. R.G. Slot Enterprise Architecture Maturity Model Young. Training and education of new architects becomes important, to  create a common frame of understanding for architects.  In this phase, architecture projects are executed within the scope of exist­ ing change programs and projects. Architecture is in this phase largely an  IT only exercise, although a limited number of business people may be in­ volved. 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 develop­ ment process, such as architecture maintenance and repositories, have in  this phase a low priority. The main effort is directed in defining architec­ tures and to convince senior management and business 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 pro­ jects helping each other with shared resources. Projects that can reuse  shared resources will have lower cost and a shorter development time.  This will not yet have effects on the IT spending at organisational 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 different back­ ground • 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 cultural  and mindset change is needed. From a detailed, fragmented look for devel­ oping 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  7
  8. 8. Enterprise Architecture Maturity Model 20 September 2000 organisational unit, but also need to understand what they can add to the  whole.  2.3 Level 3: Extended – Whole organisation endorses architecture Because of the successes of early projects, business staff and senior man­ agement become convinced of the advantages of using an architectural ap­ proach. Architecture training includes now business architects and they  claim the ownership of the business architectures within the organisation.  The need for senior architects, able to oversee business and IT increases.  Senior management makes it obligatory to include architectural efforts in  any significant development effort. Business and IT work together to create  architectures for specific organisational domains and a organisation­wide  EA is developed. By now, the sceptics are convinced and the organisation  understands 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 de­ crease for new projects which are build under architecture. 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 oper­ ational 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 patterns • 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 8
  9. 9. R.G. Slot Enterprise Architecture Maturity Model A cultural issue is how to handle the “loss of freedom” that will be experi­ enced 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 fit well in the architecture. Of  course, exceptions will exist and the organisation will have to balance busi­ ness 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 architecture maintenance is  an important activity. Re­use of patterns is standard practice and the ef­ forts for new projects will greatly be reduced to that part which adds new  business functionality. The legacy environment will be wrapped en being  rebuild. The architectural development 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 decline,  that the IT will not be in the critical path for new developments anymore  and that, consequently, organisations will be more flexible and agile, al­ though – 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   administrative   housekeeping,  without stifling  new projects  and the change management   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.  9
  10. 10. Enterprise Architecture Maturity Model 20 September 2000 2.5 Level 5: Routine – All systems are rebuild under architecture This phase will take place when a organisation succeeds in (re)building  their complete IT environment under architecture. This will mean that ar­ chitecture is routine, it is “business a usual”. The architectural processes  are firmly in place and rebuilding the legacy environments will have  needed comprehensive efforts. At this point, IT will not be an issue any­ more; 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
  11. 11. R.G. Slot Enterprise Architecture Maturity Model 4. Architectural processes The enterprise architecture maturity model phases delineate a growth  model for IT architecture. Every phase is supported by several 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 different 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 process 2. Architecture maintenance processes 3. Architectural support processes 3.1 Architecture development primary process The architecture development primary process describes how architectures  are developed within the organisation. Architecture development is a com­ plex process and a description thereof falls outside the scope of this paper.  See Goedvolk (1999) for a description of the architecture development pro­ cess IAF1 that is used by Cap Gemini Ernst & Young. The choice for a par­ ticular 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 indicat­ ors.  The quality and the use of the primary architecture development process is  one of the discriminators, in determining the EA maturity of an organisa­ tion.  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 domain­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 archi­ tecture design will be the subject of a separate project, of course, but small,  1  Integrated Architecture Framework 11
  12. 12. Enterprise Architecture Maturity Model 20 September 2000 non­essential changes in the design will be handled by architecture main­ tenance. Therefore, two maintenance processes are identified: • Architecture design archival and retrieval This   process   archives   the   resulting   designs   of   architecture   projects  and provides search and retrieve mechanisms to find back the results. • Architecture design change management If   architecture   or   implementation  projects   change   non­essential   de­ tails  in  existing   architectures,   the  change  management   process   up­ dates the archived architecture designs, so they keep reflecting the ac­ tual situation. 3.3 Architectural support processes Besides the architectural development and maintenance processes, organ­ isations 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 pro­ ject), while support processes of the second category aim to improve the ar­ chitecture development process.  (1) Support processes to improve the quality of the architecture designs An overview of the processes needed to support the primary architecture  development process, by improving the quality of the architectural design.  • Architecture project management & planning In   principle,   standard   project   management   techniques   are   applied  here. The first phase of architectural projects, tend to have less pre­ dictable lead times, because of the high levels of interactivity and in­ terdependency with the organisation. Architectural planning methods  should these effects take into account. • AS­IS Configuration management Architects need to have a high­quality, high­level overview of the ex­ isting situation. • Multidisciplinary, intergroup coordination 12
  13. 13. R.G. Slot Enterprise Architecture Maturity Model Multi­disciplinary cooperation and coordination is required within ar­ chitecture   projects.   An   organisation   needs   to   have   standard   ap­ proaches to facilitate this cooperation.  • Peer Review Peer 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 management An architecture team needs to have fast access to previous architec­ ture solutions. • Pattern recognition and reuse Inclusion 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 architec­ ture development process. An overview of these processes: • Architecture process change management Changes and experiences from architects need to be incorporated into  the primary process. • Architecture project tracking and reporting Tracking   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 management Development and use of a standard measuring method, to judge the  quality of architectural designs and decisions. • Adherence to international standards Currently standardisation of architecture processes is still in its in­ fancy. See  IEEE  14712, attempting to bring more clarity in the defini­ tion of architecture. (3) Support processes that address the organisational and HRM aspects An overview of the processes needed to imbed architectural activities in a  organisation.  • Architecture people management 2  Recommended Practice for Architectural Description 13
  14. 14. Enterprise Architecture Maturity Model 20 September 2000 Organisations need to define career paths for architects. It must be at­ tractive for people to act as an architect. • Feedback and organisational learning Within   architecture   projects,   people   learn   a   lot   about   the   process,  about feasible architecture solutions and about the mind­set of doing  architecture. Relevant experiences should not only be confined to the  involved architects, but should also be used by policy makers, general  management and IT management.  • Architecture education, mentoring & coaching Organisations   need   a   strong   architecture   learning­program.   This  learning program needs to include: training for to­be architects, ment­ oring of junior architects by seniors and ‘on the job’ coaching. 14
  15. 15. R.G. Slot Enterprise Architecture Maturity Model 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 overview of the re­ lationship between EA phases and the corresponding processes. The pres­ ence and/or the maturity of architectural processes within the organisa­ tion, indicate the EA maturity phase of an organisation. Support processes • Architecture process feedback quantitative management 5. Routine • Adherence to international standards Support processes • Architecture project tracking and reporting • Architecture design quality management 4. Mature Support processes • AS-IS Configuration management • Architecture repository management • Pattern recognition and reuse Maintenance Processes • Architecture people management 3. Extended • Architecture design archival and retrieval • Feedback and organisational learning • Architecture design Change management • Architecture development process change management Primary Process Support processes Support processes • Architecture • Architecture project management • Architecture repository management development 2. Starting • Multi-disciplinary, intergroup coordination • Architecture people management • Architects education, mentoring & • Peer review coaching 1. Initial Architectural processes are undefined Figure 2. Overview enterprise architecture phases & processes For a more detailed overview of the relationship between processes and  phases, see table 1, on the next page. 15
  16. 16. Enterprise Architecture Maturity Model 20 September 2000 Correlation between EAMM Phase and architectural processes Phase Process 1 2 3 4 5 •        Architecture development primary process      •        Support processes o       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      Table 1. Detailed relationship between architectural processes and Enterprise Architecture phases Agenda  The status of this process isdone some workby the model. The company may have already inderterminate in this area.  This process is developed in this phase  This process is refined and feeddback from earlier experiences will change the process This process is routine and well understood. This process may still  change as a result of planned process feedback. 16
  17. 17. R.G. Slot Enterprise Architecture Maturity Model 6. Quality indicators for the architecture development process As described in the paragraph “The architecture development primary pro­ cess” (page 11), this appendix contains a list with quality indicators for the  architecture development process. The indicators are in the form of ques­ tions. 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 architecture de­ velopment method? • Does the organisation have a project management approach for architec­ ture projects? • Does the method support a review process? • Does the method support a selection, decision and escalation process? • Facilitates the method multidisciplinary, intergroup cooperation? • Does the method support the inclusion of patterns, on the business, archi­ tectural and technical level? • Does   the   method   support   quality   reviews   and   other   quality   improving   mechanisms? • Does the method clearly assign responsibilities among the parties involved? • Does the method make a distinction between architectural elements and in­ fluencing factors? • Is de process model clearly defined? • Does   the   method   make   a   clear   distinction   between   process   and   deliverables? • 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 architec­ ture? Requirements management • Are the business mission & objectives of clearly defined? 17
  18. 18. Enterprise Architecture Maturity Model 20 September 2000 • Does the method support requirements analysis? • Does the method support requirements modelling? • Does the method support stakeholder analysis? • 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 solutions? • Does the method support the integration of multiple viewpoints? Physical modelling • Does the method support the modelling of alternative physical solutions? • Does the method support migration planning? • Does the method support solution optimisation? 18
  19. 19. R.G. Slot Enterprise Architecture Maturity Model 7. References Henderson, J.C. and Venkatraman, N., “Strategic Alignment: Leveraging  Information Technology for Transforming Organisations,” IBM Systems   Journal vol.32, nr1, 1993. Maes, R., Rijsenbrij, D., Truijens, O., Goedvolk, J.G., “Redefining business   – IT alignment through a unified framework”. Downloadable from http://, 2000. Goedvolk, J.G., “White paper Integrated Architecture Framework”, Down­ loadable from, 1999. 19