IT Architecture Is Not Enterprise Architecture

Research Publication Date: 17 November 2010 ID Number: G00206910 IT Architecture Is Not Enterprise Architecture Bruce Robertson Many enterprise architecture (EA) teams and their stakeholders still use "IT architecture" as a term synonymous with EA. This misperception limits EA scope and, thus, possible business outcomes and EA value. Key Findings Many EA teams and their stakeholders still use the term "IT architecture" to refer to EA. This effectively limits EA's scope and the value delivered, and increases the risk that the EA program will be ignored or cut. IT architecture is not synonymous with EA. IT architecture typically means focusing only on the enterprise technical architecture (ETA) aspects of EA. IT architecture always includes individual solution or project architecture work, which is not EA activity at all. Recommendations Move from an IT architecture approach to a full EA approach. Avoid using the term "IT architecture" certainly don't use it as a synonym for EA. Educate those who still use IT architecture and EA synonymously, clarifying the significantly wider scope and value of holistic EA. 2010 Gartner, Inc. and/or its affiliates. All rights reserved. Gartner is a registered trademark of Gartner, Inc. or its affiliates. This publication may not be reproduced or distributed in any form without Gartner's prior written permission. The information contained in this publication has been obtained from sources believed to be reliable. Gartner disclaims all warranties as to the accuracy, completeness or adequacy of such information and shall have no liability for errors, omissions or inadequacies in such information. This publication consists of the opinions of Gartner's research organization and should not be construed as statements of fact. The opinions expressed herein are subject to change without notice. Although Gartner research may include a discussion of related legal issues, Gartner does not provide legal advice or services and its research should not be construed or used as such. Gartner is a public company, and its shareholders may include firms and funds that have financial interests in entities covered in Gartner research. Gartner's Board of Directors may include senior managers of these firms or funds. Gartner research is produced independently by its research organization without input or influence from these firms, funds or their managers. For further information on the independence and integrity of Gartner research, see "Guiding Principles on Independence and Objectivity" on its website, http://www.gartner.com/technology/about/ombudsman/omb_guide2.jsp

ANALYSIS Overly IT-focused EA programs miss significant opportunities to improve their enterprises in business outcome visible ways, and are at risk of being ignored or, worse, cut. Although EA includes IT-enabled or technology-sophisticated enterprise improvements, EA is not just focused on IT. Yet, all too often, that's what CIOs and other IT and business leaders think. It is often what those new to EA think as well. This antique and limited scope view of EA being just about IT is captured in the term often incorrectly used as a synonym for EA: "IT architecture." Thirty percent of more than 200 Gartner interactions in 2010 confirm that IT architecture terminology is used by EA practitioners and, even more so, their stakeholders. Inquiry discussions occurred in 2010 and represent terminology used by EA team members directly or by key EA stakeholders (CIOs and other IT leaders, as well as multiple IT staff positions, even business stakeholders outside IT in a few cases). Contributing to this misunderstanding of the terms is the organizational reality that the EA office often reports to the CIO further cementing the association of architecture with IT. Because many EA efforts grew out of infrastructure rationalization efforts, also commonly called "IT architecture," EA offices have historically reported to the CIO. EA's role is not just to improve IT it is to improve the whole enterprise. Clarifying this distinction to improve stakeholder understanding and buy-in should be an early focus of any EA team a critical message that must be communicated until the enterprise no longer thinks it is enough to do just IT architecture. Although the EA program may start out with a limited IT architecture approach, this initial focus should only be a step in the greater maturity of an overall best-practice EA approach. Multiple Meanings of IT Architecture Limit EA's Scope There are three distinct meanings for the "IT architecture" term and each represents significant limitations in scope and ambition for EA efforts: 1. IT architecture = ETA only 2. IT architecture = ETA + some enterprise solution architecture (ESA) application portfolio management (APM) only 3. IT architecture = EA for IT business unit only This research will point out the initial benefits of each usage, but then the significant drawbacks and limitations of each one "the good, the bad and the ugly" of using the term "IT architecture." Table 1. Comparing EA to the Multiple Meanings of IT Architecture Meaning No. 1: IT Architecture = ETA Only Enterprise Technical Architecture (ETA) Enterprise Information Architecture (EIA) Enterprise Business Architecture (EBA) EA No No IT Architecture Publication Date: 17 November 2010/ID Number: G00206910 Page 2 of 6

