Why Two Thirds of Enterprise Architecture Projects Fail

Transcription

1 Why Two Thirds of Enterprise Architecture Projects Fail An explanation for the limited success of architecture projects Sven Roeleven Solution Manager Business White Paper December 2010

2 Contents Introduction 3 Drivers for EA 4 Older organizations have higher integration of architectures 5 Large organizations have more EA roles 5 Who is responsible for the purchasing of an EA tool? 6 Explanations for disappointing results 7 How can we ensure the success of an EA project? 9 Large and medium-sized organizations regard the alignment of business and IT as the most important motive for working on an enterprise architecture (EA). Other important reasons for putting EA on the agenda are support for change processes and strengthening the flexibility of the company. In spite of the huge interest in EA it turns out that 66 percent of programs did not fulfill expectations. Sven Roeleven is a Global Solutions Manager. After graduating in Public Administration from Erasmus University Rotterdam (the Netherlands), he went on to specialize in business process management within ERP environments. Sven has gained extensive hands-on experience covering all ARIS platform products throughout the course of dozens of projects within medium-sized and larger organizations across a variety of industries. 2 WHITE PAPER Why EA-Projects fail

3 Introduction This is the conclusion of a study for the Rotterdam University carried out by Jonathan Broer in the summer of 2008, ordered by BPM and EA software vendor IDS Scheer. Broer questioned 161 respondents from 89 organizations representing a range of industries about their vision and implementation of the enterprise architecture concept. Figure 1: Industries that participated in the study This ARIS White Paper comprises: an overview of typical Enterprise Architecture project roles and drivers main targets of Enterprise Architecture projects and initiatives critical success factors derived out of the survey A clear majority of respondents 92 percent believes that EA should be determined by the vision, strategy and objectives of the company. Yet only 40 percent of them actually included objectives and policies in their EA program. The alignment of Business and IT is seen as the most important argument for organizations to start using EA. At the same time connecting IT architecture and business elements, and arriving at important decisions about structure and layout on that basis, is found to be one of the biggest problems confronting businesses. Among the reasons for the failure of EA programs to fulfill expectations were a lack of EA awareness and the fact that it took longer than expected to set up an architecture. WHITE PAPER Why EA-Projects fail 3

4 Drivers for EA Organizations start using EA for different reasons. Business and IT streamlining, supporting change processes and achieving greater flexibility are the three most important reasons for starting an EA project. This fits the definition of EA used by research agency Gartner: Enterprise architecture is the process of translating business vision and strategy into effective enterprise change [..]. Figure 2: Drivers for EA projects The fact that EA is determined by vision, strategy and objectives is also affirmed by 92 percent of the organizations taking part in the study. In other words, organizations have a clear understanding of the reasons for starting an EA project, and they know that these drivers are partly determined by the business strategy. In their vision EA is therefore a holistic, business-driven discipline. 4 WHITE PAPER Why EA-Projects fail

5 Older organizations have higher integration of architectures Apart from their well-developed vision, organizations have also come quite far in the implementation of enterprise architectures. 74 percent already use a framework for EA, and the majority of those without a framework are in the process of choosing one. The most commonly used standard frameworks are TOGAF (The Open Group Architecture Framework) and ArchiMate (adopted by TOGAF in 2008 as standard modeling language). The older organizations (more than 50 years old) are often further ahead in the integration of domain architectures. In many cases they have been involved in mergers or takeovers which necessitate a good integration. The presence of legacy systems also plays an important role. It is important after all to know what the consequences of phasing out a system will be for the entire operational management the consequences for data exchanged with the system for example, or for the infrastructure on which it runs, or for the processes supported by the system which is about to be phased out. Large organizations have more EA roles There is also a connection between the size of an organization and the presence of EA related roles. The larger the organization, the larger the presence of these roles in the EA work field. Figure 3: Presence of EA related roles For small organizations the information architect is used the most. For large organizations it is the business architect. Respondent comments show that small organizations approach EA much more from an IT point of view. Larger organizations which appear to be more mature in their enterprise architecture have a more business-oriented approach, and they cite the business architect as the most common role. WHITE PAPER Why EA-Projects fail 5

6 Who is responsible for the purchasing of an EA tool? As regards the responsibility for purchasing an EA tool, it is notable that the IT manager and CIO play a far bigger role in the purchase of an EA tool than in the purchase of an ERP package for example. When purchasing an ERP package there is a larger contribution from the business, whereas EA tooling is primarily approached from the IT perspective. This is rather surprising considering that the older, larger companies tend to approach EA from a business perspective. One possible explanation for this is that the business reality has already been reproduced in a process modeling tool, and this is the responsibility of the CIO and the IT manager in most organizations. Figure 4: Responsibility for IT investments 6 WHITE PAPER Why EA-Projects fail

