How to Develop Enterprise Bu 160373

ResearchPublication Date: 4 September 2008 ID Number: G00160373

© 2008 Gartner, Inc. and/or its Affiliates. All Rights Reserved. Reproduction and distribution of this publication in any form without prior written permission is forbidden. The information contained herein has been obtained from sources believed to be reliable. Gartner disclaims all warranties as to the accuracy, completeness or adequacy of such information. Although Gartner's research may discuss legal issues related to the information technology business, Gartner does not provide legal advice or services and its research should not be construed or used as such. Gartner shall have no liability for errors, omissions or inadequacies in the information contained herein or for interpretations thereof. The opinions expressed herein are subject to change without notice.

How to Develop Enterprise Business Architecture Betsy Burton, Bruce Robertson

Enterprise architecture (EA) teams are struggling to develop enterprise business architecture (EBA). Here, we outline a seven-step iterative EBA process leveraging Gartner's EA framework and process model.

Key Findings

• EBA work is becoming increasingly critical to EA (and enterprise) success, driven by business demand and IT alignment failures.

• EA teams, however, struggle with getting EBA efforts under way; they are unsure how to do EBA work, and who should do it.

• Many EBA efforts that do get started begin with unrealistic scope expectations.

• EBA work is not just about processes; it must define multiple aspects important to business viewpoint stakeholders, including people, financials, organization and process dimensions.

Recommendations

• Follow the same iterative EA development process for all the architecture viewpoints, including EBA.

• Determine enterprise demand for EBA work, and use this to properly scope and prioritize the overall EA effort, including EBA development.

• EBA, as well as the other viewpoints, is informed by the business context, which provides the common context.

• Develop principles and models within EBA and its dimensions (people, organization, process and financials).

• Prioritize and iterate time-segmented efforts as needed to match business-strategy-driven change requirements.

• Start by taking a high-level, broad approach to EBA to gain a holistic understanding of the entire enterprise and its environment. In subsequent iterations, go deeper into more-specific business areas, based on need.

• Do not underestimate the effort needed to involve key business (not IT) stakeholders in the work.

Publication Date: 4 September 2008/ID Number: G00160373 Page 2 of 17

© 2008 Gartner, Inc. and/or its Affiliates. All Rights Reserved.

TABLE OF CONTENTS

Analysis ............................................................................................................................................. 3 1.0 Background on Gartner Definition of EBA...................................................................... 3 2.0 Develop EA (and Thus EBA) by Iterating Seven Steps ................................................. 3

2.1 Ongoing Efforts.................................................................................................. 4 2.1.1 Manage.............................................................................................. 4 2.1.2 Communicate .................................................................................... 4 2.1.3 Govern............................................................................................... 5

3.0 Step 1: Define and Scope............................................................................................... 5 4.0 Step 2: Organize............................................................................................................. 6 5.0 Step 3: Future State ....................................................................................................... 8

5.1 Best Practice: Focus on the Lines Between the Boxes................................... 10 6.0 Step 4: Current State.................................................................................................... 12 7.0 Step 5: Gap Analysis .................................................................................................... 13 8.0 Step 6: Migration Plan .................................................................................................. 14 9.0 Step 7: Iterate and Refine............................................................................................. 16 10.0 Appendix..................................................................................................................... 16

10.1 Gartner Enterprise Architecture Framework ................................................. 16 10.2 Doing EBA With Other EA Frameworks........................................................ 17

LIST OF FIGURES

Figure 1. EA Development Process in Seven Iterative Steps ........................................................... 4 Figure 2. EBA Dimensions ................................................................................................................ 9 Figure 3. Leverage Models to Identify Critical Intersections and Friction Points ............................ 11 Figure 4. Leverage Current-State Models to Identify Critical Intersections and Friction Points...... 13 Figure 5. High-Level Migration Plan or Road Map .......................................................................... 15 Figure 6. Gartner Enterprise Architecture Framework .................................................................... 16



ANALYSIS

EA teams report increasing interest in EBA. The most common reasons are: 1) a recognition that EA processes and methodologies can be used to help the business make better decisions and deliver strategic planning, 2) a desire to "align" or "integrate" IT and business initiatives and investments, and 3) a need to demonstrate business impact and value from EA efforts. The challenge, however, is that many organizations are struggling to define what EBA is, as well as determine its scope (see "Findings From the Open Group EA Conference: No Enterprise Business Architecture Definition"). In addition, many struggle with figuring out how to do EBA work (see "Government Enterprise Architectures Face Numerous Risks"). In organizations with hugely diverse approaches to EBA, some pursue EBA by defining business requirements, some by modeling business processes, and others by documenting business capabilities. While these approaches may help to create a better understanding of the business and provide information for improved decision making, all of these approaches are somewhat limited, as they don't approach EBA in a holistic way.