Enterprise Solution Architecture (ESA) Meaning No. 2: IT Architecture = ETA + Some ESA (APM Only) Business Context No Application Portfolio Management (APM) Solution or Project Architecture Meaning No. 3: IT Architecture = EA for IT BU Only Scope/Focus Source: Gartner (November 2010) EA No (but individual solutions are included in the current state of the EA, and EA teams work with distinct SA teams) Enterprise (can focus at single BU or enterprise level) Meaning No. 1: IT Architecture = ETA Only No Sometimes IT Architecture (but only from a technical/eta perspective) IT only (but EBA view includes Information Technology Infrastructure Library [ITIL] and others) The Good: It is not wrong to do ETA work in fact, Gartner has much research on this topic. Start investigating Gartner's research on ETA with "Enterprise Architecture Research Index: Enterprise Technology Architecture." Certainly, part of any EA program will need to address ITcentric and primarily technology-oriented issues this is a valid perspective on the enterprise. The Bad: Although it is common for EA teams to start with ETA work, this is not all the EA work that needs to be done. EA's more-holistic definition (see "Gartner Clarifies the Definition of the Term 'Enterprise Architecture'") includes enterprise business (EBA) and information architecture (EIA) together with ETA driving toward synergies in ESA work, including solution portfolio management, solution patterns and supporting individual solution architecture work. The Ugly: Gartner's EA approach also includes a strong emphasis on building the business context of trends and business strategies that, in turn, drive requirements for change in the business and, thus, the architecture of that enterprise (for example, including process and people aspects), and via EA planning these change requirements are mapped into IT strategy. EA is not driven by IT strategy. It's the other way around, or should be. EA must be driven by the business strategy. For more research in the area of EA strategizing, see "EA Research Index: Integrating Enterprise Architecture With Business Strategy," and then EA, in turn, can drive IT strategy (or completely define IT strategy). If IT strategy is being used to drive EA, it's a guarantee that you're taking an IT architecture approach (not an EA one). Furthermore, the EA team will have been excluded from any analysis of business context and change requirements, as well as any analysis of business process or people changes (EBA, outside those of IT itself as a business unit see definition No. 3). Without this, all IT strategic decisions seem IT-only, not business driven. They seem less than linked, aligned or integrated with the business strategy unjustified and thus difficult to sell to the business. This IT architecture approach also typically does not include analysis of information itself (EIA) and just focuses on what technology is needed to manage or store that information. Publication Date: 17 November 2010/ID Number: G00206910 Page 3 of 6

EA does not focus only on IT change; EA also addresses business change. When EA derives requirements for change in the different EA areas, as part of EA strategizing to define the business context, it provides a much more business-visible linkage between IT strategy and investments. Changes in technology can be mapped back to information, people or process changes, and through those changes to business strategies. This missing thread of justification, this line of sight, is what a true EA approach really adds, and where IT architecture normally falls short. Meaning No. 2: IT Architecture = ETA + Some ESA Work One alternative to the technology-only view of definition No. 1 is that some clients add APM to the list of IT architecture activities. For more on ESA and APM techniques, see the Recommended Reading section. The Good: The added emphasis on applications, rather than only technology, is an improvement. Now, at least, technology changes can be linked to application demands, rather than seeming to be just technology-driven. This approach can be a good starting point for the EA program. For an example, see "Toolkit: Enterprise Architecture in E.On's Pragmatic Portfolio Prioritization Case Study." The Bad: Unfortunately, this IT architecture approach is also not as effective as a full EA approach. Although an EA program can start with an APM-driven approach, a full EA approach to APM adds much stronger linkages to EBA and EIA change requirements for the application solution portfolio. Moreover, it addresses all the solution portfolios, not just the application one. The Ugly: You can tell when you've taken this IT architecture approach. You've defined impressive road maps for application change, even mapping in lots of technology changes as recommended, but the business doesn't see the need for any of the changes. It doesn't see this, because this bottom-up approach has not yet defined business changes in process, people or information issues (aka EBA and EIA). Also, while each proposed change project certainly will attempt a business case justification, these justifications are limited to vendor concerns, IT costs, and other IT-only perspectives. These views of the need for change are compelling only to IT not to the business. The need for change in process and people and information is more compelling to the business. If this is understood, then the technical and application changes needed are more likely to be approved. If not, IT remains merely a cost center. Even Uglier: Furthermore, this IT architecture approach tends to include project or solution architecture work work on one project at a time. EA teams that split time between project and EA work generally seem to get less and less EA work done. Projects drain all the time allocated to nonproject work. Although individual solution architecture work on projects is work that must be done, it is not EA work. EA (and even good ETA-only) work is focused on more than one project at a time, more than one application at a time and even more than one BU at a time. EA focuses on architecting the enterprise, not just architecting one system at a time. A mature EA approach, of course, still must integrate with solution architects, and those solution architectures are (at some level) part of the EA as descriptions of the current state. Certainly, also making those solution architectures better by leveraging EA is the goal, so EA programs must define processes (and even services; see "Organize Your Enterprise Architecture Effort: Services") to accomplish this. However, EA is not focused on single-system solution architectures. Meaning No. 3: IT Architecture = Holistic EA for the IT Business Unit Only Another alternative (but much less frequent) definition for IT architecture may seem to take an EA approach, but then it drastically narrows the focus of the work to a single business unit in the enterprise specifically, IT only. In this case, operations work on ITIL, plus other work on the Publication Date: 17 November 2010/ID Number: G00206910 Page 4 of 6

