Expand +



Putting the Enterprise Architect in Enterprise Architecture

by Sven Feurer

August 11, 2009

An enterprise architect’s job can be summarized in six phases. Learn what these phases are and the job responsibilities associated with each one.

Before you begin an enterprise architecture (EA) process, you need to have a strong business case based on enterprise principles that demonstrates your organization’s need for the future architecture. The business case should include information about how the target architecture can reduce operating costs, create more efficient business processes, and generate new revenue streams for the company. In addition, the business case should identify the risks and issues of not pursuing EA and deliver example evidence that shows where the lack of EA is already causing some problems for the organization.

Enterprise architects are responsible for designing and reengineering the EA. Their central task is to lead the EA process. They must also be able to transform their knowledge while performing at the speed of change, possess nearly countless skills, have a good grasp of different disciplines, and be able to use diverse tools. The primary responsibilities and skills of the enterprise architect can be broken down into the six main steps shown in “The Enterprise Architect’s Job.”

Adapted from: Federal Chief Information Officers Council. A Practical Guide to CIO Council - Federal Enterprise Architecture. February 2001, Version 1.0. (

Step 1: Initiate the EA Program

The first thing you need to do is to obtain broad management commitment and approval for the IT investment in EA. This process demands a strong awareness and commitment from senior executives and the support of business unit leaders. While the CIO of your company may be responsible for obtaining the executive buy-in and sponsorship, the enterprise architect primarily creates the plan to obtain support from the business units. It is important to articulate a clear architecture vision.

Step 2: Establish EA Governance

You need to establish a management structure and control mechanism to successfully develop the target-state architecture. You should do this at the outset to ensure that you maintain control while the later steps are established and executed. Effective governance helps to improve the performance of various roles and responsibilities due to an efficient decision-making process. With appropriate governance, everyone is clear on the part that they need to play and which standards they must meet.

EA governance consists of five key dimensions: organization and roles, processes, standards and templates, tools, and measures or key performance indicators (KPIs). The enterprise architect’s tasks in establishing EA governance include:

  • Defining principles for governance: Management and organization principles delineate the high-level rules and guidelines used to govern the EA process. These principles influence the EA’s implementation, use, and maintenance. Leading the creation of principles is a key responsibility of enterprise architects.

  • Embodying governance in the EA: To establish a governance structure for the EA, you should evaluate roles based on the size and complexity of your business and its architecture. In small and medium-size businesses (SMBs), one person may have several roles; in large companies, one person is more likely to have only one role. The frequency of change, as well as the volume and size of existing and planned change programs, is fundamental when determining the governance structure required.

  • Establishing the appropriate governance bodies: IT governance provides the leadership, processes, and management structures that ensure IT alignment with corporate strategies and objectives. In turn, the EA represents the foundation on which businesspeople and IT experts define and establish internal control mechanisms. Since the Sarbanes-Oxley Act, internal control reporting has become much more important. The following are some potential EA governance bodies:

EA Steering Committee (EASC): Primarily guides and oversees the program, approving high-level architecture and the entire EA. It should include senior managers and executives who can make decisions and make sure that those decisions are carried out.

Program Management Office (PMO): Manages, monitors, and controls the program, governing the development process and creating a roadmap showing how to achieve the EASC’s goals. The PMO wants to ensure the overall success of the EA program.

Design Authority (DA): Validates, reviews, and approves EA content and outcomes at a lower architectural level (e.g., any architecture models on a logical or implementation level). The DA identifies reusable components (e.g., enterprise services) and ensures consistency between sub-architectures. DA members include senior IT and business leaders.

EA Team: Consists of business, technology, information, and solution architects and support staff. The chief enterprise architect is typically the head of the team, which is responsible for all the activities in development, implementation, and maintenance.

Enterprise architects must ensure that the right management structures consist of the right roles and the right people. Furthermore, they need to track the progress of the architectural initiatives and their compliance with the EA’s principles. Enterprise architects must then ensure that the roles and processes are backed up with the correct standards and templates, the appropriate tools, and the right measures or KPIs.

Step 3: Define the Architecture Approach

The basic approach describes how the EA team intends to close the gap between the current state of the architecture and its desired future state. The enterprise architect’s tasks in this area are to:

  • Understand and use the enterprise’s operating model: The operating model shows how the organization aims to do business, how it delivers goods and services to customers, and how it plans to grow and act in the business environment. The idea is to assign each enterprise to a predefined business category such as diversification, coordination, replication, unification. Describing the responsibilities of the enterprise architect and the strategic positioning of the enterprise in an operating model is valuable input for the EA.

  • Encapsulate the EA in a core diagram: The process should start by creating a core diagram of the EA. This is a simple one-page diagram derived from the company’s operating model. It demonstrates the desired state of the EA — processes, information, and technical elements — and gives a high-level view of its building blocks. The core diagram enables both business and IT managers to discuss the target architecture and to communicate the vision throughout the organization. Different companies may address different architectural components in their core diagrams, but these diagrams should identify core business processes, shared data, integration technologies, and key customers. To design an EA core diagram, you would use an appropriate template for the specific operating model that you’re using.

  • Contribute to defining the use and scope of the EA: Determining the target-state architecture typically links to an organization’s strategic plan. The enterprise architect should help to define how to use the target-state architecture and how it will meet the business’s requirements. The enterprise architect also needs to keep the usage and purpose of the EA up to date, as they are likely to evolve over time.

As for scope, the EA views must span the entire organization from a broad high-level business perspective. You also need to consider the architecture’s vertical scope, which requires a top-down approach from each basic architectural viewpoint, ensuring that the business strategy drives the architecture and structures it in a consistent and hierarchical way.

  • Create a stakeholder map and a communication plan: The CIO and the enterprise architect should prepare a communication plan that demonstrates the benefits of the EA as well as its value to whom and how. The goal is to involve the stakeholders in the EA process, thereby gaining support for the initiative, and ensure that the EA is understood and used after the transition.

  • Evaluate and select an EA framework: Many well-established frameworks for both private and public sectors provide agreed-upon sets of constructs with which to communicate and express the building blocks of the EA. Such frameworks also typically provide a design process that incorporates best practices, therefore reducing the amount of time that’s required to create the EA’s target-state architecture.

One framework that should be mentioned in this context is The Open Group Architecture Framework (TOGAF), which provides a rich method to assist with the six steps discussed in this article. You may even decide to develop your own framework. If you do, always balance the costs, benefits, and risks of creating your own framework against those of adapting and tailoring an existing and proven framework.

For example, the SAP Enterprise Architecture Framework (SAP EAF) is an extension of TOGAF. Instead of creating a vendor-specific framework, SAP provides a set of extensions to support the effective adoption of packaged solutions in the service-oriented enterprise. (The most-often-used frameworks were discussed in my article “Building an Agile Enterprise Architecture,” SAP NetWeaver Magazine, Fall 2007.)

  • Develop an education program for the EA group: Developing a target-state architecture often brings in new technologies, innovative business processes, and novel ways of managing information across the organization, so the EA team will need to develop some enhanced skills. You should combine long-term educational programs with short, well-directed workshops, as well as establishing “mentor-mentee” relationships wherever possible.

The scope of the architecture extends the reach of the enterprise architect. Today, many companies have integrated business processes that go beyond their own organizational boundaries including key players in their business network (e.g., customers, suppliers, partners, communities, and so on). This kind of system affects the development of the EA because it describes the current and future state of the business processes, technology, and information. So it’s possible that enterprise architects may even interact and work with individuals and systems that are outside of their own companies.

When implementing new application patterns or frameworks, such as enterprise service-oriented architecture (enterprise SOA), even the application developer’s role changes. Technically skilled people in the IT department don’t create applications from scratch any more. Instead, they create enterprise services while business-process experts (BPXes) compose applications based on the existing services. The interaction between the application developers and the BPXes increasingly focuses on defining which services they want to create and in what order.

Step 4: Develop the EA

To develop the target-state EA, the enterprise architects must transform and expand the basic viewpoints — the business, application, data, and technology architectures — in a managed way and accomplish the following tasks:

  • Collect information: The enterprise architect needs to identify the existing architecture’s documentation and collect architectural blueprints for the target state. This is crucial for sequencing the steps. Put all the information compiled and collected in the EA Resource Base, which determines the relationships and dependencies of various elements. The resource base should also provide versioning functionality so you can trace architectural assets. If there isn’t enough information about the architecture, you may need to interview subject-matter experts (SMEs) and domain owners.

After collecting the information, the core team can begin to develop EA products and elements, identify the differences between products of the two architectures (gap analysis), and lead the migration toward the target EA. A clear definition of what these products are, and the information relationships that are required to construct them is needed if the EA team is going to plan this work effectively.

  • Define the “to-be” state: Moving the organization from where it is to where it wants to be requires a thought process documented in the company’s strategic plan. The enterprise architect needs to summarize the long-range business goals and objectives in the company’s mission and vision statements, and offer overall direction and strategic management. A strategic plan alone typically provides poor direction for developing an IT infrastructure and business-process capabilities. However, together with the operating model, it can drive a top-down sequence to be followed for EA development.

The core diagram encapsulates the organization’s operating model. It provides a high-level view of customers, business processes, technology, and data, and illustrates their interdependencies. The “big picture” diagram is an optimal starting point from which to derive conceptual models and tools for each architectural viewpoint. (Note: Whether you define the “as-is” state or the “to-be” state first depends on the organization’s issues, requirements, and vision.)

  • Document the architecture’s “as-is” state: An important logical step is to describe and document the current state of the architecture. Describing the “as-is” architecture enables you to create a baseline to compare against the target architecture, discover the drawbacks of the current architecture, and provide reference materials. Documentation doesn’t need to be perfect — architectural artifacts will be out of date the day after you pass and publish them — it just needs to be good enough to let enterprise architects understand and communicate the current and future EA. Even when documentation is incomplete and fragmentary, it is often much better than trying to proceed without it.

  • Review architecture products: The EA team is responsible for reviewing the architecture artifacts that describe the target state (and maybe the current state) of the enterprise; however, their competency may be insufficient to assess detailed architectural models. The EA stakeholder map developed in step three will be invaluable at this point. Before passing the architecture’s products to the SMEs, senior members of the EA team should review them. You can repeat this review procedure until the changes from the last review are included and the architectural products are updated.

When the products have a specific level of maturity, you can conduct the SME review. This step defines the completeness and accuracy of the specific EA element. Participants are typically SMEs (business-process experts, industry experts, and so on), the enterprise architect, members of the EA team, domain owners, and quality and risk managers. It is important to understand which viewpoints — and which products — each stakeholder can contribute to, and needs to review at this point; rarely will any one role or person see the whole architecture model.

At this time, the risk manager can effectively make a contribution to assess business and technical risks and may point out early cost and scheduling risks for implementing the architecture.

For validation and final product approval, you may pass these risks on to a more specialized Technical Design Authority (TDA), and then to the EASC. Upon receiving the approval of these governance bodies, you should update and publish the revised product’s documentation.

  • Analyze the gaps between current- and future-state EA: Gap analysis is typically accomplished after the product review. EA deliverables from the review step are now compared to their current- and future-state specifications. The gap identified between the two represents the extent of the change initiatives. If all of the current architecture satisfies the requirements of the target architecture, then, in theory, there’s no reason to start updating the project.

To identify and analyze gaps, you need the following key inputs, among others: description of the target-state architecture, documentation of the current-state architecture, requirements of enterprise solutions, principles of the conceptual architecture, usage of the appropriate tools and techniques, and recommendations for developing and prioritizing.

  • Plan the migration path for closing the gaps: Based on a sequencing plan that defines the step-by-step process for moving from the current architecture to the envisioned architecture, you should plan the migration to consider the resources required (such as budget, people, and time), the degree of change the organization can cope with at any one time, and the technical interdependencies and intermediate stages required.

For instance, changing a business process is typically formulated within an entire program, including multiple projects. An individual project manager leads each project, which represents a logical division of work. A project focuses on implementing one specific change initiative (or set of initiatives).

  • Approve and publish the overall architecture: To “get a green light” for the overall EA requires the approval of the EASC, the CIO, the enterprise architect, executives, and the CEO. However, the approval process may differ from organization to organization. Before you promote using the enhanced EA, you need to share information about the architecture. This is typically realized in electronic read-only formats; however, groups should get detailed information concerning only a specific subset of the EA for security reasons.

Historically, the focus of the EA has been on the technical architecture, which was reflected in the technical skill set of enterprise architects. Today, business strategy explicitly drives EA, and therefore, technology expertise is not as essential as it once was. New and expanded architecture viewpoints (such as business or enterprise SOA) require advanced skills from the architecture team. Enterprise architects must understand the company’s operating model to translate it into architectural requirements.

Architecture frameworks provide more detail and guidance on what needs to happen to develop the EA if required. The phases of TOGAF and the SAP EAF extensions provide a comprehensive approach where the EA consists of packaged applications and enterprise services. Depending on the scope and nature of EA, a tailorable approach is available, as are templates/extensions for different approaches.

Step 5: Use the EA

The EA is used to implement and enhance the company’s foundation for business execution. It establishes a connection between the architectural group and the implementation group. The goal here is to govern the overall change, procurement, implementation, and deployment processes.

  • Promoting the usage of the EA: Enterprise architects need to proactively encourage organizational groups to use the architecture. As the new architecture encapsulates the organization’s strategic plans, it should become a central tool that supports daily business operations.

The new architecture represents a strategic information asset base that supports decision-making and communicating these decisions across the organization. Promoting and applying this new asset can be a technical and cultural challenge. Enterprise architects must also ensure that the organization uses the appropriate development tools and techniques to build solutions in compliance with the architecture. The final success of EA efforts depends on political and cultural factors that exist within your own company.

  • Guiding strategic technology procurement using EA: The enterprise architects should work closely with procurement to ensure that the new contracts and products being procured meet the expectations of the roadmap that has been constructed.

  • Implement projects by ensuring EA compliance: An integral part of this step is implementing the defined architecture. In times of crisis and transforming business networks, when companies need to change rapidly to survive, it can make sense to implement massive projects. However, it may be too risky and expensive to take a “Big Bang” approach. Instead, you may want to perform one project at a time, implementing only one specific piece of the defined architecture in each project.

The enterprise architect and the EA team advise project and program leaders on how to develop business solutions. They want to ensure that the projects formulated and prioritized in the sequencing plan are truly funded and properly implemented, but they usually don’t become deeply involved in the details of each single implementation project.

Before the final decision is made, the architecture team assesses the alignment of project proposals to the EA based on business alignment, business case solution, sequencing plan, and technical compliance. If project proposals are not aligned to the EA, the architecture team will also support implementation teams to bring these projects into compliance. The enterprise architect’s efforts need to be linked to the IT results of the implemented projects.

For instance, enterprise architects can show the positive impact of the EA because it reduces the amount of time needed to build composite applications on top of enterprise SOA, reduces implementation risk by developing a clearer understanding of what is to be built before it is built, and lowers the costs of projects. Therefore, the EA team should create those measures and KPIs that will demonstrate how the architecture is going to achieve its IT and business goals.

Step 6: Maintain the EA

The EA should keep up with ongoing changes in the enterprise’s business functions and technology. Consequently, each component of the EA needs to be maintained and updated. The task here is to reassess the EA periodically and ensure that EA products remain current. The EA is dynamic. It aims to reflect the enterprise’s current vision, ensuring that the current state reflects the real IT infrastructure, the target state properly reflects the business vision of the organization, and the sequencing plan is up to date and considers the priorities and available resources of the current business environment.

The mechanism for change and configuration management should ideally be put in place as part of step two. Otherwise, the EA team runs the risk of delivering an out-of-date architecture at the end of step four. This mechanism should align to existing change control and approval processes within the organization, where they exist.

Drivers for changing the EA can be technical, such as new technology reports, technology withdrawals, technical-only or business-only initiatives — perhaps an unexpected event in a business process — business innovations, or strategic changes.

The high-level technology and business drivers that will potentially transform the organization determine a proactive approach for maintaining the architecture. Then, the EA team needs to plan for the evolution of any new business functions and technologies.

Ongoing Enterprise Change

Maintaining and reassessing the EA is important because it reflects the enterprise’s ongoing changes. Once the EA no longer reflects the company’s business strategy, you need to change it. Before launching the next wave of innovation, the organization should cash in on the lessons it has learned.

The company culture needs to allow an atmosphere of trust that makes continuous improvement everyone’s concern. You can compile a list of lessons learned from business owners, development, investment-planning, and management teams, as well as from the EA team. Communicating the lessons learned to the stakeholders of the EA is the job of the EA team. You may also want to share these lessons with external organizations and consultants.


1. Federal Chief Information Officers Council. A Practical Guide to CIO Council - Federal Enterprise Architecture. February 2001, Version 1.0.

2. Feurer, Sven. “Building an Agile Enterprise Architecture,” SAP NetWeaver Magazine, Fall 2007, page 70.

3. Woods, D., and T. Mattern. Enterprise SOA — Designing IT for Business Innovation. O’Reilly Media. May 16, 2006.

4. Ross, J.W., P. Weill, and D.C. Robertson. Enterprise Architecture as a Strategy. Harvard Busness School Press. August 1, 2006.

5. The Open Group: The Open Group Architecture Framework. URL: December 19, 2003.

Sven Feurer is an SAP NetWeaver industry advisor at SAP Deutschland AG & Co. KG. This article was taken, in part, from Feurer’s Master Thesis in Business Information Systems at the University of Applied Science in Karlsrühe, Germany. You can reach him at

An email has been sent to:

More from SAPinsider


Please log in to post a comment.

No comments have been submitted on this article. Be the first to comment!