You are on page 1of 17

Research

Publication Date: 4 September 2008 ID Number: G00160373

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-strategydriven 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 morespecific business areas, based on need. Do not underestimate the effort needed to involve key business (not IT) stakeholders in the work.

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.

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

Publication Date: 4 September 2008/ID Number: G00160373 2008 Gartner, Inc. and/or its Affiliates. All Rights Reserved.

Page 2 of 17

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
Publication Date: 4 September 2008/ID Number: G00160373 2008 Gartner, Inc. and/or its Affiliates. All Rights Reserved. Page 3 of 17

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

Manage and Communicate

1. Define and Scope

2. Organize

3. Future State

4. Current State

5. Gap Analysis

6. Migration Plan

7. Iterate and Refine

Govern
Ongoing throughout the entire process of supporting EBA, including manage, communicate and govern
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
Publication Date: 4 September 2008/ID Number: G00160373 2008 Gartner, Inc. and/or its Affiliates. All Rights Reserved. Page 4 of 17

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.

Publication Date: 4 September 2008/ID Number: G00160373 2008 Gartner, Inc. and/or its Affiliates. All Rights Reserved.

Page 5 of 17

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

Publication Date: 4 September 2008/ID Number: G00160373 2008 Gartner, Inc. and/or its Affiliates. All Rights Reserved.

Page 6 of 17

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.

Publication Date: 4 September 2008/ID Number: G00160373 2008 Gartner, Inc. and/or its Affiliates. All Rights Reserved.

Page 7 of 17

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)

Publication Date: 4 September 2008/ID Number: G00160373 2008 Gartner, Inc. and/or its Affiliates. All Rights Reserved.

Page 8 of 17

Figure 2. EBA Dimensions

Business Functions and Subfunctions


People

Financials

Organizations

Processes

Source: Gartner (September 2008)

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:

Publication Date: 4 September 2008/ID Number: G00160373 2008 Gartner, Inc. and/or its Affiliates. All Rights Reserved.

Page 9 of 17

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

Publication Date: 4 September 2008/ID Number: G00160373 2008 Gartner, Inc. and/or its Affiliates. All Rights Reserved.

Page 10 of 17

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

Roles Investment Services

Required Skills High

Required Impact High

Gaps Not automated

Required Incentive Bonus

Performance Metrics Revenue growth

Business Processes Consolidated customer and banking investment management

Organization Operations

Customer Service (Banking)

Medium

High

Too few

Bonus

Customer services Consolidated and market growth customer and banking investment management Market share growth Business analytics based on consolidated management Development integrated with consolidated management

Customer Service

Customer Marketing

High

High

Needs business focus

Bonus

Marketing

Web Developer

Medium

Medium

Fragmented

Bonus

Holistic customer experience

IT

Source: Gartner (September 2008)

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)

Publication Date: 4 September 2008/ID Number: G00160373 2008 Gartner, Inc. and/or its Affiliates. All Rights Reserved.

Page 11 of 17

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

Publication Date: 4 September 2008/ID Number: G00160373 2008 Gartner, Inc. and/or its Affiliates. All Rights Reserved.

Page 12 of 17

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
Commercial Banking Customer Service Commercial Banking Marketing and Sales Personal Banking Customer Service

Customer Payment Processing Customer Service Money Desk

Financial Planning Marketing and Sales Loan Products Customer Services Investments Customer Service Operations Management

Branch Services

Personal Banking Marketing and Sales

Loan Products Marketing and Sales MSIT

Investment Banking Investment Products Development

MIS/IT

Banking Products Development

Loan Products Development

Roles Investment Services Customer Service (Banking) Customer Marketing Web Developer

Business Skills High

Direct Impact

Gaps

Incentives

Metrics Service rate

Business Processes Customer and investment management Customer account management and core banking

Organization Operations

Medium Not automated

Medium

Low

Too few

Bonus

Service rate

Customer Service Marketing IT

High Medium

Medium Needs business focus Low Limited direction

Bonus

Market Business share growth analytics None Development processes

MIS/IT = management information system/IT


Source: Gartner (September 2008)

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
Publication Date: 4 September 2008/ID Number: G00160373 2008 Gartner, Inc. and/or its Affiliates. All Rights Reserved. Page 13 of 17

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.

Publication Date: 4 September 2008/ID Number: G00160373 2008 Gartner, Inc. and/or its Affiliates. All Rights Reserved.

Page 14 of 17

Figure 5. High-Level Migration Plan or Road Map

Current State: Fragmented customer relationship and service


Increase sales in more then one product by 15% Increase new product sales by 5% Decrease operating costs by 10% Increase sales in more then one product by 7% P1: Interim skills training and organizational changes Phase 1 Phase 2 P1: Conduct customer and internal focus group on customer service P2: Develop new unified customer services processes (banking, investments, loans) Integrate with related processes Competitive market Market/buyer trends Link to EIM effort

Future State (3-5): Increased revenue from current customers


P3: Integrate unified customer services processes with newly acquired systems P4: Release unified customer services system and integrated analytics

P2: Initiate total customer service training and hire new skills P1: Define new performance metrics and incentives

P2: New integrated customer service BU and integrate IT (central and BU) efforts and resources

Improve customer retention

P2: Invest in acquiring customer service agency and skills Phase 3

P3: Determine teleworker, security, hiring policies Phase 3

Phase 3

BU = business unit EIM = enterprise information management


Source: Gartner (September 2008)

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.

Publication Date: 4 September 2008/ID Number: G00160373 2008 Gartner, Inc. and/or its Affiliates. All Rights Reserved.

Page 15 of 17

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 currentand 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

Business Strategy Environmental Trends


Architecting Organize Architecture Effort Develop Requirements Develop Principles Develop Models

Future-State Architecture

Governing and Managing

Closing the Gap

Current-State Architecture
Documenting
Source: Gartner (September 2008)

Publication Date: 4 September 2008/ID Number: G00160373 2008 Gartner, Inc. and/or its Affiliates. All Rights Reserved.

Page 16 of 17

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 Naes Unidas, 12551 9 andarWorld Trade Center 04578-903So Paulo SP BRAZIL +55 11 3443 1509

Publication Date: 4 September 2008/ID Number: G00160373 2008 Gartner, Inc. and/or its Affiliates. All Rights Reserved.

Page 17 of 17

You might also like