• No results found

IT Architecture Is Not Enterprise Architecture

N/A
N/A
Protected

Academic year: 2021

Share "IT Architecture Is Not Enterprise Architecture"

Copied!
6
0
0

Loading.... (view fulltext now)

Full text

(1)

Research

Publication Date: 17 November 2010 ID Number: G00206910

© 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 orga nization 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

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.

(2)

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

EA IT Architecture

Meaning No. 1: IT Architecture = ETA Only

Enterprise Technical Architecture (ETA)

Yes Yes

Enterprise Information Architecture (EIA)

Yes No

Enterprise Business Architecture (EBA)

(3)

EA IT Architecture

Enterprise Solution Architecture (ESA)

Yes No

Meaning No. 2: IT Architecture = ETA + Some ESA (APM Only)

Business Context Yes No

Application Portfolio Management (APM)

Yes Sometimes

Solution or Project Architecture No (but individual solutions are

included in the current state of the EA, and EA teams work with distinct SA teams)

Yes (but only from a technical/ETA perspective)

Meaning No. 3: IT Architecture = EA for IT BU Only

Scope/Focus Enterprise (can focus at single BU

or enterprise level)

IT only (but EBA view includes Information Technology Infrastructure Library [ITIL] and others)

Source: Gartner (November 2010)

Meaning No. 1: IT Architecture = ETA Only

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 IT-centric 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).

(4)

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

(5)

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 total-cost-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:

"Gartner Clarifies the Definition of the Term 'Enterprise Architecture'"

"Architecting the IT Organization: The Shoemaker's Children Have No Shoes" Meaning No. 2:

(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

References

Related documents

There were significant differences among locations for the contents of total Gly and the A3 and basic subunits; however, planting dates were not significantly different for total

Whether a large bulky upload, or a slow trickle over a long time, FlowTraq makes it easy to track how much data leaves your network and where it’s going?. FlowTraq provides

Although places have to compete intensely for tourists, foreign direct investments, and exports (Balakrishnan, 2009) to link culture, identity, and image (Pedeliento and Kavaratzis,

This regulation prescribes Headquarters, Department of the Army (HQDA) authority, policy, and responsibilities for the operation of the Army Military Affiliate Radio System (MARS)

With football the highest participation team sport among men in England, this paper examines the potential public health benefit of offering STI testing to men in this setting

ISSN: 0269-9052 (Print) 1362-301X (Online) Journal homepage: http://www.tandfonline.com/loi/ibij20 Intranasal Nerve Growth Factor administration improves cerebral functions in a

• Pending Case Tracking • Licensing & Appointments • Workflow/ Compliance Management • Commission Tracking • Flexible Reporting • CRM •

The landscape impacts of the December 2013 surge included the notching of soft rock cliffs and clif fline retreat; erosion of coastal dunes; augmentation or re-activation of