How can organizations develop a high-impact, valuable business architecture? We recommend that EA teams leverage a clearly defined, practical EA framework and process, with a specific focus on EBA dimensions such as people, organization, process and financials. Then, use the results from this iterative and requirements-driven EA development process — including EA artifacts, lessons learned, findings and social network creation — to help business leaders make better decisions about moving the business forward, and assist IT in better responding to and supporting this business evolution. This EBA work will in turn require iterative development work in other EA framework areas, such as information, technology and solution architecture.

Here, we describe how to use Gartner's EA process and EA framework to develop EBA. Many EA programs use an EA framework — all of which have a common focus on business architecture, including at least process, if not other dimensions such as people, organization and financial aspects. (For more on developing EBA with other frameworks, see Appendix.)

1.0 Background on Gartner Definition of EBA Gartner's enterprise architecture process (see "Gartner Enterprise Architecture Process: Evolution 2005") describes — through a set of requirements, principles and models — the future state, current state and migration plan guidance necessary to flexibly evolve and optimize for EBA, specifically the business dimensions (people, process, organization, financial) to achieve effective enterprise change (see "Understand Enterprise Business Architecture to Realize Your Future State").

2.0 Develop EA (and Thus EBA) by Iterating Seven Steps For illustrative purposes, Gartner's EA process model (see Appendix) can be represented as a series of seven steps that can be followed during the support of any architecture viewpoint (see Figure 1), along with ongoing management, governance and communications efforts. This must be done iteratively: Architects must continue to evolve in depth and breadth, based on changes in the business context (such as new business strategies). This doesn't mean only redoing all seven steps over again in order; it also means going back one or more steps at certain points to adjust and recalibrate as needed. Defining any architecture viewpoint must be an iterative improvement process, not a one-time project to "get it all architected once and for all."

These seven EA development "steps" are activities that may overlap and blend. One step can start before another step has ended — we do not advocate a strict waterfall approach. Thus, we represent the steps with dotted lines and the entire process with color gradients. Architects and



EA teams may find themselves performing tasks from different steps at the same time based on their organizations' needs, resources and time.

While this EA development method is usable for any EA framework area, we'll apply it here to EBA. As we describe each step in the EA development process, we'll focus on the EBA-specific issues and artifacts. Furthermore, we will use the Bank XYZ prototype enterprise created by Gartner for illustrative purposes as an example throughout this report (see "Toolkit: Bank XYZ Business Strategy").

Figure 1. EA Development Process in Seven Iterative Steps

Ongoing throughout the entire process of supporting EBA, including manage, communicate and govern

Manage and Communicate

Govern

1.Define

and Scope

2.Organize

3.Future State

4.Current State

5.Gap

Analysis

6.Migration

Plan

7.Iterate

and Refine

Ongoing throughout the entire process of supporting EBA, including manage, communicate and govern

Manage and Communicate

Govern

1.Define

and Scope

2.Organize

3.Future State

4.Current State

5.Gap

Analysis

6.Migration

Plan

7.Iterate

and Refine

1.Define

and Scope

2.Organize

3.Future State

4.Current State

5.Gap

Analysis

6.Migration

Plan

7.Iterate

and Refine

Source: Gartner (September 2008)

2.1 Ongoing Efforts Before we discuss the seven separate steps, it is important to note that several ongoing efforts must take place throughout the entire process of supporting EBA, including manage and communicate, and govern (see the lines pointing into the steps in Figure 1).

2.1.1 Manage

Each EBA development team — there may be more than one if volume dictates — needs to be managed for normal projectlike goals based on an iterative phase (based on time and objectives); timelines must be created, working sessions organized, deliverables created, and so on. Often, the chief enterprise architect is in charge of managing these activities, but management tasks may be delegated to EBA-specific roles. The EBA leader must ensure that the planned work gets done. (For more on leader and team member roles, see "Toolkit: Best Practices for Planning People and Responsibilities for EA Project Teams.")

2.1.2 Communicate

Communication is often overlooked, but is critical to success (see "The EA Staffing Conundrum"). It is always a challenge (see "Top EA Challenges Are People and Business Issues"). Within each of the steps, the EBA team needs to contact management — as well as business and IT leaders — to inform them about what they are doing and to promote how it will benefit the business (see "Q&A: Architects Must Advocate, Evangelize and Educate"). An ongoing part of communication is



organizational change management regarding concerns of perceived and/or real changes (see "Successful EA Change Management Requires Five Key Elements").

