insight

Enterprise Architecture (EA) can be either a cohesive force that binds technology and business operations in support of strategic goals or a misunderstood initiative that undermines the credibility of the entire IT organization. The difference comes in successfully applying the seven essential elements of enterprise architecture—proven principles that should be a part of any EA undertaking.

7 Essential Elements of EAFollow this roadmap to engage your business, manage complexity, and govern the implementation of your architecture

by David C. Baker and Michael Janiszewski

Figure 1

Mention enterprise architecture (EA) to many CEOs or CIOs, and you often get a fairly standard set of responses:

“EA costs too much.” “EA simply isn’t a practical exercise for us.” “There doesn’t seem to be much benefit.” “ Our stakeholders wouldn’t use our EA if we had one.”

Several factors keep many senior executives from embracing the idea of EA. One reason is that the management of information is not a well-understood science. Even at 50 years of age, EA still is in its infancy, and practitioners have yet to develop common definitions, standards, processes, or tools for managing EA. Another reason is the organizational and cultural barriers that block the acceptance of EA. EA is viewed as an ivory-tower playground for technicians or academics, so organizations miss the message that it’s the glue that ensures the alignment of business and technology within the enterprise. This misconception often arises from the pains many organizations experience when embarking on an EA effort:

• Frameworks are often not readily actionable (that is, they lack architectural

management concepts that are clearly relevant to architecture delivery).

• Results of the EA effort are often difficult to communicate over the range of the organization’s various constituencies (for example, CIOs, business staff, and technical architects).

• Enterprise linkages and interactions are not well understood or documented, making it difficult to use EA as a business enabler.

Those problems are serious, but not insurmountable. In fact, we’ve seen numerous companies extract real value from EA initiatives. The chances of implementing a successful EA effort are substantially increased by managing the seven essential elements of EA that occur in stages throughout the architecture lifecycle (see Figure 1).

Managing these elements helps ensure the organization embraces EA and can answer the important questions, from “Why are we building an EA?” to “How will we measure and control the end result?” These seven elements are essential in delivering an EA that provides real business value. It is a

representation that is traceable, actionable, and communicable.

In this article, we’ll describe the seven elements that provide a roadmap for making your EA practice an asset to your organization. We’ll discuss them within the context of the architecture lifecycle as shown in Figure 1. Executed successfully, these elements empower your architecture organization to engage the business, manage the complexity inherent in your information enterprise, and govern the implementation activities that follow your architecture effort.

The seven elements are:

• Set the stage with guiding principles.

• Manage complexity with blueprints.

• Organize for architecture success.

• Integrate through architecture processes.

• Keep on track with architecture governance.

• Use tools to model, analyze, and communicate your architecture.

• Measure architecture success with metrics.

2

For more information contact:

Dave Baker, Partner & Chief Architect david.baker@diamondconsultants.com

3

Figure 2

Incomprehensible technical models and arcane diagrams make it impossible to launch a meaningful architecture discussion with business stakeholders. That approach will simply collapse under the weight of engaging the business to help create such detailed models. A better way to introduce a business audience to EA is to begin collaborating with business stakeholders to develop a set of guiding principles, our first element.

Guiding Principles are a collection of definitive statements that provide guidance on how the organization should conduct certain business and technical functions (see Figure 2). They serve as filters for decision making, eliminating possible solutions that are not consistent with the organization’s goals and objectives. Good guiding principles are unlikely to change within a short-term period, and are clear, concise, and supported by rationale and implications developed with business and technical staff working together. Consensus building and alignment are beneficial by-products of conducting a series of structured guiding-principle discussions. In all cases, the results serve as guideposts for the upcoming decision making

and are a necessary tool to unite business and technology constituencies.

The second element, blueprinting, is the art of documenting the EA models and standards. As in civil architecture, a good set of blueprints helps manage the complexity associated with ongoing repairs and updates to intricate systems. However, unlike civil architecture, EA does not have a rigorous blueprinting methodology. You can use frameworks such as the Zachman Framework, Steven Spewak’s Enterprise Architecture Planning, and the Federal Enterprise Architecture Framework that identify blueprint contents, but do not address how to go about developing the blueprints.

Start by engaging the business stakeholders in the development of business architecture blueprints. Architects work closely with the business to document the mission, vision, goals, objectives, and business capabilities required to enable the business strategy. This strategic business architecture work is led by the enterprise architect, bringing an engineering rigor to the process. The result is a set of linked architecture elements clearly

Engaging the Business

4

showing which capabilities are required to deliver the business goals and objectives. Furthermore, business metrics are identified and associated with each objective, providing a model that is used to periodically measure the progress toward attaining the business vision.

