A Maturity Model based Roadmap for Implementing TOGAF

Transcription

1 A Maturity Model based Roadmap for Implementing TOGAF R.W. Gosselt University of Twente Deldenerstraat 37-I, 7551AB Hengelo The Netherlands ABSTRACT Almost two third of the enterprise projects result in failure. The fact that the supporting architecture frameworks are overly complex is one of the main reasons for this. In this paper we try to reduce the initial complexity of adopting The Open Group Architecture Framework (TOGAF), the de facto standard, by prioritizing and tailoring its implementation based on insights from architecture maturity models. This should make the initial dive into the world of enterprise architecture and TOGAF specifically less daunting. Keywords Enterprise Architecture, Maturity models, Maturity assessment, TOGAF, Architecture Development Method, NASCIO. 1. INTRODUCTION One of the challenges facing enterprises today is how to cope with the rapid changes in the business environment and IT technology [25]. As an enterprise grows in size and complexity, several factors impede its abilities to solve the problems it faces. The point is rapidly reached where the factors that come into play in structuring and conducting the business of the enterprise become too numerous and complex to manage [9]. As information systems and technologies grow in complexity and scope, the need for a coherent and comprehensive modeling approach becomes of paramount importance [13]. In the last decades the subject of Enterprise Architecture has raised a lot of interest [7]. It helps control complexity, create cohesion and provides a future proof solution.[27] The top benefits reported are improved systems integration, improved IT governance, higher chance the development team follows common technology, improved business efficiency and increased data integrity [5]. The growing interest in enterprise architecture has led to the development of many frameworks to support the creation of enterprise architecture. The Open Group Architecture Framework ( TOGAF)[29] is such a framework and it has become the de facto standard for development and deployment of enterprise architecture[2]. According to Shaw [24], more than 66% of enterprise architecture initiatives fail. This was a conservative estimate he derived from a Rotterdam University survey done in Before this survey, in 2007 the Gartner Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. 17 th Twente Student Conference on IT, June 25 th, 2012, Enschede, The Netherlands. Copyright 2012, University of Twente, Faculty of Electrical Engineering, Mathematics and Computer Science. group had predicted that 40% of all the EA programs would terminate by 2010 because of failures. Although exact data for TOGAF projects is not available it is reasonable to assume that TOGAF projects cope with comparable failure rate. There is a plethora of reasons why these projects fail. The Open Group recognizes a lack of experience, lack of understanding of the artifacts and excessive time pressure as one of the main reasons [32]. According to Gartner [4], a wrong architecture leader, insufficient stakeholder understanding & support, too much focus on IT, the EA team doing all the work, lack of integration between the business units, lack of impact measurement and lack of communication are the key reasons. According to Sunderan most architecture projects are overly ambitious and complex [28] which leads to delayed results and running out of budget. This is confirmed by Sessions [23], who reports that the main characteristic shared by each of the Enterprise Architecture Frameworks is complexity. All of the frameworks are highly complex. Murch [15] states, to let IT infrastructures and architectures become increasingly complex with no action is unacceptable and irresponsible. If we simply throw more skilled programmers and others at this problem, chaos will be the order of the day. Until IT vendors and users alike solve the problem of complexity, the same problems will be repeated and will continue to plague the industry. It is easy to see that complexity is a big issue in TOGAF implementations. TOGAF is a heavy methodology that requires quite some architecture skills and sophistication. One could say that a complete implementation of the TOGAF method is only possible for organizations which have the highest EA maturity level. Less mature organizations don t have the infrastructure to fully implement TOGAF. For organizations new to the enterprise architecture practice adopting TOGAF could be a daunting task. This paper uses the six levels of architecture maturity proposed by NASCIO to prioritize and tailor the adoption of TOGAF as the organizations maturity progresses. To do this we first create a good understanding of enterprise architecture and its role in the organization. This is described in section 2.1. In section 2.2we analyze the TOGAF method and provide an overview of its key elements. Section 2.3 contains a description of maturity models and an overview of the relevant elements of NASCIO for our research. In section 3 the results of our mapping of TOGAF elements to the NASCIO stages are described. An overview of these results is presented in the table in appendix B. On the left hand side are the TOGAF elements, on the right the maturity stage at which they should be introduced within the architecture program. On the right-hand-side we also mapped each TOGAF element to the NASCIO category which provides a description in relation to the TOGAF element.