Managing and communicating require defining key stakeholders — those to involve in the process (see the Organize step) as well as those that need to be informed throughout. With EBA work, specifically, this means working with business customers and constituencies. This may not be the forte of an IT-centric EA team, but without working with business stakeholders, EBA can't be effective or successful.

2.1.3 Govern

Governing EA efforts is an ongoing activity within EA (and thus EBA specifically) that deals with two general issues. First, governance must ensure that key decision makers do not ignore or even just generally support EA, but that they specifically endorse and approve EA development efforts (that is, ratifying EA future-state standards and guidelines, as well as approving initial migration plan projects). EBA efforts must support, reflect, advance and integrate with the organization's overall EA efforts, as well as with the other EA viewpoints — enterprise information architecture (EIA), enterprise solution architecture (ESA) and enterprise technical architecture (ETA).

Second, governance must ensure that EA requirements, principles, models and other recommendations are adhered to when migrating toward endorsed future states (EA assurance for projects as they implement change).

As we have mentioned, during the entire EA process the EA team needs to ensure that stakeholders understand what the team is doing, and how the work will deliver business value. This effort should be strengthened by defining key metrics (see "Focus Enterprise Architecture Metrics on Business Value") that are evaluated as the effort evolves from one step to another. The EA team must either directly or indirectly ensure that promised business value is actually achieved, which is the only justification for the planning activity of EA.

For EBA work, these governing and metrics activities must be done directly with business constituencies. Getting business leaders to commit to business metrics, even as aspirations or goals, can be tricky. Getting business leaders to participate in governance is equally demanding. Yet, without these foundational activities, no EBA development work will prove effective.

3.0 Step 1: Define and Scope First, ensure that there is a common agreement and understanding of what EBA is, the potential value (based on business goals and objectives) of supporting the EBA development process and the value of leveraging the outcomes (both physical artifacts and soft impacts). This should be done within the scope of an overall EA effort. However, regardless of an understanding of the value and impact of EA overall, the EBA team needs to ensure that EBA (as a specific effort) is understood and supported.

Second, define the scope of initial iterations. While the ultimate long-term goal of EA (and, more specifically, EBA) is to understand and articulate the entire business as a whole, the only way that this can be accomplished is through an integrative process of progressing from one iterative scoped area to another. Additionally, critical constraints impact the scope. For example, an EA team may be resource-constrained because of few EA team resources with EBA skills, or there may be insufficient business unit support from one or more business units to include them in the scope. Refined objectives must exist that are doable, addressing business issues and team capabilities.



Take, for example, Bank XYZ. The business strategy is to "develop deeper, more-profitable relationships with customers by offering a one-stop resource for all of their financial services —personal as well as business" — and potentially to make some international acquisitions to help increase customer services on an international scale. In this example, initial EBA efforts might focus on cross-organizational domain key customer touchpoints, such as customer services (banking, loans, financial planning), customer analytics reporting, marketing, customer access points (Web site, branches, ATMs, direct sales and so on), human capital (talent) management and development.

To get stated with EBA, the EA team should:

• Establish a clear definition of EBA, including general goals and objectives for EBA work.

• Create a statement of scope for this specific iteration, as well as a statement of what is out of scope.

• Develop a statement of relevant assumptions (such as the availability of business subject matter experts [SMEs]).

• Identify the overall business sponsor as well as a business sponsor for each iteration (they may or may not be the same).

• Determine the relationship between the EBA activity and the other viewpoint activities, dependencies and relationships (see Section 2.1.3 on governance).

• Develop a statement regarding the relationship to overall EA processes.

• Identify critical constraints (compliance, the extended enterprise ecosystem, organizational culture and politics, and industry and regional requirements).

These high-level statements and goals should be agreed to by key stakeholders, including senior management and relevant business managers, as well as by their staff and relevant IT management. Garnering this support can be politically and culturally complex. The more the iteration's scoping details are grounded in defined business goals (that is, public statements) and put in specific business terms, the better. We find that many organizations that start EBA (and EA in general) lack a clear goal or scope (see "Findings: EA Should Be Driven by Business Objectives"). Do not ignore this step, as it is critical for ensuring that your efforts have direction as well as management support.

4.0 Step 2: Organize Next, identify and organize the team to do the iteration's work. In general, for any EA area, this means detailing key lead and member roles, and securing their participation officially from their constituency leadership (see "Toolkit: Best Practices for Planning People and Responsibilities for EA Project Teams"). Furthermore, collect the necessary (as well as available) supporting information, models and artifacts.

