Myth-Busting: What Enterprise Architecture Is Not November 3-7 ...

More documents

Recommendations

Info

Myth-Busting: What Enterprise Architecture Is Not EA Provides the Foundation for Better Implementation Decisions EA provides the foundational principles, guidelines, standards and constraints that enable implementation teams to make better decisions. EA is not implementation. This presentation, including any supporting materials, is owned by Gartner, Inc. and/or its affiliates and is for the sole use of the intended Gartner audience or other authorized recipients. This presentation may contain information that is confidential, proprietary or otherwise legally protected, and it may not be further copied, distributed or publicly displayed without the express written permission of Gartner, Inc. or its affiliates. © 2008 Gartner, Inc. and/or its affiliates. All rights reserved. AC Water Media Key Issue: What EA is not. And, how does EA relate to other IT and business initiatives? Enterprise architects do not dictate implementation details for the entire organization or for specific practice areas. Organizationwide departments, competency centers, project teams and steering groups have deeper knowledge of the specific requirements, processes, people and technology within a defined practice area. The representations of the business, processes, information, people and technology that are created by the EA effort should be used to guide and support the planning and implementation effort across the organization. Architects should work closely and in collaboration with critical teams. Their joint efforts should be focused on leveraging artifacts to apply guidelines to a specific practice area and implementation, while enabling the implementation teams to lead with respect to their specific skills. Action Item: Enterprise architects must actively engage with implementation teams and focus architecture efforts not on the creation of yet another standard, but rather on identifying the areas in which the business strategy demands reuse and interoperability. Betsy Burton ESC20_666, 11/08, AE Page 13
Myth-Busting: What Enterprise Architecture Is Not Finding: Many EA teams become trapped in a vicious cycle of creating and managing current-state architecture documentation — so much so that they never effectively focus on the strategic requirements future-state planning. EA Is Much More Than Just ETA This presentation, including any supporting materials, is owned by Gartner, Inc. and/or its affiliates and is for the sole use of the intended Gartner audience or other authorized recipients. This presentation may contain information that is confidential, proprietary or otherwise legally protected, and it may not be further copied, distributed or publicly displayed without the express written permission of Gartner, Inc. or its affiliates. © 2008 Gartner, Inc. and/or its affiliates. All rights reserved. A common EA pitfall is excessive documentation of the current-state architecture. Best practices for creating currentstate architecture to document: 1. Remain focused on EA scope 2. Develop in the context of the future-state architecture 3. Take an iterative approach EA is not a technology or application inventory. Key Issue: What EA is not. And, how does EA relate to other IT and business initiatives? Current-state inventory (as a component of the architecture repository) is updated with each EA iteration through gap analysis, impact assessment, migration planning and implementation planning. The initial focus of current-state documentation must be to place basic information about solution attributes in the context of the solution taxonomy (for example, business organizational units cross-referenced to critical business information flows) developed from the futurestate exercise. This taxonomy provides the context to place current solutions in the taxonomy for future analysis. Many EA teams take this explanation to mean that they must inventory every process, data element, application, service and technology that exists in the organization and take complete responsibility for maintaining that inventory. This interpretation can lead to never-ending, current-state documentation, with limited time and resources to focus on the future state. In fact, we recently spoke with a midsize government organization that hired a consultant to "do" its EA, and the output of this work was an 85-page inventory of technologies, applications and their connecting points. Although a technology and application inventory may be helpful when defining a current state, this is not an EA. EA is a much broader process that directly reflects the business vision and strategy, as well as the people, processes, organization, information and technology (including applications) that are critical to the business strategy. The current-state architecture should be business as usual for every good manager. Managers should have an accurate picture of the current state of the domain they manage, and the EA team should be able to leverage this information. EA provides actionable, prescriptive guidance for project-level decision making, consistent with executing a transition plan toward a described future-state architecture that aligns with the business strategy. Betsy Burton ESC20_666, 11/08, AE Page 14
Page 1 and 2: Myth-Busting: What Enterprise Archi
Page 13: Myth-Busting: What Enterprise Archi
Page 21: Myth-Busting: What Enterprise Archi

Myth-Busting: What Enterprise Architecture Is Not November 3-7 ...

Create successful ePaper yourself

Delete template?

Save as template?