2 2. RELATED WORK 2.1 Enterprise Architecture Enterprise architecture (EA) has the purpose to optimize, across the enterprise, the often fragmented legacy of processes (both manual and automated) into an integrated environment, that is responsive to change and supports the achievement of the business strategy[29]. EA can be used by organizations to perform strategic planning and develop blueprints of their future-state. EA is also used as a management tool to ensure planning and activities are aligned with the strategic goals of the organization, and to identify opportunities for collaboration and reuse of resources across an organization[25]. An architecture may be viewed as a set of rules, guidelines and patterns for describing the architecture of systems.[18] The ISO standard [8] describes architecture as the fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution. The Open Group [29] defines enterprise as any collection of organizations that has a common set of goals. For example, an enterprise could be a government agency, a whole corporation, a division of a corporation, a single department, or a chain of geographically distant organizations linked together by common ownership. The term enterprise in the context of enterprise architecture can be used to denote both an entire enterprise encompassing all of its information and technology services, processes, and infrastructure and a specific domain within the enterprise. In both cases, the architecture crosses multiple systems, and multiple functional groups within the enterprise. Most enterprise architecture frameworks (EAFs) provide a definition of enterprise architecture. These definitions share commonalities that EA is about a set of models including their components and how these components integrate and work together to achieve a specific goal [14]. It is important to understand that Enterprise Architecture is not limited to IT, but is a company wide effort [21]. According to Lankhorst et al.[12] enterprise architecture (i) offers a holistic perspective of the current and future operations, and on the actions that should be taken to achieve the company s goals. It is (ii) an important asset in positioning new developments within the context of the existing processes, IT systems, and other assets of an organization, and it helps in identifying necessary changes. Thus, good architectural practice helps a company innovate and change by providing both stability and flexibility. The insights provided by an enterprise architecture are needed on the one hand in determining the needs and priorities for change from a business perspective, and on the other hand in assessing how the company may benefit from technological innovations. And EA is a (iii) valuable asset in the complex and diverse world of business-it alignment. The business-it alignment is based on a well-known strategic alignment model of Henderson and Venkatraman[6] which distinguishes between the aspects of business strategy and organizational infrastructure on the one hand, and IT strategy and IT infrastructure on the other hand. Lankhorst et al. [12] positioned enterprise architecture within the context of the enterprise. This is visualized in the form of a pyramid show in Figure 1. At the top of this pyramid, we see the mission of the enterprise: why does it exist? The vision states its image of the future and the values the enterprise holds. Next there is its strategy, which states the route the enterprise will take in achieving this mission and vision. This is translated into concrete goals that give direction and provide the milestones in executing the strategy. Translating those goals into concrete changes to the daily operations of the company is where enterprise architecture comes into play. It offers a holistic perspective of the current and future operations, and on the actions that should be taken to achieve the company s goals. Figure 1. Enterprise architecture positioned within the organizations context (Lankhorst et. al.) Architecture has three value creating potentials: innovativeness, responsiveness and economies of scale [11]. Organizations with highly capable infrastructure will have greater tendency to innovate with information technology. Higher levels of IT infrastructure capabilities will be more responsive at adapting their information systems to accommodate changing business conditions. The development cost and time of business application systems will generally be lower for firms with more capable IT infrastructures. 2.2 Enterprise architecture frameworks With the growing use of EA, architects have an increasing need for instruments to manage, to define, realize and communicate demands on the architecture [10]. An enterprise architecture framework (EAF) provides such an instrument. Enterprise architecture frameworks are commonly used to develop a single cohesive model that encompasses all aspects of a business in support of business and IT initiatives. A well-developed EA optimizes business processes by eliminating redundancy, contradictions and identifying gaps [17]. EAFs help organizations to build target-conformant enterprise architecture that is flexible, adaptable and efficient [25]. The four most used Enterprise Architecture Frameworks are the Zachman Framework, The Open Group Architecture Framework (TOGAF), Federal Architecture Framework (FEA) and the Gartner Methodology TOGAF TOGAF is growingly considered to be the de facto standard way of working for the development and deployment of modern IT systems in enterprises [2]. TOGAF is freely available to members and non-members and has gained a market penetration of 50% according to its own figures [19]. Ohren[18], made some efforts of characterizing available EAFs. From his architecture framework ontology can be concluded that TOGAF distinguishes itself by the development of an architecture repository to support the organization of re-usable architectures. TOGAF is not wholly specific with respect to generated documents; in fact, it provides very little in the way of prescriptive document templates merely guidelines for inputs and outputs [20]. In a comparison of the before mentioned four 'frameworks' Sessions [22] states that TOGAF, although self-described as a