Selecting the right EBA team leaders is critical. Ideally, the person chosen to lead EBA efforts should be from the business and be focused full-time on leading the EBA effort. This ensures that EBA efforts are fully concentrated on the business, brings clear business knowledge directly to the effort and adds credibility within the business. We have seen successful cases where the EBA leader reports into the business or the EA team, depending on the broad perception of the value and impact of the EA team on business-related issues. If the EBA leader is not on the EA core team, someone in the EA organization should be assigned, full-time, to support the EBA leader and his or her efforts. This bridge can ensure that the EBA project is aligned with the



overall EA framework, and that the EBA work is also integrated into the ETA, EIA and ESA efforts.

Larger organizations may present the opportunity to define three EBA teams. The first would be a small core EBA team of people from different businesses with diverse work experiences (including business process analyst, HR/training and finance) within the scope areas. Regardless of formal reporting structures, the members of the core EBA team should allocate a large percentage of their time to this effort, with the team meeting on a regular basis. The members of this team could rotate based on the evolution of the EBA.

The second team would be a larger virtual extended EBA team/community that would help provide support, advice and reviews of the EBA efforts. In addition, members of this broader team would be asked to take on specific tasks within their domain expertise for a short period of time. This virtual team or community would meet on a less frequent basis (once a month), and consist of people from diverse businesses and with varied skills. Defining this team will help to augment the work of the core team, and to help increase knowledge, support and evangelizing of EBA efforts across business and IT.

Finally, specific EBA iteration or project teams can be assembled to do specialized EBA work, with results reported back to the core EBA team and the extended EBA team kept informed. Such EBA project teams would often be composed of members of the core EBA team or extended teams, but could include other SMEs as needed. While the core and extended EBA teams must stay together a long period of time across multiple iterations of work, each of these project teams must have a short life span of only one project's effort. Because most EBA project iterations should be completed within approximately two to three months, these teams will need to focus on the job at hand and quickly create a specific deliverable per the iteration's scope. If the result of such time-boxed activity (this whole process as an iteration) takes much longer, it is probably best to stop and rethink goals and iteration scope. Taking too much time on one iteration can lead to an "ivory tower syndrome" as well as the idea that the whole enterprise is being modeled. Instead, keep any single EBA work iteration short, and just do more iterations if you're not done.

Any EBA team — core, extended or project — should have:

• A defined charter based on goals and objectives (see "Toolkit: Bank XYZ EA Team Charter and Plan")

• Clearly defined roles and responsibilities (see "Toolkit: Best Practices for Planning People and Responsibilities for EA Project Teams")

In addition to organizing the people who will support EBA efforts, it is also key to discover/collect which EA and business documents may exist. If your organization has already made investments in EA or has an EA effort under way, processes and artifacts should be in place for leverage, in order to increase consistency and save time, including business context materials (such as a common requirements vision [CRV], business strategy, market analysis and business scenarios), current- and future-state anchor models, overall EA principles, EA models for ETA, EIA, and ESA, and existing charters and role definitions. In addition, the EBA team should determine which existing relationships and social networks could be leveraged. In addition, the EBA team should work to discover and leverage business analysis and scenario planning, process models, HR skill inventory, financial models, and so on. The goal at this stage is only to collect what artifacts already exist, not to develop or create new artifacts. If additional current-state data is needed, it will be collected in that step or during future-state or current-state projects that implement changes based on this planning.



5.0 Step 3: Future State The third step is to identify a future-state EA vision by defining requirements, principles and models that describe the long-term targets for change and how to move toward that target state successfully.

The first future-state task is to define the context for EBA change, understanding how the business context applies to your EBA iteration. You must understand current business and technology trends that impact your business and its extended business ecosystem, and further understand how the business is reacting to these trends at the business strategy level. This input is needed for any area of EA work, but it is indispensable for EBA work. The business context, which includes the CRV view, provides a common context for informing all the EA viewpoints of what is going on in the business — it is the keystone to the business rationale behind all EA guidance. It supplies the context within which the requirements for change in the EBA can be defined. With these requirements, further narrowing of the scope of EBA work overall and for any EBA iteration specifically can be defined. If this work has not already been done (for example, by a business strategy group or other EA teams), the EBA team should start by doing as much of this work as it can by focusing on what they need.

The second future-state task is to identify or define the business domains to focus on (or between) as the high-level service or functional or capability model of the enterprise. This conceptual view will include the anchor model for most EBA work (which is generally considered part of the business context), the one model to which all other work will be mapped, and the first model that non-EBA work should be mapped to. Start by taking a high-level and broad approach to gain a holistic understanding of the entire enterprise and its environment. In subsequent iterations, go deeper into more-specific business areas, based on need.

For the Bank XYZ example, this includes the "organizational key customer touchpoints." This means understanding the:

• Cross-organizational processes (no more than three to five)

• Critical roles and the competences of the people in these roles