The business architecture also includes an operational business architecture that defines the key processes, stakeholders, and interactions that are needed to implement the business strategy. Current state and future state versions of the operational business architecture allow architects to assess the impact a new strategy would have on current operations.

Next, engage IT to develop the systems architecture. The systems architecture describes, in a platform-independent way, the high-level applications, information, infrastructure, and interfaces that enable the strategic and operational business architectures. These models are useful for linking technical elements (such as applications, information, infrastructure, and interfaces) to the business capabilities. This linkage provides a language for discussing technology with the business—both in terms of impact (What happens to my technology when I change a business goal?) as well as in terms of cost (What does it cost to implement a particular business strategy or capability?).

The business and systems architectures are typically created and updated during regular IT planning cycles. You use these architectures to identify the IT initiatives (and determine the funding) needed to implement the business vision—expressed in terms of the business capabilities, which by now has become the common language that binds business and IT.

The final level of blueprints is the technical architecture, which describes the physical implementation of the applications, information, infrastructure, and interfaces. The technical architecture identifies the specific products, protocols, and wiring schemas that guide the implementation.

5

An enterprise architect requires a unique blend of skills. At various times he or she needs to employ the characteristics of an artist, a guru, a coach, and a spy. As an artist, an enterprise architect needs to be creative by looking beyond the “right” answers to uncover new solutions to old problems. The enterprise architect also needs to be a guru—someone who understands some topics in depth, but can address a breadth of business and technical topics.

As a coach, the enterprise architect must bridge both business and technology, be able to find points of influence in both camps, and ensure that technology stays off the critical path. Finally, as a spy, the enterprise architect must be able to work across the enterprise, see patterns across disparate business needs, and define solutions that satisfy multiple business needs. Enterprise architects grow from within the technical architecture ranks, learning how to be artists, gurus, coaches, and spies as they work their way from being technical specialists, through application or infrastructure architects, eventually to enterprise architects.

The third essential element of EA is organizing for architecture success. Architect career paths should be nurtured within an appropriate organizational structure. An effective architecture organization ensures appropriate ownership of the architecture and correct sponsorship of the work, and provides an efficient structure for solving problems. The organizational form typically depends on an organization’s level of architecture maturity. Organizations just starting out on the EA path typically have architects spread across various application and infrastructure departments, providing technical architecture services (products, protocols, wiring diagrams).

The first step is to centralize all those architects into an organization delivering

EA services—business, systems, and technical architectures. This organizational structure establishes a foundation to give rise to EA capabilities, and allows architect involvement in enterprise planning activities such as business strategy development and investment management. As the EA organization matures, and individual architect skills develop, the organization can swing back to a more distributed structure. However, this new structure should maintain a small central group of enterprise architects to oversee the activities of the distributed virtual community of architects. This virtual architecture organization works because of the EA awareness and skills gained by the individual architects.

Understanding the need for true architectural processes is our fourth essential element. Architecture processes document how architecture design is performed and how architecture is communicated and implemented within an organization. They provide the groundwork for leveraging the architecture organization to get work done in a consistent and effective manner. Sample processes can include blueprinting, integration planning, and project architecture checkpoints and signoff (see “Controlling the Effort,” page 7).

Architecture processes should be centrally maintained in an easily communicable format and accessible location. Clear, traceable processes provide tremendous benefit to the organization, reducing time to project completion and setting better expectations around what it means for an architecture effort to be complete. Developing architecture processes is essential to enforcing the EA big picture, to create architecture that concretely provides benefit to the organization.

Physical creation of an EA requires a lot of doing. One of the biggest challenges

Organizing for Success

6

an organization faces with regard to its EA is writing it down. When assumptions and tacit knowledge exist around an EA, its capabilities as a business enabler are severely diminished. Therefore, it is critical that the EA is well-documented, current, and available for use by stakeholders.

The fifth element is that you should use tools to model, analyze, and communicate your architecture. Fortunately, the market for EA tools has been progressively evolving to meet these challenges and to help the organization do architecture. Capturing EA requires an engineer’s rigor with the associated representations. Many EA tools now possess the capability not only to record and analyze disparate information but also to import that information for storage in a central repository.

These tools also provide good versioning capabilities and recently have had an enhanced focus on EA presentation—ameliorating some of the need for taking EA elements and reformatting them to make them more consumable. With a solid EA documented, stored, and updated within an EA tool, business users should find straightforward answers to questions such as “What happens to my business if I turn off that server right there?” or “If we decide to expand our marketing efforts into new territories, what information assets can be leveraged to reduce risk and cost while enabling greater impact and speed to market?” An EA tool allows the stakeholder to work with the EA in an understandable format and to realize real benefits from the effort to create the EA.