3 framework, it is actually more accurately defined as a process. He comes to this conclusion because the Architecture Development Method is the most visible and important part of the TOGAF framework, which is a process for creating the architecture artifacts. Figure 2. Phases in the TOGAF Architecture Development Method The Architectural Development Method (ADM) is a detailed, step-by-step method on how to build, maintain, and implement an enterprise architecture. It consists out of 8 different steps in the design cycle. See figure 2. These phases are an indication however, because TOGAF is flexible with respect to the phases. As the specification itself says: One of the tasks before applying the ADM is to review its components for applicability, and then tailor them as appropriate to the circumstances of the individual enterprise. This activity might well produce an "enterprisespecific" ADM [29]. TOGAF allows phases to be done incompletely, skipped, combined, reordered, or reshaped to fit the needs of the situation [22]. Appendix B contains an overview off the most important elements of the TOGAF method. Next we will describe these elements to get a better understanding of what they are. Architecture development Method (ADM), the development process, is the most visual element of TOGAF. The ADM provides a tested and repeatable process for developing architectures. The ADM includes establishing an architecture framework, developing architecture content, transitioning, and governing the realization of architectures. All of these activities are carried out within an iterative cycle of continuous architecture definition and realization that allows organizations to transform their enterprises in a controlled manner in response to business goals and opportunities. The Architecture Board oversees the implementation of the governance strategy. This body should be representative of all the key stakeholders in the architecture. Architecture Compliance Assessment. Once an architecture has been defined, it is necessary to govern that architecture through implementation to ensure that the original Architecture Vision is appropriately realized and that any implementation lessons are fed back into the architecture process. Period compliance reviews of implementation projects provide a mechanism to review project progress and ensure that the design and implementation is proceeding in-line with the strategic and architectural objectives. Architecture Contracts are the joint agreements between development partners and sponsors on the deliverables, quality, and fitness-for-purpose of an architecture. The Architecture Governance Framework supports the architecture governance by assisting the identification of effective processes and organizational structures, so that the business responsibilities associated with architecture governance can be clarified, communicated, and managed effectively Architecture governance is the practice and orientation by which enterprise architectures and other architectures are managed and controlled at an enterprise-wide level. It includes systems to control over the creation and monitoring of all architectural components and activities. Ensuring compliance with internal and external standards and regulations and ensuring accountability to the stakeholders. Phase G of the TOGAF ADM is dedicated to the implementation governance. The Architecture skills framework provides a set of roles, skills, and experience norms for staff undertaking enterprise architecture work. The Architectural content framework provides a structural model for architectural content that allows the major work products that an architect creates to be consistently defined, structured, and presented. Architecture Building Blocks (ABBs) typically describe required capability and shape the specification of Solution Building Blocks (SBBs). For example, a customer services capability may be required within an enterprise, supported by many SBBs, such as processes, data, and application software. Solution Building Blocks (SBBs) represent components that will be used to implement the required capability. For example, a network is a building block that can be described through complementary artifacts and then put to use to realize solutions for the enterprise. The Architecture Definition Document is the deliverable container for the core architectural artifacts created during a project and for important related information. The Architecture Definition Document spans all architecture domains (business, data, application, and technology) and also examines all relevant states of the architecture (baseline, transition, and target). The Architecture Definition Document provides a qualitative view of the solution and aims to communicate the intent of the architect. A Transition Architecture shows the enterprise at an architecturally significant state between the Baseline and Target Architectures. Transition Architectures are used to describe transitional Target Architectures necessary for effective realization of the Target Architecture. Architecture Patterns are a technique for putting building blocks into context. Patterns can be used to describe a re-usable solution to a problem. Building blocks are what you use. Patterns can tell you how you use them, when, why, and what trade-offs you have to make in doing so.