• Organizations (actual and loosely coupled social networks)

• Major financial factors (such as budgets and investments)

The third future-state task is to clarify the business architecture dimensions (people, organization, process, financials [see Figure 2]) of the selected business domains to the required depth. Commonly, this means understanding and defining the requirements, principles and models for the future state of:

• Process: Cross-organizational processes (no more than three to five)

• People: Critical roles and the competencies of the people in these roles

• Organization: Relevant organizations (actual and loosely coupled social networks)

• Finance: Major financial factors (such as budgets and investments)



Figure 2. EBA Dimensions

Business Functions and Subfunctions

Processes

People

Organizations

Financials

Business Functions and Subfunctions

ProcessesProcesses

PeoplePeople

OrganizationsOrganizations

FinancialsFinancials


The purpose of calling out the EBA dimensions is to identify them as the areas — such as a business lever — that may be adjusted, augmented or changed to evolve the business — its functions and subfunctions — toward a future state. Like the other EA viewpoints, the EBA should result in the creation of artifacts, including requirements, principles and models, which help business and IT people move their business toward a future state.

As with EA overall, the process of defining EBA future-state requirements, principles and models must be iterative. One way to describe the iterations of future-state work is the leveraging of a simple three-level model composed of conceptual, logical and implementation-level work. For process, the conceptual level is the overall single-slide view of the process, the logical level is activity, and the implementation level is task. This is another opportunity to consider the iterative nature of the other viewpoints (such as EIA, ETA and ESA). The iterations provide the opportunity to reconcile the work occurring in these other viewpoints to identify improvement opportunities.

Always start with conceptual-level work. Input may be much deeper (process diagrams from system implementations), but the first iteration's output should be primarily conceptual. By conceptual, think short — a few slides or just one. In subsequent iterations, the EBA project team can go into more details and deeper. Doing conceptual work only can be extremely valuable, even if you never go deeper in many areas in later iterations. Don't always insist that logical and implementation-level iterations need to be done. In our experience, this detailed work is often done by project teams, with the guidance and support of EBA teams (including integrating content from the information, technology and solution viewpoints).

Within the future state, we recommend focus on three different aspects of future-state description: requirements, principles and models. First, we strongly urge EBA teams to focus on the requirements for change to any of the EBA — this is the demand for change — don't model things that don't need change. Then, define principles representing enterprise intent that further constrains what you'll model. Finally, model the future state directly:



• Requirements: Leverage the EA CRV results for business context, and extend it with (more) requirements for change in EBA. If the organization has not developed a CRV, it must perform CRV work at the business context level, and then define at least high-level EBA requirements. In our CRV work, we call these business change requirements (BCRs). Refined EBA requirements should also be brought back to architects working on ETA, EIA and ESA efforts to determine if and how these requirements impact their efforts, and vice versa. Moreover, this requirements work should be validated by key stakeholders before any actual future-state modeling work is begun.

• Principles: The EBA teams should also create initial EBA principles based on future state and overall EA principles (if they exist). For example, in the case of Bank XYZ, they might define an EBA principle as, "any new investments in businesses models, processes or applications must focus specifically on ensuring consistency of critical (end-to-end) customer processes across business functions and business units." In the short and long term, EBA principles should be used to help constrain long-term, changeable process and organizational design, as well as help drive human capital and financial decisions (such as investments and budgets). As with requirements, these principles should be validated by key stakeholders before undertaking significant modeling work.

• Models: EBA team should model (again, at a high level) critical business dimensions (people, organization, financials and process) based on future-state requirements and principles. The EBA team should work closely with other SMEs or domain experts within the broader virtual EBA team to leverage their work and knowledge. These domain experts may include human capital managers, financial analysts, business operation managers, business functional analysts, business process analysts and process architects (see "Role Definition and Organizational Structure: Business Process Improvement"), IT and solutions architects, and project managers focused on solutions. As EBA efforts evolve and become more mature, the core EBA team should be able to step back and support these resources, but enabling the domain experts to take the lead on EA project teams while still executing within the scope and framework of the overall EBA work.

EBA teams must not model to infinite detail. Instead, by taking a high-level but broad approach to EBA to gain a holistic understanding of the enterprise and its environment, the structure is defined, within which additional iteration work can proceed. In these subsequent iterations, architects can go deeper into subfunctions, roles, processes, financial details and organizational structures (conceptual, logical and implementation). Taking a high-level approach increases the agility of the EBA efforts, as the EBA team can go into greater levels of detail on whatever aspect supports the most-critical business imperatives (such as customer touchpoints). The deeper the work, the less directly the EBA team does the modeling, and the more it is a reviewing function for specific iteration work. Also, as time passes, interactions with other viewpoints improve, creating the opportunity for affinity analysis to highlight cross-viewpoint opportunities that are one of the major benefits and differentiators of an EA approach.