software development life cycle (SDLC), qualifies as a minor amount of EBA work (see "EA and ITIL: The Business Architecture of IT"). There may be some work on IT metrics and EIA as well. The Good: Getting EA defined as focusing on process, people and information is a good extension. More than one EA program in our experience has chosen this as a starting effort for a holistic approach, but it is not as common as the other two approaches. By using a holistic EA approach that is scoped narrowly, at least the EA team and its key customer (the IT organization) start thinking more broadly, outside of technology and solution portfolios. It starts to see business and information architecture concerns as important. It can drive skills that can be later leveraged outside of the IT BU. This can build a proof of concept to show other business units the value of taking the holistic EA approach. Thus, this IT architecture approach is, again, a possible early approach for an immature EA program that does not have strong support from business stakeholders, but does have stronger IT stakeholder support. The Bad: If EA's job is always only to get at IT change (or IT's role in the enterprise), it will miss some business changes it could impact. Negatives also include still not linking IT change to business change directly and, essentially, the flaws of the other two definitions. If you're focused only on lowering IT costs, but you are addressing that challenge with people, process and information (in addition to technology) changes, then you have made IT's response more totalcost-oriented. However, you are still not architecting the larger problem the business. That is unfortunate, because the business spends approximately 95% of the operational spending in an organization, while IT only spends 5%. Gartner's 2009 actual and 2010 forecasts are found in "IT Metrics: IT Spending and Staffing Report, 2010." This IT architecture approach will not help address this larger spending's business drivers and future states. The other two approaches won't either. They won't identify cost savings in the business, nor why, perhaps, a drive for cost savings in the business may require increased spending in IT. The Ugly: Finally, this IT architecture approach also won't address business goals beyond cost savings and those objectives or business strategies always exist. EA must find them, and make sure that EA and IT work is not just aligned with the business spending and strategies, but directly synergistic with them to enable them to succeed. In Summary Although there are different meanings for the term "IT architecture," none of them are EA, and each has limitations that constrain EA value delivery. Although these IT architecture approaches may be useful in the early stages of an EA program, they should be seen as only steppingstones in a progression toward a more valuable EA approach. Thus, although these terms may be commonly, yet mistakenly, equated in discussions, EA teams must strive to distinguish IT architecture from EA, and then drive their enterprises toward the more-holistic EA approach. RECOMMENDED READING Some documents may not be available as part of your current Gartner subscription. Meaning No. 1: Meaning No. 2: "Gartner Clarifies the Definition of the Term 'Enterprise Architecture'" "Architecting the IT Organization: The Shoemaker's Children Have No Shoes" "Developing the Enterprise Solution Architecture: Architecting Solution Portfolios" Publication Date: 17 November 2010/ID Number: G00206910 Page 5 of 6

"Planning for Application Overhauls: Start From the Top With APM" "Application Portfolio Triage: TIME for APM" "Drive Application Overhaul Efforts With a Portfolio Approach" REGIONAL HEADQUARTERS Corporate Headquarters 56 Top Gallant Road Stamford, CT 06902-7700 U.S.A. +1 203 964 0096 European Headquarters Tamesis The Glanty Egham Surrey, TW20 9AW UNITED KINGDOM +44 1784 431611 Asia/Pacific Headquarters Gartner Australasia Pty. Ltd. Level 9, 141 Walker Street North Sydney New South Wales 2060 AUSTRALIA +61 2 9459 4600 Japan Headquarters Gartner Japan Ltd. Aobadai Hills, 6F 7-7, Aobadai, 4-chome Meguro-ku, Tokyo 153-0042 JAPAN +81 3 3481 3670 Latin America Headquarters Gartner do Brazil Av. das Nações Unidas, 12551 9 andar World Trade Center 04578-903 São Paulo SP BRAZIL +55 11 3443 1509 Publication Date: 17 November 2010/ID Number: G00206910 Page 6 of 6