4 Architecture Principles are a qualitative statement of intent that should be met by the architecture. They have at least a supporting rationale and a measure of importance. Principles are general rules and guidelines, intended to be enduring and seldom amended, that inform and support the way in which an organization sets about fulfilling its mission. We differentiate Business, Data, Application and Technology principles. The Architecture Repository acts as a holding area for all architecture-related projects within the enterprise. The repository allows projects to manage their deliverables, locate re-usable assets, and publish outputs to stakeholders and other interested parties. Part of the repository is the Reference library which provides guidelines, templates, patterns, and other forms of reference material that can be leveraged in order to accelerate the creation of new architectures for the enterprise. Another important aspect of the repository is the Standards information base which captures the standards to which new architectures must comply. They may include industry standards, selected products and services from suppliers, or shared services already deployed within the organization. The Architecture Metamodel describes the organizationally tailored application of an architecture framework, including a method for architecture development and a metamodel for architecture content. The Architecture Requirements Specification provides a quantitative view of the solution, stating measurable criteria that must be met during the implementation of the architecture. The Architecture Roadmap lists individual work packages that will realize the Target Architecture and lays them out on a timeline to show progression from the Baseline Architecture to the Target Architecture. The Architecture Roadmap is incrementally developed throughout Phases E and F, and informed by readily identifiable roadmap components from Phase B, C, and D within the ADM. The Architecture Vision is created early on in the ADM cycle. It provides a summary of the changes to the enterprise that will accrue from successful deployment of the Target Architecture. The purpose of the Architecture Vision is to provide key stakeholders with a formally agreed outcome. Business principles, business goals, and business drivers provide context for architecture work, by describing the needs and ways of working employed by the enterprise. Many factors that lie outside the consideration of architecture discipline may nevertheless have significant implications for the way that architecture is developed. Capability assessments are used to identify the abilities that an organization possesses. Capabilities are typically expressed in general and high-level terms and typically require a combination of organization, people, processes, and technology to achieve. We differentiate a business capability assessment, IT capability assessment, architecture maturity assessment and a Business transformation readiness assessment. The latter provides insight in the readiness of the organization to accept change. Identifying readiness issues and then dealing with them in the Implementation and Migration Plans is vital for a successful architecture transformation in Phases E and F. A Change Request is a document containing a call for an adjustment of the architecture; it may be submitted in order to kick-start a further cycle of architecture work. The development of a Communications Plan allows for effective communication, of targeted information to the right stakeholders at the right time through the right channels, to be carried out within a planned and managed process. The Enterprise Continuum is a categorization mechanism useful for classifying architecture artifacts (Architecture continuum) and solution artifacts (Solutions continuum), both internal and external to the Architecture Repository, as they evolve from generic Foundation Architectures to Organization-Specific Architectures. The Implementation and Migration Plan provides a schedule of the projects that will realize the Target Architecture. The Implementation and Migration Plan includes executable projects grouped into managed portfolios and programs. A key element of the Implementation and Migration Plan is the Implementation and Migration Strategy which provides strategic implementation direction and an implementation sequencing approach. The Implementation Governance Model ensures that a project transitioning into implementation also smoothly transitions into appropriate architecture governance. It does so by defining specific processes, organizations, roles, responsibilities, and measures on a project-by-project basis. Interoperability requirements define the degree to which the information, business processes and services are to be shared. As part of the change management phase Monitoring Tools are deployed that monitor for technology and business changes that impact the baseline architecture. They could eventually lead to change requests. The Organizational model contains the scope of organizations impacted, budget requirements, roles and responsibilities (for architecture teams) and a governance and support strategy. A Request for architecture work is a document that is sent from the sponsoring organization to the architecture organization to trigger the start of an architecture development cycle. Requests for Architecture Work can be created as an output of the Preliminary Phase, a result of approved architecture Change Requests, or terms of reference for architecture work originating from migration planning. A Requirements Impact Assessment assesses the current architecture requirements and specification to identify changes that should be made and the implications of those changes. Risk management. There will always be risk with any architecture/business transformation effort. It is important to identify, classify (assessment), and mitigate these risks before starting so that they can be tracked (monitoring) throughout the transformation effort. It is within the governance framework that the risks have to be accepted and then managed. Stakeholder Management is an important discipline that successful architecture practitioners can use to win support from others. Stakeholder management helps ensure stakeholders support and their input improves the quality of the models produced. Stakeholders are people who have key roles in, or concerns about, the system. Different stakeholders with different roles in the system will have different concerns. Stakeholders can be individuals, teams, or organizations (or classes thereof). Concerns are the key interests that are crucially important to the stakeholders in the system, and determine the acceptability of the system. The Statement of Architecture Work defines the scope and approach that will be used to complete an architecture development cycle. The Statement of Architecture Work is typically the document against which successful execution of the architecture project will be measured and may form the basis for a contractual agreement between the supplier and consumer of architecture services.