5.1 Best Practice: Focus on the Lines Between the Boxes A key goal of the modeling process is to identify critical intersections and friction points between processes, organizational issues, people requirements and financials — for example, considering a conceptual process model of customer service within Bank XYZ, and a conceptual model of the people/roles that support customer service (see Figure 3).



Figure 3. Leverage Models to Identify Critical Intersections and Friction Points

RolesRequired Skills

Required Impact Gaps

Required Incentive

Performance Metrics

Business Processes Organization

Investment Services

High High Not automated

Bonus Revenue growth Consolidated customer and banking investment management

Operations

Customer Service (Banking)

Medium High Too few Bonus Customer services and market growth

Consolidated customer and banking investment management

Customer Service

Customer Marketing

High High Needs business focus

Bonus Market share growth

Business analyticsbased on

consolidated management

Marketing

Web Developer

Medium Medium Fragmented Bonus Holistic customer experience

Development integrated with consolidated management

IT



Required Incentive

Performance Metrics


Investment Services



Operations




Customer Service

Customer Marketing





Marketing

Web Developer



IT



Required Incentive

Performance Metrics


Investment Services



Operations




Customer Service

Customer Marketing





Marketing

Web Developer



IT


By understanding the links between these processes and people, EBA teams can begin to understand and address gaps (or pain points) and opportunities. They can, for example:

• Refine the future state of the business architecture based on the current modeling iteration

• Identify areas (process, organization and people) for automation and skill augmentation

• Identify benefits and risks associated with change (mergers, acquisitions and divestitures)



• Identify the effects on related processes and organizational units, and describe interdependencies

• Position the future-state process in the business process portfolio

• Refine the business case and state the costs/benefits, as well as possible risks

The analysis of EBA content should not be restricted to merely mapping inside a single EBA dimension, or just between EBA dimensions alone. EBA content also should be mapped outside EBA itself — to other EA viewpoints, to the strategies (via the CRV), to the project portfolio, and of course to actual implemented solutions (see "Compare Portfolio Views by Visualizing the Matrix" and "Using the Application Partition Model to Plan Your Portfolio's Evolution").

At reasonable points during this future-state work, work products — including requirements, principles and models — should be reviewed and disseminated among key stakeholders as well as the extended EBA team. Moreover, if additional EBA resources are needed, this communication should discuss those needs and actions.

6.0 Step 4: Current State The fourth step in this process is to baseline the current state. The goal is to understand the state of your current business dimensions within the scope of your EA and EBA efforts. Many organizations start documenting the current state but unfortunately never get to the development of the future state. The current state takes too long. To address this, the scope and level of detail of current-state documentation should reflect those of the future state, as the objective of this task is to prepare for the next step — identifying the gaps between where you are today and where you want to be. Another key is to leverage the domain leaders or SMEs to provide just enough current-state information (of any kind necessary, including process models, organization structures, competency assessments, training plans and financial budgets) for the focus of a single iteration. The EBA team should help guide and facilitate ongoing collection at a high level, but will need only to consume high-level content (see "Make the Current-State Architecture 'Business as Usual'"). Primary current-state efforts should include:

• Current-state anchor model: As the with the future state, current-state anchor models should focus on a high level with the necessary details to be created/gathered during further iterations. The first effort must be to identify the EBA scope within the current anchor document or, if one does not exist, create a high-level current-state anchor model for EBA.

• Models: As with the future state, EBA teams should start to model critical business dimensions (people, organization, financials and process) at a high level, based on what was modeled in the future state. The most significant difference between the future state and current state is that current-state efforts should be performed by domain experts (human capital management, financial analysts, business operation managers, business functional analysts, business process analysts and process architects), with the guidance and advice of the core EBA team.

As with defining the future-state models, a key goal of the current-state modeling process is identifying critical intersections and friction points between processes, organizational issues, people requirements and financials. These pain points may suggest where future-state changes are necessary, or confirm the initial scoping efforts that found existing approaches to be ineffective.

Consider a conceptual process model of customer service within Bank XYZ, and a conceptual model of the people/roles that support customer service (see Figure 4). By understanding the



links between these business capabilities and the people resources, EBA teams can begin to understand and address gaps and opportunities.

Figure 4. Leverage Current-State Models to Identify Critical Intersections and Friction Points

RolesBusiness Skills

Direct Impact Gaps Incentives Metrics


Investment Services

High Medium Not automated Service rate Customer and investment management

Operations


Medium Low Too few Bonus Service rate Customer account management and core banking