It is important to remember, however, that although tools are an essential element of EA, content is important as well. Tools are a means of storing and working with the artifacts created while working through the other key elements of the EA. To record EA information in a tool requires careful analysis and understanding of the relationships between the key EA elements. To do this, the organization requires a level of maturity regarding its development and use of architecture before implementing an EA tool and repository. Using an EA tool without this maturity provides minimal benefit to the organization.

7

With an EA effort in full swing, it is critical to maintain alignment between program execution and the organization’s EA. This means ensuring that work tracks are accomplishing what the EA describes and that feedback loops exist for raising architecture issues, updating the EA, and measuring EA program success. Our sixth and seventh essential EA elements, keeping on track with architecture governance and measuring architecture success with metrics, address this need.

Separate from traditional program management office responsibilities of driving and measuring project progress, we believe that architectural governance is a key element to ensuring that the EA vision is maintained across the enterprise. Architectural governance refers to how an organization makes decisions, sets priorities, allocates resources, designates accountability, and manages its architectural processes. The governance body is responsible for reviewing products produced from EA efforts to ensure that they meet the goals of the EA (for example, designs meet the to-be depiction from the enterprise blueprints).

The governance body is also the forum for raising and resolving issues through established escalation processes, and for providing inputs and updates to the EA. The governance organization should consist of a mix of subject matter experts and senior leadership capable of representing the organization from both business and technical areas, and have the authority to make architectural decisions.

Architecture governance ensures organizational alignment and a place for the EA to remain a living asset. It is also an ideal place to implement our final key element—metrics. Implementing and using architecture metrics

proactively provides the basis for demonstrating the value of your EA. Metrics associated with blueprints provide an ideal opportunity to ensure program success. Good architectural metrics provide insight into aspects of the architecture that have meaning to the business.

For example, you can measure the EA for the percentage of strategic capabilities that have been realized (capabilities that are described in the blueprints) and percentage of existing enterprise architectural assets reused by a program. Architectural metrics, used in conjunction with governance, inform strategic planning and portfolio management programs, giving quantification to the return on architecture assets achieved by the organization. They are critical to articulating the benefits of your EA effort and provide the information necessary to help your EA organization provide guidance to the enterprise.

Once in place, the seven elements establish EA as a valuable asset for your organization. Engaging business resources in guiding principles and blueprinting activities ensures that the downstream implementation work delivers the business vision. Building a strong EA organization and integrating the EA processes in IT management activities allows the architecture to guide investment and implementation activity.

The payoff comes from the clear linkage of business vision and technical architecture. That linkage allows EA to govern implementation activities and provides the metrics to communicate progress toward realization of the business goals and objectives. The seven elements are best when executed in concert, but do not let that daunt you. Pick a subset of the business strategy and get started with guiding principles or blueprints. You will learn much and be on the road to achieving EA maturity.

Controlling the Effort

Suite 3000 John Hancock Center875 North Michigan Ave. Chicago, IL 60611T (312) 255 5000 F (312) 255 6000www.diamondconsultants.com

.

Chicago Hartford London Mumbai NewnYork Washington, D.C.

© 2006 Diamond Management & Technology Consultants, Inc. All rights reserved.

Diamond (NASDAQ: DTPI) is a premier global management consulting firm that helps leading organizations develop and implement growth strategies, improve operations, and capitalize on technology. Mobilizing multidisciplinary teams from our highly skilled strategy, technology, and operations professionals worldwide, Diamond works collaboratively with clients, unleashing the power within their own organizations to achieve sustainable business advantage. Diamond is headquartered in Chicago, with offices in Washington, D.C., New York, Hartford, London and Mumbai. To learn more, visit www.diamondconsultants.com.

David Baker is a partner and the chief architect at Diamond. As an EA knowledge leader, Dave develops business and technical blueprints that govern strategic initiatives. Dave’s specialties include identifying leading-edge technologies, guiding innovation projects, defining strategies for applying technology, and leading architecture assessment and implementation efforts. Dave has over 24 years of design, development, instructional and managerial experience in key technologies and architectures. His experience includes mobile application architectures, service-oriented architectures, enterprise application integration, business-to-business and business-to-consumer e-commerce, community sites and content aggregation. He also has experience in customer service technologies, wireless operator enterprises, communication networks and relational databases and is a certified Federal Enterprise Architect.

Michael Janiszewski is a consultant with Diamond. He is experienced in technology-related strategy creation, EA, architecture assessment, implementation and education, architecture governance, program planning, and execution. Michael has worked for clients in both the public and private sector. Michael is a certified Federal Enterprise Architect.

About the Firm

About the Authors