5 Tailored architecture framework. Before TOGAF can be effectively used within an architecture project the TOGAF model needs to be tailored for integration into the enterprise and also tailored for the specific architecture project. This tailoring will include integration with project and process management frameworks, customization of terminology, development of presentational styles, selection, configuration, and deployment of architecture tools, etc. The formality and detail of any frameworks adopted should also align with the organizational context, such as culture, stakeholders, commercial models for enterprise architecture, and the existing level of Architecture Capability. The Technical reference model (TRM) is a taxonomy that categorizes a set of technology areas and their relationships at a conceptual level. It establishes a common structure and vocabulary for describing technology components. Solution development & deployment. During Phase G (Implementation & Migration) the actual solution is implemented and deployed. This is not a direct output of the architecture development process. But because of its importance it is also listed as an element of TOGAF. 2.3 Maturity models Maturity models date back to the early seventies. In contrast to popular believe the first application of a staged maturity model to IT was not by CMM/SEI, but rather by Richard L. Nolan, who, in 1973 published the stages of growth model for IT organizations. The Capability Maturity Model (CMM) was originally developed as a tool for objectively assessing the ability of government contractors' processes to perform a contracted software project. The CMM is based on the process maturity framework first described in the 1989 book Managing the Software Process by Watts Humphrey. It was later published in a report in 1993 (Technical Report CMU/SEI-93- TR-024 ESC-TR February 1993, Capability Maturity Model for Software, Version 1.1) and as a book by the same authors in The CMM model proved useful to many organizations, but its application in software development has sometimes been problematic. Applying multiple models that are not integrated within and across an organization could be costly in training, appraisals, and improvement activities. The Capability Maturity Model Integration (CMMI) project was formed to sort out the problem of using multiple CMMs.[31] For software development processes, the CMM has been superseded by CMMI, though the CMM continues to be a general theoretical process capability model used in the public domain. CMMI was developed by the CMMI project, which aimed to improve the usability of maturity models by integrating many different models into one framework. The project consisted of members of industry, government and the Carnegie Mellon Software Engineering Institute (SEI). Maturity models can be categorized in one of two types of maturity models [26]. (i) Staged models: These models distinguish five levels of maturity. For each level a number of focus areas are defined specific to that level. These focus areas have to be implemented satisfactorily for the organization to achieve that particular level. (ii) Continuous models: These models also distinguish five general maturity levels and a number of focus areas. The difference with the first kind of models is that the focus areas are not attributed to a level, but within each focus area the 5 levels are distinguished. 2.4 Enterprise architecture maturity models With the emergence of enterprise architecture also a lot of maturity models specifically tailored for enterprise architecture were developed.[1,3,16,26] According to NASCIO an essential part of enterprise architecture development is for the organizations to assess their current situation, and then set goals for the future. Identifying the maturity of EA Architecture program components formally allows the organization to benchmark the status of current programs and begin the process of improving their effectiveness, or kick off a new program.[16] Architecture Capability Maturity Models (ACMMs) provide an effective and proven method for an organization to gradually gain control over and improve its architecture change processes. By describing process improvement practices and a framework to measure that improvement. A maturity model is not only suitable as an assessment tool of the current state of the architecture. It could also be used as a roadmap of steps to take to improve the enterprise architecture [30]. 2.5 NASCIO One of the most used models is the National Association of State Chief Information Officers ( NASCIO) Enterprise architecture maturity model [14,29]. It is also proposed by TOGAF to perform Enterprise architecture maturity assessments. The model is based on the Capability Maturity Model developed by the Software Engineering Institute (SEI). NASCIO describes the intent of the model as: to supply a tool that can be used to benchmark the effectiveness of an Enterprise Architecture program. It also illustrates the natural progression of benefits that a supported and managed architecture program will contribute to an organization as it matures. NASCIO organizes its maturity descriptions by 8 different categories: Architecture Planning ensures the program is managed to assure the goals for implementation are realistic and achievable and the program is kept within scope. Architecture Framework consists of the processes, templates and forms used by those documenting the operations and standards of the organization. Architecture Blueprint refers to the completed documents that are prepared using the Architecture Framework processes, templates and forms. The Blueprint refers to the documented products and standards, together with their detail, classifications, impact statements, and migration strategies. Communication is the element that ensures standards and processes are established and readily available to team members for reference and use. As an organization changes and programs evolve the continued communication ensures the EA program remains vital and operates optimally. Compliance must be reviewed periodically to be sure the business and IT programs and services are operating effectively. Integration addresses the ability of the various entities (internal or external to the organization) to coordinate their efforts to the greatest benefit of the organization. This is a key factor, as great efficiencies are gained by identifying similar functions or operations, both inside and outside of an organization. Involvement must be part of an EA Program. Without the support of managers and employees who are expected to utilize and follow the defined process, the program is sure to fail.