Customer Service

Customer Marketing

High Medium Needs business focus


Business analytics

Marketing

Web Developer

Medium Low Limited direction

None Development processes

IT

CommercialBanking

CustomerService Customer

FinancialPlanningMarketingand Sales

LoanProductsCustomerServices

PaymentProcessingCustomerService

InvestmentsCustomerService

CommercialBanking

Marketingand Sales

BranchServices

MoneyDesk

OperationsManagement

InvestmentProducts

Development

PersonalBanking

CustomerService

PersonalBanking

Marketingand Sales

LoanProductsMarketingand Sales

MSIT

InvestmentBanking

MIS/ITBankingProducts

DevelopmentLoan

ProductsDevelopment

MIS/IT = management information system/IT

RolesBusiness Skills

Direct Impact Gaps Incentives Metrics


Investment Services

High Medium Not automated Service rate Customer and investment management

Operations


Medium Low Too few Bonus Service rate Customer account management and core banking

Customer Service

Customer Marketing

High Medium Needs business focus


Business analytics

Marketing

Web Developer

Medium Low Limited direction

None Development processes

IT

CommercialBanking

CustomerService Customer

FinancialPlanningMarketingand Sales

LoanProductsCustomerServices

PaymentProcessingCustomerService

InvestmentsCustomerService

CommercialBanking

Marketingand Sales

BranchServices

MoneyDesk

OperationsManagement

InvestmentProducts

Development

PersonalBanking

CustomerService

PersonalBanking

Marketingand Sales

LoanProductsMarketingand Sales

MSIT

InvestmentBanking

MIS/ITBankingProducts

DevelopmentLoan

ProductsDevelopment

MIS/IT = management information system/IT


Current-state models should be reviewed and communicated with key stakeholders as well as the extended EBA team. Also, if additional EBA resources are needed, this communication should be discussing those needs and actions.

7.0 Step 5: Gap Analysis By the time the EBA team reaches this step, the gaps between the current state and future state should be fairly clear. The goal during this step is to clearly document these gaps.

Our Bank XYZ example shows a gap between the fragmented way that customer relationship management (CRM) is supported today (applications and information) versus the vision of a cohesive CRM and banking system of the future.

This gap must be understood by stakeholders as well, so additional communication activities may be needed during this step. The EBA team needs to bring this back to the overall EA team and



integrate their plans. After this review, adjustments may need to be made to the overall EBA, as additional gaps may be uncovered (such as new application training and organizational changes). Often, identifying process changes may lead to further solution plans — and getting to the future state of the EBA will require changing not just EBA but many other areas, including key solutions that automate those processes. While the EBA change can be represented by itself, it is more effective to connect the EBA change to realistic, additional changes elsewhere, as EBA activity often will result in further work in other EA areas (such as ESA, ETA and EIA).

8.0 Step 6: Migration Plan In this step, the EBA team must outline the high-level projects or initiatives that will be undertaken to close the gaps between the current- and future-state architectures. In general, EA road maps can serve as valuable planning tools to help the organization define a clear set of proposed change projects that will move the enterprise from current state to future state (see "Use Road Maps to Chart a Course to the Future-State Architecture"). The gap analysis component of the EA process identifies gaps in all the viewpoints, with an eye toward creating a consolidated view of the steps that must be taken for the enterprise to evolve from the current state to the future state. However, organizations may find it helpful to develop viewpoint-specific road maps to assist in the detailed effort that each viewpoint team must facilitate. In these cases, EBA road maps should focus on business impacts and business dimensions, as well as the relationship with other EA efforts.

In our Bank XYZ example (see Figure 5), a road map would include process changes (blue), people changes (red), financial changes (green) and organizational changes (orange) from EBA along with other changes to create a holistic set of recommendations in a holistic migration plan. While this example is very simplistic and high-level, it is worth noting that we have documented the following key change initiatives in this chart: 1) the current-state to future-state goals and time frames, 2) the high-level performance metrics (far left), 3) a series of specific projects within each EBA dimension, and 4) links to other ETA and EIA efforts.



Figure 5. High-Level Migration Plan or Road Map

Current State:

Fragmented customer relationship and service

Future State (3-5):

Increased revenue from current customers

P1: Interim skills training and

organizational changes

P2: New integrated customer

service BU and integrate IT (central and

BU) efforts and resources

P3: Determine teleworker,

security, hiring policies

P1: Define new performance metrics and incentives

P2: Invest in acquiring customer

service agency and skills

Phase 1 Phase 3

• Competitive market

• Market/buyer trends

Phase 2 Phase 3 Phase 3

• Integrate with related processes

• Link to EIM effortDecrease operating costs by