7 Explanations for disappointing results In spite of the fact that organizations already have a reasonably mature vision and implementation, the expected results are not achieved in 66 percent of the EA projects. The most frequent explanation given for this failure is that connecting EA to business elements such as strategy and BPM is found to be difficult in practice. Figure 5: Most common EA problems Other reasons given by many respondents for the failure to meet expectations were: Not enough support from C-level (CIO and CFO for example) so that EA is not given enough status and expectations cannot be fulfilled in practice. Limited commitment from interested parties so that there is a return to old habits, and agreements are not complied with. Not enough EA awareness among interested parties inside the organization. EA not a generally accepted concept in daily business activities. Financial and political issues that thwart EA projects. Setting up an architecture takes longer than expected. This means it takes longer for the results to become visible, which means there is a considerable risk factor for EA. WHITE PAPER Why EA-Projects fail 7

8 Figure 6: Most commonly recorded domain architectures Another possible explanation is the discrepancy between initial intentions for EA on the one hand and the actual realization of the architectures and degree of compliance with agreements on the other. For example: 92 percent of the organizations believe that vision, strategy and objectives are determining factors for EA, yet only 40 percent incorporated them in the architecture. On this basis it is of course impossible to define the direct impact of strategic choices on the architectural lay-out. The following histogram provides an overview of the most frequently recorded domain architectures, including those for objective and policies. Figure 7: The way EA is implemented The three most frequently recorded architectures are found to be the application architecture, process architecture and information architecture. 8 WHITE PAPER Why EA-Projects fail

9 The recording of domain architectures does not mean there is a successful enterprise architecture in place however. Agreements also have to be complied with about the use of one another s information, the methods to be used, ownership, and procedures for arriving at innovations. All this is collectively referred to as EA Governance. In the following graph, four principles of EA Governance show that the organizations do not score highly for maturity. This may help to explain the disappointing results of EA projects. Even when a big effort has been made to sort out EA, a lack of (compliance with) agreements leads to relatively low yields. Since the recorded EA is not an integrated component of operational management, there is a lack of commitment. This undermines the status of EA inside the organization. Also, architectures are often constructed which be ar no relation to other architectures inside the organization. As a result there are no gains from rapid impact analyses, coordination between domain owners and integrated project scheduling. Structural monitoring of compliance with architectural principles can help in this regard, but this is not sufficiently applied in practice. How can we ensure the success of an EA project? The study shows that the following three rules will help to create the right conditions for making EA successful in an organization: 1. Set clear, enterprise-wide EA objectives before you start, and manage expectations inside the organization. The objectives affect the choice of the EA concept, including the choice of domain architectures and the degree of integration between them. With clear objectives it is easier to manage expectations in relation to EA inside the organization. In this way disappointment is avoided and the organization does not have to spend a lot of time and energy trying to create an architecture which is never realized. By deploying EA enterprise-wide it is also easier to demonstrate that a shared approach to EA pays off, in comparison to the silos of documentation in Excel, Word and niche tools, with all the duplication and inconsistencies these involve. Use it to raise the level of commitment and celebrate the successes achieved. 2. Set up EA Governance and comply with it. If the methods and agreements drawn up are not complied with by the EA roles, the yield from the EA initiative will be inadequate. Appoint a Chief EA to oversee compliance who also reports to higher management (C-level). Higher management can in turn ask for feedback through the Chief EA about the impact of strategic management choices on operational management and operational structures. In the context of EA Governance, it is important to specify in the standard project approach that it is mandatory to check what information has already been recorded on the scope of the project; this information should be used as a starting point for the TO-BE situation. It is also important of course that EA owners validate innovations according to a fixed release procedure, and for the new AS-IS situation to be documented in the EA tool before discharging responsibility for the project. 3. Make sure the business is sufficiently involved in these initiatives, starting with the choice of the EA tool. Do not allow EA procedures and tooling to become an IT matter, otherwise the EA will not serve as driver of business and IT streamlining. Choose a tool that supports all domain architectures and is able to connect them in a single repository. Also make sure the tool can incorporate ownership, combine the different methods used, and produce flexible reports. Tools that already provide standard EA frameworks such as TOGAF, IAF and ArchiMate are preferable in this regard. WHITE PAPER Why EA-Projects fail 9

10 Notes 10 WHITE PAPER Why EA-Projects fail

11 Notes WHITE PAPER Why EA-Projects fail 11

12 T O F I N D T H E S O F T W A R E A G O F F I C E N E A R E S T Y O U, P L E A S E V I S I T W W W. S O F T W A R E A G. C O M Take the next step to get there faster. ABOUT SOFTWARE AG Software AG is the global leader in Business Process Excellence. Our 40 years of innovation include the invention of the first high-performance transactional database, Adabas; the first business process analysis platform, ARIS; and the first B2B server and SOAbased integration platform, webmethods. We offer our customers end-to-end Business Process Management (BPM) solutions delivering low Total-Cost-of-Ownership and high ease of use. Our industry-leading brands, ARIS, webmethods, Adabas, Natural, CentraSite and IDS Scheer Consulting, represent a unique portfolio encompassing: process strategy, design, integration and control; SOA-based integration and data management; process-driven SAP implementation; and strategic process consulting and services. Software AG - Get There Faster 2011 Software AG. All rights reserved. Software AG and all Software AG products are either trademarks or registered trademarks of Software AG. Other product and company names mentioned herein may be the trademarks of their respective owners. SAG_EA_EA-Projects_Fail_WP_Dec10