6 The maturity model is a staged model which differentiates 6 stages of maturity, from no program (immature) to a continuously improved program (mature). We will give a short description of each of these stages. Appendix A contains a more in-depth description of the (for our research relevant) elements in each of the 6 stages. Or consult the NASCIO maturity model document for a more detailed description for each of the different stages[16]. Level 0: No program. At this level there is not a documented architectural framework in place at this level of maturity. While solutions are developed and implemented, this is done with no recognized standards or base practices. The organization is completely reliant on the knowledge of independent contributors. Level 1: Informal program. The base architecture framework and standards have been defined and are typically performed informally. There is general consensus that these steps should be performed, however they may not be tracked and followed. Organizations with an Enterprise Architecture framework at this level are still dependent on the knowledge of individual contributors. Level 2: Repeatable program. The base architecture and standards have been identified and are being tracked and verified. At this point in the program processes are repeatable and reusable templates are starting to be developed. The need for product and compliance components to conform to the standards and requirements has been agreed upon, and metrics are used to track process area performance. Level 3: Well-defined program. The enterprise architecture framework is well defined; using approved standard and/or customized versions of the templates. Processes are documented across the organization. Performance metrics are being tracked and monitored in relationship to other general practices and process areas. Level 4: Managed program. At this point performance metrics are collected, analyzed and acted upon. The metrics are used to predict performance and provide better understanding of the processes and capabilities. Level 5: Continuously improved program. The processes are mature; targets have been set for effectiveness and efficiency based on business and technical goals. There are ongoing refinements and improvements based on the understanding of the impact changes have to these processes. 3. USE OF TOGAF IN EACH LEVEL With every level of architecture maturity more elements of TOGAF should be adopted in the EA process. In this chapter we will describe these elements for each of the maturity levels. Because a higher maturity builds on lower levels only the elements introduced in that maturity level are specified. An overview of the mapping of the NASCIO elements to the TOGAF elements can be found in Appendix A. An overview of the TOGAF elements in each of the maturity levels can be found in Appendix B. That table also contains a mapping of the TOGAF elements on the different categories distinguished by NASCIO in its maturity model. 3.1 Level 0: No program At this maturity stage TOGAF has not yet entered the reality of the organization. The awareness and even most elementary use of an enterprise architecture framework would put the organization in a higher maturity level. 3.2 Level 1: Informal program According to NASCIO the architecture activities and the architecture process are informal and unstructured at this stage of maturity. There is no defined process and the success of the architecture activities depends on the efforts of individual contributors. These contributors can use aspects of the ADM in isolation. For the development of a baseline and target architecture they could use the architecture vision phase of the ADM as guide. According to the TOGAF document the goal of the architecture vision phase is develop a high-level aspirational vision of the capabilities and business value to be delivered as a result of the proposed enterprise architecture. As part of the vision phase it provides a step by step plan to deliver a lowlevel (0.1 version) business, application and technology architecture. These steps don t rely on the existence or knowledge of other TOGAF elements and could therefore well be used in isolation. The deliverable can be seen as an immature or draft (v0.1) architecture definition document. One of the biggest reasons for EA failure is a lack of focus on the business aspects early on in the architecture life cycle[4,24]. It is therefore important to focus on business architecture as well as the IT architectures and involve the business practice in the process. NASCIO describes the informal documentation of business drivers in this maturity stage. The business principles, goals and drivers element of TOGAF could be beneficial in guiding this documentation. One of the first things you want to do in developing an enterprise architecture is demonstrating success[23]. This helps you build momentum and establish credibility early on. It is therefore important to develop and deploy solutions early on. In this level of architecture maturity there is very little communication about the architecture and its documents. 3.3 Level 2: Repeatable program At this maturity level the need for governance has been identified. TOGAF supports this by means of an Architecture Governance Framework. The forming of committees has started, but this is not a very formal process. The development of clear roles and responsibilities is supported by the stakeholder management process and documented as part of the organizational model. In this level of maturity the organization should have decided on the use of an architecture methodology ( ADM) and start tailoring the architecture framework. The tailoring of the framework has become important because a lot of elements of TOGAF get introduced to the architecture process in this maturity level leading to an increase in complexity. The (tailored) Architecture program is documented within the architecture metamodel which is part of the architecture repository. The customized Architecture development Method forms the bases for EA program plan that should be developed. The architecture principles, which are defined in addition to the business principles, are also an input to the identification of EA tasks. The Migration & Implementation Plan and Architecture Roadmap are key deliverables regarding planning. In this maturity level focus is on the resource requirements and business value of the individual projects. The organization is beginning to reuse methods for capturing critical EA information. This could be supported by a fixed set of artifacts, which are documented in the content metamodel. The technical reference model provides taxonomy for describing technology components. The growing need for storage and dissemination of architecture documents can be filled by the architecture repository. The architecture