10%

Improve customer retention

Increase sales in more then one product

by 7%

Increase new product sales

by 5%


by 15%

P2: Initiate total customer service training and hire new

skills

P1: Conduct customer and internal focus

group on customer service

P2: Develop new unified customer

services processes (banking,

investments, loans)

P3: Integrate unified customer services

processes with newly acquired

systems

P4: Release unified customer services system and integrated

analytics

BU = business unit

EIM = enterprise information management

Current State:

Fragmented customer relationship and service

Future State (3-5):

Increased revenue from current customers

P1: Interim skills training and

organizational changes

P2: New integrated customer

service BU and integrate IT (central and

BU) efforts and resources

P3: Determine teleworker,

security, hiring policies

P1: Define new performance metrics and incentives

P2: Invest in acquiring customer

service agency and skills

Phase 1 Phase 3

• Competitive market

• Market/buyer trends

Phase 2 Phase 3 Phase 3

• Integrate with related processes

• Link to EIM effortDecrease operating costs by

10%

Improve customer retention


by 7%

Increase new product sales

by 5%


by 15%

P2: Initiate total customer service training and hire new

skills

P1: Conduct customer and internal focus

group on customer service

P2: Develop new unified customer

services processes (banking,

investments, loans)

P3: Integrate unified customer services

processes with newly acquired

systems

P4: Release unified customer services system and integrated

analytics

BU = business unit

EIM = enterprise information management


The goal of this diagram is to help focus EBA members and have them keep the highest-level goals in mind as they proceed through the phases and daily work of implementing the EA. Following this effort, EBA teams should:

• Recommend changes to EBA dimensions (people, process, organization and financials)

• Determine changes to related ETA, EIA and ESA architectures

• Identify adjustment decisions (organization changes, redefined projects and project launches)

• Identify investment decisions (skills, people and technology)

• Identify EBA dimensions that could be affected by changing internal and external factors (compliance, culture and politics, industry, and region) — develop scenarios for critical areas.



These diagrams and recommendations should be reviewed with key stakeholders as well as the extended EBA team. The EBA team may also consider working with internal PR resources (see "Q&A: Architects Must Advocate, Evangelize and Educate"), HR, senior management and change management resources to define an internal and external communication plan.

9.0 Step 7: Iterate and Refine While it is important to define a scope and focus for a specific iteration, supporting EBA is not a project but an ongoing and evolving component of EA. As the organization continues to evolve toward a future state, the EBA team should consider deeper iterations as needed, particularly strengthening the dependencies on other architecture viewpoints; doing so will allow for better affinity analysis and better impact analysis, leading to greater agility. In addition, business, market, economic, social and environmental changes may impact EBA efforts. Therefore, principles, requirements and models should be regularly revisited and revised based on current- and future-state vision.

10.0 Appendix 10.1 Gartner Enterprise Architecture Framework In Gartner's EA framework (see "Gartner Enterprise Architecture Framework: Evolution 2005"), an EA has a minimum of three viewpoints: a business viewpoint, an information viewpoint and a technology viewpoint. These viewpoints are derived from the business context (see Figure 6) and should demonstrate clear traceability of architectural decisions to the elements of the business strategy.

Figure 6. Gartner Enterprise Architecture Framework

Environmental Trends

Business Strategy

Closing the Gap

Future-State Architecture

Current-State Architecture

Governing and Managing

Org

aniz

e Ar

chite

ctur

e Ef

fort

DevelopRequirements

DevelopPrinciples

DevelopModels

Architecting

Documenting


Business Strategy


Business Strategy

Closing the Gap

Future-State Architecture

Current-State Architecture

Governing and Managing

Org

aniz

e Ar

chite

ctur

e Ef

fort

DevelopRequirements

DevelopPrinciples

DevelopModels

Architecting

Documenting




10.2 Doing EBA With Other EA Frameworks We have several case studies of organizations using other frameworks, such as:

• Zachman (see "Toolkit Case Study: Business Architecture Delivers a Departmentwide Approach to Identity Fraud")

• The National Association of State Chief Information Officers (see "The NASCIO Toolkit Can Guide Government Enterprise Architecture Development")

• Public Service Reference Model (see "The Canadian Government's Style of Enterprise Business Architecture")

Regardless of which EA framework you choose to follow (see "Enterprise Architecture Frameworks: Just Choose One and Use It"), EBA must be an integral part of the overall EA effort, including a direct link to and from technology, information and solution architecture. While EBA may consider different dimensions and deliver unique artifacts or models, organizations should follow a common high-level framework and process for defining EBA, as is done when defining with other architecture viewpoints.

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

Documents

How to Develop Enterprise Bu 160373