Professional Documents
Culture Documents
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.)
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
2. Organize
3. Future State
4. Current State
5. Gap Analysis
6. Migration Plan
Govern
Ongoing throughout the entire process of supporting EBA, including manage, communicate and govern
Source: Gartner (September 2008)
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.
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.
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
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
Financials
Organizations
Processes
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.
Publication Date: 4 September 2008/ID Number: G00160373 2008 Gartner, Inc. and/or its Affiliates. All Rights Reserved.
Page 10 of 17
Organization Operations
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
Bonus
Marketing
Web Developer
Medium
Medium
Fragmented
Bonus
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)
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.
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
Financial Planning Marketing and Sales Loan Products Customer Services Investments Customer Service Operations Management
Branch Services
MIS/IT
Roles Investment Services Customer Service (Banking) Customer Marketing Web Developer
Direct Impact
Gaps
Incentives
Business Processes Customer and investment management Customer account management and core banking
Organization Operations
Medium
Low
Too few
Bonus
Service rate
High Medium
Bonus
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.
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).
Publication Date: 4 September 2008/ID Number: G00160373 2008 Gartner, Inc. and/or its Affiliates. All Rights Reserved.
Page 14 of 17
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
Phase 3
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.
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
Future-State Architecture
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
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