7 definition document is used to contain the core architectural artifacts created and now also contain transition architectures. The architecture principles together with the Architecture Vision are key elements used in the identification of strategic info. The organization has begun to develop a compliance process to ensure that projects and enhancements are consistent with EA standards. TOGAF provides architecture compliance assessment to support this process. The need for Enterprise Architecture is being communicated to Senior Management and EA awareness activities are beginning to emerge or be developed. The organization also begins to develop plans for EA educational sessions and materials to increase the awareness and understanding of the EA concepts and processes. All communications efforts are planned through the Communications plan element of TOGAF. Although EA awareness is one of the key success factors for enterprise architecture there are no direct references to it in the TOGAF documentation. EA awareness and involvement are however improved by a well-executed communications plan and readily available architecture documentation. 3.4 Level 3: Well-defined program Most of the TOGAF elements used in the previous maturity level will be developed more extensively in this level. For instance the Implementation and migration planning is extended by focusing on the timeline and financial requirements of the different projects. The governance committees get a more formal nature. An architecture board could be formed and the Architecture skills framework could be useful to support the definition of well-defined governance committees. The organization starts using templates to capture information consistently. These templates are located within the reference library. The use of an Standards information base assists in the classification of existing technology standards in a consistent way. Architecture Patterns help to identify combinations of Architecture Building blocks and/or Solution Building Blocks (ABBs/SBBs) that have been proven to deliver effective solutions in the past. The Enterprise continuum acts as a categorization mechanism for all the architectural and solution artifacts. The EA Compliance process is followed consistently throughout the enterprise. If there is a variance to the requirements or architecture definition document a change request may be created to kick-start a new development cycle. When a new cycle is necessary a request for work is created. Interoperability requirements could be used to improve the integration between the EA Program and strategic planning and budgeting processes by describing the way information and services are shared. 3.5 Level 4: Managed program The main difference between organizations in this maturity level and the previous one is the extent to which metrics are used to measure progress and effectiveness. For instance the organization captures metrics to measure the progress against the established EA plans. The Architecture requirements specification provides quantitative statements that outline what a project must do in order to comply with the architecture. It is typically a major component of the architecture contracts. The statement of architecture work is another document in which quantitative measurements are defined. They are used to measure whether the project is successfully executed. Requirements impact assessments can be used to identify the need for updates to architecture documentation and/or classifications. Corrective action plans are put in place when deficiencies in templates and/or procedures are identified. The risks and issues that may threaten the success of the enterprise architecture practice and its ability to meet its vision, goals and objectives is assessed. This helps the organization to improve the effectiveness of the architecture program. Although a government framework is already in place, specific processes, organizations, roles, responsibilities, and measures may need to be defined on a project-by-project basis. The Implementation Governance Model could be used to support this. 3.6 Level 5: Continuously improved program Requirements Impact Assessment assesses the current architecture requirements and specification to identify changes that should be made and the implications of those changes. Based on these implications the architecture is updated. Monitoring tools are deployed to watch for new technology and business trends that will improve the business. 4. CONCLUSION The maturity models provide some indication for what TOGAF elements to focus on early in the enterprise architecture maturity and which elements to postpone, until a higher maturity is reached. It could offer a kind of roadmap on top of the step-by-step plan offered by the architecture development method (ADM), which is the most visual and most important part of TOGAF. Besides offering a good step-by-step process it also introduces a lot of processes, deliverables & methods to use within or on top of it. The maturity based roadmap could help identify the elements that are relevant for the organization at hand, offering guidance for the architects in selecting what elements to focus on. The more modular specification document introduced by the Open Group with version 9.1 makes this focus on single elements easier. This helps avoid the architect getting overwhelmed by information and also making the architecture process less complex. Although our research could offer benefits in theory this should be proven in practice. Due to the limited time offered to the bachelor thesis project we don t provide a validation of the proposed mapping in practice. 4.1 Future work The most important restriction of our research is a lack of validation to see whether our results comply with actual use of TOGAF. It would, in general, be interesting to see what elements of TOGAF have been adopted in the real world and how successful these architecture projects have been. And to be more specific, how the adopted elements relate to the architecture maturity of the organizations. Within the specification document they make notion that a future versions of TOGAF may include a maturity model to measure adoption of TOGAF itself. This paper could be used as a starting point for such a maturity model. This model should assess whether the relevant elements of TOGAF have been adopted in the given maturity stage. 5. REFERENCES 1. Department of Commerce. Enterprise Architecture Capability Maturity Model - Version: Dietz, J.L.G. and Hoogervorst, J.A.P. A Critical Investigation of TOGAF - Based on the Enterprise Engineering Theory and Practice. In A. Albani, J. Dietz

8 and J. Verelst, eds., Advances in Enterprise Engineering V. Springer-Verlag Berlin, Berlin, 2011, GAO. A Framework for Assessing and Improving Enterprise Architecture Management (Version 1.1).. 4. Gartner. Ten Enterprise Architecture Pitfalls Identified Gokhale, A. Increasing Effectiveness Of The Zachman Framework Using The Balanced Scorecard. (2010). 6. Henderson, J.C. and Venkatraman, N. Strategic alignment: leveraging information technology for transforming organizations. IBM Systems Journal 32, (1993), Iacob, M.-E., Franken, H., and Berg, H. van den. Handbook enterprise architecture : method, language and tools. BiZZdesign, Enschede, IEEE. IEEE Std : IEEE Recommended Practice for Architectural Description of Software-Intensive Systems. IEEE, (2000). 9. Iyer, B. and Gottlieb, R. The Four-Domain Architecture: An approach to support enterprise architecture design. IBM Systems Journal 43, 3 (2004), Jonkers, H., Lankhorst, M.M., ter Doest, H.W.., Arbab, F., Bosma, H., and Wieringa, R.J. Enterprise architecture: Management tool and blueprint for the organisation. Information Systems Frontiers 8, 2 (2006), Kayworth, T.R., Chatterjee, D., and Sambamurthy, V. Theoretical justification for IT infrastructure investments. Advanced topics in information resources management 1,, Lankhorst, M. Enterprise architecture at work: Modelling, communication and analysis. Springer-Verlag New York Inc, Leist, S. and Zellner, G. Evaluation of current architecture frameworks. Proceedings of the 2006 ACM symposium on Applied computing, (2006), Meyer, M., Helfert, M., and O Brien, C. An Analysis of Enterprise Architecture Maturity Frameworks. In J. Grabis, M. Kirikova, W. Aalst, et al., eds., Perspectives in Business Informatics Research. Springer Berlin Heidelberg, 2011, Murch, R. Managing Complexity in IT, Part 1: The Problem. In NASCIO. NASCIO Enterprise Architecture Maturity Model Version Oda, S., Fu, H., and Zhu, Y. Enterprise Information Security Architecture A Review of Frameworks, Methodology, and Case Studies ND IEEE INTERNATIONAL CONFERENCE ON COMPUTER SCIENCE AND, (2009), Ohren, O. An ontological approach to characterising enterprise architecture frameworks. Knowledge Sharing in the Integrated Enterprise: Interoperability 183, (2005), Opengroup. Newsletter - Togaf 9 survey results Perks, C. and Beveridge, T. Guide to Enterprise IT Architecture. Springer-Verlag New York, Inc., Ross, J.W., Weill, P., and Robertson, D. Enterprise architecture as strategy: creating a foundation for business execution. Harvard Business Press, Sessions, R. A Comparison of the Top Four Enterprise- Architecture Methodologies Sessions, R. A Better Path to Enterprise Architectures Shaw, B. Enterprise Architecture Will Yours Fail Too. il.htm. 25. Song, H. and Song, Y.-T. Enterprise architecture institutionalization and assessment. Proceedings - 9th IEEE/ACIS International Conference on Computer and Information Science, ICIS 2010, (2010), van Steenbergen, M., van den Berg, M., and Brinkkemper, S. A Balanced Approach to Developing the Enterprise Architecture Practice. ENTERPRISE INFORMATION SYSTEMS-BOOKS 12, (2008), Steenbergen, M. van. Maturity and effectiveness of enterprise architecture. (2011). 28. Sunduran, S. Five Keys to a Successful Enterprise Architecture Program -- Enterprise Systems. Architecture.aspx?Page=3&p= The Open Group. The Open Group Architecture Framework (TOGAF), version 9. Van Haren Publishing, Zaltbommel, Vermoolen, J. Een volwassenheidsgroeimodel voor Enterprise Architectuur - Hulpmiddel voor organisatiegerichte IT Wikipedia contributors. Capability Maturity Model. Wikipedia, the free encyclopedia, ity_model&oldid= World-Class Enterprise Architecture. Whitepaper, The Open Group, (2010).

9 APPENDIX A NASCIO ELEMENTS MAPPED TO TOGAF NASCIO elements TOGAF elements 0: No EA program 1: Informal program Informal EA activities by individual contributors Informal and incosistent business drivers 2: Repeatable program Identified need for governance Begin development of clear roles & responsibilities Begin development of an architecture vision Identify EA tasks and resource requirements Develop a EA plan Decide on a methodology EA program is documented Identification of strategic info Technology standards identified Ensure project compliance with standards EA repository for storage and dissemination needed Need for communication to Senior management 3: Well defined program Architecture committees are defined and their authority are aligned Templates are used for consistent information capturing Consistent classification of existing standards Formal EA compliance process as part of EA lifecycle processes EA program is integrated with strategic planning and budget 4: Managed program Measure architecture progress against EA plan Documentation and classification of products and compliance Capture metrics to improve effectiveness 5: Continuously improved program Proactively review architecture program Monitoring of new business & technology trends Architecture vision (phase) Architecture definition document Architecture Development Method Business Principles, Goals and Drivers Architecture governance framework Organizational model Stakeholder management process Architecture vision Architecture principles Architecture roadmap Migration & implementation plan Architecture development method Tailoring of the architecture framework Architecture & content metamodel Architecture vision Technical reference model Architecture compliance assessment Architecture repository Communications plan Architecture board Architecture skills framework Reference library Standards information base Architecture patterns Architecture building & solutions blocks Enterprise continuum Change requests & request for arch. Work Interoperability requirements Architecture requirements specification Architecture contracts Statement of architecture work Requirements impact assessment Risk management Requirements impact assessment Monitoring tools

10 APPENDIX B TOGAF ELEMENTS IN EACH MATURITY LEVEL