Task 1 - BCM Method_Guide v5e Final

The World Bank Official Use Only

of 86 <Task 1 - BCM Method_Guide v5e Final.doc > Business Capability Method

Ed BUSINESS CAPABILITY MODELING

TASK 1 DELIVERABLE – METHOD GUIDE Ver. <5 – Including Heat Map Chapter>

Project ID: <8003150>

Staff Name Role Date

Prepared By Richard Hudson Christine Etue

Bob Etris

Grant Thornton Team V1 Grant Thornton Team V2 Grant Thornton Team V3 Grant Thornton Team V4 Grant Thornton Team V5

May 6, 2008 May 13, 2008 May 27, 2008 June 30, 2008

Reviewed By Denise Bedford Business Architecture Team May 9 May 17

Susan Dubas Business Architecture Team May 9 Irma Mentzer EA Office May 9 Denisa Popescu EA Office May 9 Virginia Yee EA Office May 9 Luisita Guanlao World Bank - Project Manager May 9

May 19 Version 4 Approved By

Luisita Guanlao World Bank - Project Manager

June 2

Version 5 Approved By

Luisita Guanlao World Bank - Project Manager

Change Control

Version Staff Name Change Description Date Version 4 Christine Etue Completed items in Appendix

2 based upon outputs from Tasks 2 & 4

June 26

Added Sections 4.2.1, 4.2.2, 4.3

June 26

Version 5 Richard Hudson Bob Etris

Include chapter on Heat Maps as part of Extension Task A. Apply updates to rest of document to conform to new chapter (e.g. Appendix 1 – Business Capability Model Templates)

Sept 29



Information Solutions Group The World Bank

Table of Contents

1 INTRODUCTION .............................................................................................. 3 2 METHOD OVERVIEW ....................................................................................... 5 3 APPROACH .................................................................................................... 12 4 TECHNIQUES AND NOTATION ....................................................................... 19 5 BUSINESS CAPABILITY HEAT MAPS .............................................................. 31 6 ROLES AND RESPONSIBILITIES .................................................................... 58 7 METHOD AND MODEL GOVERNANCE ............................................................. 61 8 CHANGE CONFIGURATION PROCESS ............................................................. 63 9 GLOSSARY OF TERMS .................................................................................... 66 10 APPENDIX 1 – BUSINESS CAPABILITY MODEL TEMPLATES ........................... 69 11 APPENDIX 2 – MODEL REFERENCE DOCUMENTS ........................................... 72

Electronically distributed, uncontrolled if printed.



1 Introduction

1.1 Background

This deliverable is primarily focused on describing the approach to business capability modelling. A business capability describes what a business does - its external visible behavior and the expected level of performance (versus how it does it – its internal behavior). Business capabilities have “customers” and they are expected to perform at a certain level in terms of delivery of a “product” to that customer (such as units per period of time, or with a specified level of quality). The business capability describes “what” is done and the expected, or contracted, level to which it is done. Inside the capability are the specifics of how that capability is implemented at a given point of time with respect to people, procedural steps, technology and so forth. In building the capability model we focus on the external aspects. How they are achieved is not important to the definition of the capability. The emphasis is on describing the external, observable and measurable behavior of the business.

1.2 Architecture Benefits

A goal of the Information Systems Group (ISG) is the adoption of an approach that supports greater engagement with business stakeholders to define, implement and manage business rules and policies for their respective business applications. By having a better understanding of the business and by developing a fully elaborated business architecture, ISG will be able to re-orient the current vertical, application-oriented architecture to one that is better aligned to business needs; is more streamlined; will extend the use of open standards; will facilitate the redeployment of platforms to support changing business needs; and, will reduce overall integration costs. The main benefits of having an overall architecture are to: • Increase the agility with which IT can respond to changes in the business • Increase the value of IT spend by prioritizing against overall business needs and driving

cost efficiencies • Ensure cross-functional alignment • Increase re-use of applications and services • Increase the capacity to sustain current operations • Eliminate redundancy • Better understand the impact of change • Be better prepared and less reactive to change The advantages of the business capability approach within the overall architecture are that the model: • Focuses on commonly understood, externally visible attributes as opposed to the details

of internal flows; • Speaks to business owners in their own language; • Is a more rigorous approach to the definition of business requirements and their

eventual technical implementation; and, • Aims to maximize the life expectancy of the implementation in an ever changing

environment - organizational structures and process flows change.

1.3 Primary Audience

The primary audience for this document are:



• the Enterprise Architecture Office; and, • the Business Partnership Teams.

1.4 Overview of the Document

Business capability modelling is just one facet of a business architecture, which itself is just one view of an enterprise architecture. To be able to properly describe the context for business capability modelling, it is therefore important to place it in the context of an overall architecture framework so that the key dependencies to other architecture views are understood. Therefore, this document is structured to build from a general description of an architecture framework to the specific details and templates to support business capability modelling. A summary of the main sections of the document follows: • Section 2 - Method Overview: Provides an overview of the “Integration Framework”

and introduces the main phases through which an architecture is elaborated. It also shows the main architecture views and describes the relationships between various architecture models.

• Section 3 – Approach: Provide more details on business architecture at the “enterprise” level and then for a specific “initiative”. It describes the process for building the business architecture using the business capability modelling approach, the main inputs to the process, the deliverables that are produced and the key participants.

• Section 4 – Techniques and Notation: Focuses specifically on business capability modelling and the various levels of model. The section defines the components, the steps in building a capability model and the key attributes of the model.

• Section 5 – Business Capability Heat Maps: Presents the method for developing heat maps to demonstrate the application of criteria pertaining to performance, business value, predictability, change impact against business capabilities. The generation of heat maps facilitates decision making regarding architecture and development directions.

• Section 6 – Roles and Responsibilities: Describes the roles of the main participants to business capability modelling. There are three main considerations, roles for those who develop and maintain the method; roles for those who develop and maintain the enterprise-level models; and, roles for those who develop and maintain the models associated with a specific initiative.

• Section 7 – Governance: This section describes the main decisions rights and accountabilities for business architecture and the architecture methods.

• Section 8 – Change Configuration Process: Provides an introduction to the management of models.

• Section 9 – Glossary. Provides a definition of the main concepts introduced in this document.



2 Method Overview

2.1 Introduction

In today’s environment, organizations have usually defined a high-level target state referred to as an enterprise vision, complemented by strategic goals and objectives. To enable achievement of the vision it needs to be described as a target state in terms of customer priorities, performance goals, business capabilities and the supporting human, financial and information technology resources. Combined, these elements are appropriately described through the standard components and inter-relationships of an enterprise architecture. To implement the enterprise architecture, an organization must make sure that the information technology is aligned with the business needs and supporting resources. This necessitates having a clear understanding of business priorities and the ability to define projects that can effectively deliver the information technology to enable the desired business capabilities. Optimally, an organization should take a holistic view of the enterprise at a strategic level and then use it to plan and execute multiple projects simultaneously. Characteristically, the holistic view accommodates comparison between: • A performance-based view, which addresses the contribution of an initiative to the

realization of the strategic objectives. • A program-based view, that addresses the resources required to deliver the projects

comprising the initiative and addresses the capacity of those impacted by the initiative’s implementation.

• An “anchor initiative view”, that relates to an integrated infrastructure initiative such as implementation of an ERP system or an enterprise data warehouse that has major cross-cutting impact on multiple business owners.

The development of the enterprise architecture and consideration of trade-offs is a complex and difficult challenge, especially when recognizing that many interdependencies between projects exist that must be coordinated to achieve success. The challenge is exacerbated as the target state cannot be implemented overnight, but as time passes the business needs evolve. Changes to the architecture are therefore inevitable and a mechanism needs to exist to assess the enterprise impact of change on all the related architecture components and the projects that are implementing them. The architect therefore has to fully understand the transition state and follow a method that allows it to continually evolve. Without coordination of the interdependencies and their changes over time, an organization could successfully complete each project but find that the lack of integration across the projects result in a failure to implement the enterprise vision. In response to these challenges, the Integration Framework was developed. It builds upon the work done in methods such as the Zachmann framework, the Department of Defense Architecture Framework (DoDAF) and the Federal Enterprise Architecture Framework (FEAF). Like the precursors, the integration framework defines a series of integration points and work products that must be specifically addressed to properly synchronize efforts to deliver the target state. However, it builds on these and introduces a new discipline of integration management to address the inevitable changes that occur as the target state vision is implemented. Integration Management, shown as the central circle in Figure 2-1, coordinates three management disciplines:



1. Architecture Management – involves documenting current state business capabilities, information, systems, technology and performance results; defining a target state architecture; and identifying the initiatives in the form of programs required to close gaps between the current and target states.

2. Program Management – includes activities such as planning and managing scope, performance and earned value; identifying and managing risks; tracking budgets, schedules and milestones; establishing and monitoring adherence to quality standards; and coordinating change through communications.

3. Outcome Management – involves activities that allow managers to not only measure program success, but also helps to make certain that program successes, and corresponding investments, support larger organizational objectives. Outcomes Management includes activities such as output and outcomes planning, performance measurement and management, business case preparation and justification, and performance analysis and oversight.

Figure 2-1 illustrates the Main Management Disciplines of the Integration Framework .

Each of these management disciplines focus on a subset of the concerns that must be controlled during program and project execution. Integration Management fosters a clear understanding of the relationships among outcome requirements, architecture decisions, project costs, schedules and risk mitigation strategies. Moreover, Integration Management transition, project planning and control activities help managers make sure that: • Projects are Coordinated

•

: Projects comprised within a program are treated as parts of an integrated strategy and not as independent investments; Trade-offs are Balanced

•

: Project solution alternatives are considered within the context of larger program objectives and not just in terms of a project’s near-term needs; Architectures Drive Investment

•

: Architecture efforts are more than just compliance exercises – architectures are the basis of target state planning activities and investment decisions; and Changes are Addressed

: Target state plans are regularly reviewed, adjusted and kept in tune with current organizational priorities, available resources and program accomplishments.

The following section introduces the Integration Framework and sets the context for Business Capability Models.



2.2 Integration Framework Phases

The Integration Framework defines an organized and integrated set of processes and work products that may be used to define a target state vision for an organization at the enterprise level, and to define the overall concept and high-level requirements for an individual initiative. A simple representation of the framework in terms of the main phases and activities is shown in Figure 2-2. The area highlighted in yellow represents the business architecture view. The Framework defines two sets of visioning work products: • The Enterprise Vision, which creates an integrated view of the entire enterprise within

which the relationships between the high-level business and IT components are described. It also defines the sequencing for the integrated enterprise-wide suite of initiatives.

• The Initiative Vision, which defines a single initiative to a level of detail that would support its acquisition. This includes describing the alignment of the initiative to desired performance standards. A separate Initiative Vision will be produced for each initiative that is defined by the Enterprise Vision. The Initiative Vision work products may become part of a statement of objectives that is used to acquire an initiative solution or to guide a system development activity.

Figure 2-2 illustrates the Integration Framework’s phases and core activities. The scope of the architecture described using the framework may be very large (for example, the entire enterprise) or focused on a single solution or initiative. The level of detail in the description will increase as the scope decreases to focus on a single initiative.



2.3 Integration Framework Work Streams

The Integration Framework defines work products that will support both the Enterprise Vision and the Initiative Vision. These work products are grouped by work stream and by system development lifecycle phase. The Integration Framework work streams are: • Performance, which defines the metrics by which the success of the business will be

measured. • Business, which defines what the business does to deliver products and services to its

customers. • People, which defines the nature of the human resource, the organizational culture and

leadership, and the organizational structure and responsibilities of the units that make up the enterprise.

• Information, which defines the data and information that is required to support the Business Capabilities.

• Application, which defines the application systems and service components that realize the Business Capabilities.

• Technology, which defines the technical standards and products the enterprise may use in support of the Business Capabilities.

• Integration Plan which defines the overall concept of operation, the plans for its implementation, the sequencing of key activities, change impacts and approach to controlling the initiatives as they implement.

Figure 2-3 illustrates the Integration Framework’s phases and work streams.

Figure 2-3 Integration Framework Phases and Work Streams Some examples of the key work products within the work streams of the integration framework are:



Performance Work Stream • Business Performance Model, which defines the strategic performance objectives and

the key performance indicators in the context of better support to clients, employees and other stakeholders.

Business Work Stream • Business Capability Model, which defines the Business Capabilities, associated with

the architecture segments in support of the enterprise mission. • Business Use Cases, Business Process Flow and Core Business Requirements

which together describe how the Business Capability is to be delivered. People Work Stream • Human Resource Model which documents the organizational culture, the structure of

the enterprise in terms of relationships between organizational units, the key roles and distinct personas of the enterprise.

Information Work Stream • Enterprise Conceptual Data Model and Logical Data Model which defines the major

business data entities and relationships between the entities. The Conceptual Data Model is a high-level overview of the enterprise-wide data that is created during the Enterprise Vision phase, while the Logical Data Model is a more detailed model (based upon the Conceptual Data Model) that is created during an Initiative Vision phase. The Logical Data Model focuses upon the subset of the enterprise data entities that are used by a particular initiative.

• Information Exchange Diagram, which shows the information exchanged within the enterprise and between the enterprise and external partners and citizens.

Application Work Stream • Application Component Model, which defines a high-level view of executable software

or business service components that implement one or more business processes or parts of business processes. Ultimately, an initiative is a project that implements one or more components.



Most of the work streams utilize and build upon the work products of other work streams. Many of the work streams contain traceability matrices that express relationships between architectural elements defined by their work products and created by other work streams. For this reason, work streams (and work products within a particular work stream) have dependencies upon each other. Figure 2-4 depicts the main relationships between the high level work streams.

Figure 2-4 Work Stream Model Dependencies

A preferable ordering for starting the development of work streams that honors these dependencies is:

1. Performance 2. Business 3. Information 4. Human Resource 5. Technology 6. Application 7. Integration Plan

However, the development of the models is iterative and there is rarely the situation that all enterprise level models can be completed before work starts on the more detailed architecture for an initiative. It is important to not lose sight of the fact that we gain value through architecture by taking contributions from all the layers at one time and implementing them to deliver a business capability Figure 2-5 below presents a comprehensive list of the work products and work product components that comprise the Integration Framework.



• Target State Concept of Operations• Target State Change Impacts• Integration Sequence Plan• Initiative Concept of Operations• Initiative Business Case

EnterpriseVision

Business

Performance

Human Resource

Information

• Enterprise Mission, Vision & Objectives• Extended Enterprise Value Chain• Products & Services• Outcomes Map (strategy map)

• Information Principles• Conceptual Data Model (Subject/Entity)• Data Taxonomy & Dictionary• Information Exchange Matrix• Information Relationships Matrix

• Organizational Culture & Principles• Organizational Structure• Organizational Roles• Employee Personas• Human Resource Relationships Matrix

• Application Principles• Application Component Model• Application Component Relationships Matrix

• Technology Principles• Technology Standards• Technology Component Model• Technology Component Relationships Matrix

• Logical Data Model (Subject/Entity/Attribute)• Data Taxonomy & Dictionary• Information Relationships Matrix

• Initiative Performance Indicators• Product & Service Description

• Organizational Structure• Organizational Roles• Employee Personas• Human Resource Relationships Matrix• Initiative Change Management Strategy• Initiative Communication Plan

• Application Component Model• Application Component Relationships Matrix

• Technology Standards• Technology Component Model• Technology Component Relationships Matrix

• Enterprise Architecture Segments• Business Capability Areas• Business Capabilities• Business Principles

• Business Capability Model• Business Process Model• Business Use Cases• Functional Requirements

Applications

Technology

Updates to Enterprise Vision

Syst

em

Del

iver

y Li

fecy

cle

Phas

es

Syst

em D

eliv

ery

Life

cycl

eW

ork

prod

ucts

InitiativeVision

• Initiative Concept of Operations• Initiative Change Impacts• Initiative Transition Plan• Initiative Business Case

Integration Plan

Figure 2-5 Integration Framework Work Products

The flow depicted at the bottom of the chart shows how the architecture models need to be updated as initiative visions are completed and solutions are implemented. As mentioned earlier, it is important for the architect to have a clear understanding of both the target state and the current transition state. The Integration Framework does not prescribe the fine details of the implementation of each work product or recommend tools to produce the work products. The framework was designed to allow each visioning task to select their own work product implementation and tools as long as the work product implementations achieve the objectives specified in the framework.



3 Approach

3.1 Introduction

This section introduces the approach to building the Work Products of the Enterprise Business Architecture and the Initiative Business Architecture with a specific focus on the identification and definition of Business Capabilities. This represents just one of the seven work streams of the integration framework.

3.2 Enterprise Business Architecture

The purpose of defining the business architecture at the enterprise vision level is to define the optimal set of Business Capabilities to realize the vision and strategic objective of the organization. This includes identifying the main resources required to enable the Capabilities and to provide the context for prioritizing and delivering improvements to the Capabilities. Figure 3-1 shows the key elements involved in developing the enterprise business architecture.

• Enterprise Mission / Vision• Target Performance Model• Current Business Processes• Current Organizational Model

Inputs• Business Sponsors• Business Managers• Operational Subject Matter Experts• Business Partnership Teams• EA Office

Participants

• Identify the main external stakeholders in terms of customer, suppliers, strategic partners, regulators, etc.• Identify the core functions of the enterprise in terms of those that deliver products & services to customers• Identify the functions that provides direction and guides the organization to its mission and vision• Identify the functions that provide support to the realization of the mission and the delivery of products• Aggregate the functions around a common purpose to identify a unique segment

• Identify what the business does to deliver its main products & services to customers• Identify what the business does to provide direction to and enable business operations• Map the capability areas identified to architecture segments• Validate against the mission of each organizational unit with each architecture segment• Validate the initial map of the business capability areas

• For each business capability area, identify the business capabilities:What are main components required to deliver the capability?Who is the customer and what is the major result (outcome) delivered to them?How is the delivery of the result measured (metrics)?Is there a dependence between any of the capabilities?

• Create a diagram that shows the main business capabilities and their dependencies• Describe each capability in terms of the customers, products/services, performance criteria, triggers/inputs

and identify what manages or controls the capability• Describe each capability in terms of the key resources required in support of the capability (human

resources, information, applications, technology)• Validate the business capabilities

• Enterprise Architecture Segment• Business Capability Areas

Deliverables

Define Enterprise Business Architecture

Main Process Steps

• Business Capabilities• Business Principles



Figure 3-1 Enterprise Business Architecture

Capability improvements are delivered by structuring the architecture into initiatives based upon priorities for improvement, inherent dependencies between Capabilities, funding constraints and capacity to implement the initiative solution. Core techniques to support business architecture development include: • Value chain analysis1

• Affinity analysis

: This is a technique for analyzing the relative cost and added value of a business's primary and support activities in the delivery of a product or service to the customer. Value chain analysis diagrams a business's activities vertically and horizontally. The vertical (upstream to downstream) view represents the primary activities of transforming an input into an output (inbound logistics, operations, outbound logistics, marketing and sales, service). The horizontal view shows support activities (firm infrastructure, human resource management, technology development, procurement). The configuration of these activities drives the cost and value of a delivered product or service, providing inputs for defining the activities and resources of the business unit (organizational boundaries). Analysis of supplier and customer value chains can identify opportunities or threats for customer and network choices.

2

• Business scenario analysis

: is a data analysis and data mining technique that discovers co-occurrence relationships among activities performed by (or recorded about) specific individuals, groups, or in general about objects for which there is a desire to aggregate by some common characteristics.

3

• Customer value analysis

: This is a technique in which sets of internally consistent assumptions about future environmental conditions and events are projected. Developing these projections may include an analysis of external factors derived from environmental scanning or other similar techniques.

4

• Strength, Weakness, Opportunity, and Threat (SWOT) analysis: A technique for the identification of opportunities and threats and analysis of an organization strengths and weaknesses in the business context. SWOT analysis involves specifying the objective of a business venture or project and identifying the internal and external factors that are favorable and unfavorable to achieving the objective

: Measurement of customer and non-customer satisfaction with products and services, relative to those of competitors. Customer value analysis measures market-perceived benefits of products and services adjusted for their relative price.

• Strengths – attributes of the organization that are helpful to attaining the objective • Weaknesses – attributes of the organization that are harmful too achieving the

objective • Opportunities – external conditions that are helpful to achieving the objective • Threats – external condition that are harmful to achieving the objective • Balanced Scorecard5

1 Porter, Michael, Competitive Advantage: Creating and Sustaining Superior Performance, The Free Press, 1985

: Procedure in which financial performance targets are related to other performance measures from strategic and organizational perspectives on the basis of causal linkages. The scorecard can link short-term objectives (financial performance)

2 J. Han et al, 2006, Data Mining: Concepts and Techniques 3 Schwartz, Peter, The Art of the Long View: Paths to Strategic Insight for Yourself and Your Company, Doubleday Currency, New York, Second edition, 1996 4 Gale, Bradley T., Managing Customer Value, The Free Press, 1994, 5 Kaplan Robert S. and Norton David P., Using the Balanced Scorecard as a Strategic Management System, Harvard Business Review, 1996



with long-term objectives (strategic objectives). It originally served to align the objectives (milestones), measurements, targets and initiatives of four perspectives - financial, customer, business process and learning.

Figure 3-2 presents the purpose and content of each deliverable:

Enterprise Business Architecture Deliverables

Purpose:To define the business in terms of:• The core line of business associated with the delivery of products and services• The functions involved in providing direction and guiding the enterprise towards the vision• The functions involved in providing support Content:• Architecture segment description• Mapping to business units

Purpose:• To define what the business does to deliver products and services, to provide direction and guide the enterprise

towards the vision and to provide support Content:• Architecture segment to business capability area map• Business capability area description

Purpose:• To define what the business does to deliver an output to a customer within a specific business capability area• To identify business capabilities that cross business capability areas Content:• Business capability dependency diagram• Business capability description

Purpose:• To provide clear guidelines for business and architectural decisions• To state the fundamental beliefs that the organization wishes to establish as the basis for decisions Content:• Statement of the principle• Implications and rationale

Enterprise Architecture Segment

Business Capability Area

Business Capability

Business Principle



Figure 3-2 Enterprise Business Architecture Deliverables

3.3 Initiative Business Architecture

The Initiative Business Architecture identifies the Business Capabilities that belong to the target initiative, and elaborates the details pertaining to the role and relationships of supporting resources such as people, information and technology in delivering the products and services to the customer. This facilitates the development of functional requirements and Use Cases that can be used by developers to create a solution(s) that enable the Capability performance improvements. The Initiative Business Architecture:

• Clarifies business scope of the initiative by defining specific Business Capabilities and requirements

• Describes how the business requirements are delivered through the business processes, including control activities, and shows what resources are required.

• Aligns the Capabilities to specific key performance indicators • Translates the Business Capabilities into Use Cases and creates the core functional

requirements that can be used to make technology choices or guide systems development.

• Figure 3-3 shows the key elements involved in developing the initiative business architecture.



• Business Capabilities• Initiative Concept of Operations• Initiative Performance Indicators• Target/Current Business Processes• Target/Current Resource Models (Human,

Information, Application & Technology)

Inputs• Initiative Sponsor• Subject Matter Experts - Initiative Business Managers - Business Users• Business Partnership Teams• Enterprise Architecture Office• Information Technology Specialists

Participants

• For each business capability in the Initiative Concept of Operations:What are main components required to deliver the capability?Who is the customer and what is the major result (outcome) delivered to them?How is the delivery of the result measured (metrics)?What dependencies exist between the capabilities?

• Create a diagram that shows the main business capabilities that comprise this initiative• Describe each capability in terms of the customers, products/services, performance criteria, triggers/inputs

and identify what manages or controls the capability• Validate the performance criteria against the Initiative Performance Indicators• Describe each capability in terms of the key resources required in support of the capability (human

resources, information, applications, technology)• Validate the business capabilities with the business users and IT team• Identify the core business requirements associated with each business capability

• Develop the process flow in support of each capability (identify key inputs, outputs and steps in the process)

• Develop Use Case descriptions addressing flow of events, goals and actors

• Using the business requirements from the capabilities, the use case model and the content of the initiative resource models (human, information, application & technology) create a list of functional requirements

• Business Capability Model• Business Process Model

Deliverables

Define Initiative Business Architecture

Main Process Steps

• Business Use Cases• Functional Requirements

Figure 3-3 Initiative Business Architecture

Core techniques to support Initiative Business Architecture include: • Stakeholder analysis6

• Prototyping is the process of quickly putting together a working model (a prototype) in order to test various aspects of a design, illustrate ideas or features and gather early user feedback. Prototyping is often treated as an integral part of the system design process, where it is believed to reduce project risk and cost. However, it can also be used during the initiative vision phase to help validate a concept. Often one or more prototypes are made in a process of iterative and incremental development where each prototype is influenced by the performance of previous designs, in this way problems or deficiencies in design can be corrected

is a form of analysis that aims to identify the stakeholders that are likely to be affected by the activities and outcomes of a project, and to assess how those stakeholders are likely to be impacted by the project. Stakeholder analysis has the goal of developing cooperation between the stakeholder and the project team and, ultimately, assuring successful outcomes for the project.

• Scenario Analysis combines the concepts of prototyping with business scenario analysis to prepare different usage scenarios to help validate the completeness of a

6 Savage, G. T., T. W. Nix, Whitehead and Blair. (1991). "Strategies for assessing and managing organizational stakeholders." Academy of Management Executive



concept of operations. It is usually a “paper-based” exercise to assess how the capabilities will meet the requirements of the various stakeholders based on their different requirements of the capability

• Strength, Weakness, Opportunity, and Threat (SWOT) analysis: Identification of opportunities and threats and analysis of an organization strengths and weaknesses in the business context. SWOT analysis involves specifying the objective of a business venture or project and identifying the internal and external factors that are favorable and unfavorable to achieving the objective

• Strengths – attributes of the organization that are helpful to attaining the objective • Weaknesses – attributes of the organization that are harmful too achieving the

objective • Opportunities – external conditions that are helpful to achieving the objective • Threats – external condition that are harmful to achieving the objective • Figure 3-4 presents the purpose and content of each deliverable:

Initiative Business Architecture Deliverables

Purpose:• To define what the business does to deliver its output(s) to its customers and how its performance is measured• To articulate the main components required to provide a business capability and to define business requirements Content:• Business capability dependency diagram• Business capability description• Business capability resources• Business requirements

Purpose:• To define how the business applies resources to create its outputs and provide appropriate controls • To graphically depict the business process steps to show sequence, dependency and role of resourcesContent:• Business process model• Business process description

Purpose:• To provide a link between the business capability and the applications/services required to support the capability Content:• Use Case diagram• Use Case description• Use Case relationships matrix (relationships to business capability, process, data, user class)

Purpose:• To provide clear statements of functionality to be provided by the automated solution• To set priorities to allow effective evaluation of alternative solutions Content:• Requirement identifier/name and description• Priority (mandatory, desirable, optional)• Type

Business Capability Model

Business Process Model

Use Case

Functional Requirements

Figure 3-4 Initiative Business Architecture Deliverables



Figure 3-5 shows the main relationships between the deliverables of the Initiative Vision phase and how they feed the selection of a technology solution and the main phases that support that’s technology’s implementation

Business Capability

Descriptions

Business ProcessUse Cases Business Requirements

Functional Requirements

Define technology usage through

Define activity sequence through

Enabled by Enabled by

Provide formal structure for

Derived from

Derived from Derived from

Technology Solution

Drive the selection of

Initiative Vision Phase

Detailed ConfigurationRequirements

Solution Configuration

ConfigurationDesign

Solution Delivery Lifecycle

Solution Implementation

Figure 3-5 Initiative Business Architecture Deliverable Relationships



4 Techniques and Notation

4.1 Introduction

In this Section, we introduce one of the main concepts that is used to articulate a business architecture, the Business Capability. We describe how to build a business capability and what attributes of the capability should be captured to support the design of the resources and other architecture components that enable the business capability. A business capability is "what the business does to perform something of value to that business". This is in contrast to a business process, which describes how

the business performs or implements the given capability or how capabilities connect to deliver a desired outcome. Business capabilities describe the stable elements of the business to model your organization and provide the critical layer that aligns application services to business operations, and hence drives the development of a service-oriented architecture.

A business capability is expressed in terms of outcomes and service levels, to create value for the customer (who may be internal or external). Business-capability mapping is the process of modeling what a business does (its capabilities), to reach its objectives. Links between capabilities are defined as capability connectors that focus on information exchange in terms of inputs (what is consumed) and outputs (products and outcomes) and controls (policies, standards, approvers, etc.). Business capabilities may be defined at different levels within an organization: • Capability Areas exist at level 2 of the business architecture, and reside one level

below each of the Bank’s architecture segments. Examples of Capability Areas with the architecture segment of Enterprise Business Management include Enable Collaboration, Procure Goods and Services, and Pay Administrative Expenses.

• Capability Sub-Areas exist at level 3 of the business architecture, and are the logically decomposed elements within a Capability Area.

• Capabilities exist within Capability Areas and Sub-Areas. They are the more granular group of activities that physically appear as capability objects on the diagram itself. The level at which capabilities are defined varies in accordance with the individual needs of each initiative.

4.2 Techniques for Identifying Capabilities

The Enterprise Vision defines the Capabilities of the organization in levels 1 (architecture segments) and 2 (Capability Areas). These compose the essential elements of the “high-level” enterprise Business Capability framework for the Bank. In reality, however, most Capability Diagrams contain elements that cross Architecture Segments, or that cross Capability Areas within Segments. As a result, each Capability that is identified for modeling purposes needs to be analyzed by the Capability Facilitator7

in the context of this broader framework to ensure alignment across segments.

7 See Section 5.2 of this document for a description of the role of the Capability facilitator.



Figure 4-1 - Sample Relationship between Segments, Capability Areas, and Capability Models

Figure 4-1 above shows a representative example of how a Capability diagram titled “Obtain and Pay for Goods and Services”, a typical procurement Capability, ties back to the Bank’s Architecture Segments and Capability Areas and Sub-Areas. To define a Capability Model, the Capability Facilitator leads the steps detailed in Section 2.2 of this document. 4.2.1 Steps to Define Enterprise Level Capabilities The following section details the high level steps that can be used to identify capabilities at the Enterprise level (Level 0 and Level 1):

Step1: Review Literature and Background Materials: Review existing materials through a “Discovery Phase”, including business function schemes, strategic priorities, organizational alignment, and operational strategy. Step 2: Develop Straw Model of Level 0 Capabilities and Conduct Initial Validation: Using information gleaned from the existing literature, define segments or “lenses” by which the organization can view the capability definitions. Using these lenses8

, develop an initial model to define the main markets/clients and the high-level products and services that are delivered to these markets / clients. Review this model with key business stakeholders for accuracy, relevance, and potential additions.

8 Lenses used at the Bank during the initial development of the level 0 model included architecture segment, value chain, business process team, and strategic theme.

Architecture Segment: Enterprise Business Management

Capability Area: Corporate Procurement

Capability Sub-Area: 1 - Procure Goods and Services

2 - Monitor Receipt of Goods and Services

Architecture Segment: Finance, Banking, and Investment

Management

Capability Area: Expenditure Management

Capability Sub-Area: 1 – Pay Administrative Expenses

Procure Goods and

Services

Monitor Receipt of Goods & Services

Pay Administrative

Expenses

Sample Capability

Obtain and Pay for Goods and Services: “ From Order to Invoice ”

Level 1 – Architecture Segments

Level 2 – Capability

Area

Level 3 – Capability Sub-Area

Capability Diagram

High - Level BCM

Framework

Requisition / SOW

Paid Invoice

Level 4 to n Capability



Step 3: Identify Level 1 Capabilities: Once the context of the high level model has been established, continue to drill down into the Level 1 Capabilities across the Enterprise. This definition will:

provide greater definition for validating the context at the higher level; demonstrate uniqueness in the capability by high-lighting overlaps and

duplicates; and, enable mapping of the capabilities to the business units that provide the

capability. Step 4: Validate High-Level Model with Business Owners: Review the model with key business stakeholders to validate wording and completeness of the Level 0 diagram. These stakeholders should be a cross-functional representation in terms of networks, regions, country offices and the main market segments. Step 5 Validate Lower-Level Model with Business Owners: Once the top level capability map has been validated, the stakeholders validate the second level of capabilities (Level 1). This review includes looking at naming conventions, model completeness and accuracy of the listed capabilities.

4.2.2 Steps to Define Initiative Level Capabilities The following section details the high level steps that can be used to identify capabilities at the Initiative level (Level 2 and Below). This section is broken into two parts – studying the Current State or “As-Is” and the visioning of the Target State or “To-Be”. 4.2.2.1 Business Capability As-Is Playbook

Step 1: Scope Capability: Similar to the Enterprise Level, the Initiative As-Is definition begins with a review of existing materials to define the scope of the initiative. This activity reviews the Level 0 and Level 1 documentation as well as establishes a baseline understanding of the initiative capability area. The scope defined in this step is validated with the Business Sponsors of the initiative. Step 2: Compartmentalize Capabilities: Utilize existing information and business sponsor input to identify potential capabilities. This activity should focus across the entire capability area and capture key elements and potential gaps in information. Step 3: Develop Strawman Maps: Draft the Level 2 Capability Map and any Level 3 or 4 maps where information in sufficient to do so. This diagram provides an integrated view of each capability and obvious / important objects. Step 4: Interviews with Stakeholders: Collect questions or issues identified through the initial scope and mapping exercise. Identify key stakeholders for interviews, ordered by broad subject matter expertise and level of influence in the organization. Interviews should focus on the following four components:

• Goals for the project – to understand interests and perspectives • Measures of success – to understand each interviewee’s desired outcome

from the project • Review of Draft Capability Diagrams – to orient each interviewee to the high-

level capability diagram • Questions specific to the interview – to clarify questions, fill gaps, and analyze

capabilities



Upon completion of the interviews, produce formal notes and document key subject matter input on the capability map(s). Step 5: Draft Capability Templates: Utilize information gathered during the interview process to draft a capability template for the lowest level diagrams, including business requirements identified by the stakeholders and interviewees. The template for this documentation can be found in Appendix 1. Step 6: Conduct Workshops: Utilize a workshop format to validate capability components and related business requirements and identify additional items. Workshops should be attended by core team members and key stakeholders. The draft capability maps resulting from the interview process provided sufficient detail to begin work on the underlying capability templates. Step 7: Detailed Capability Models: Document the final As-Is capability models and templates and validate with the Project Sponsor and key stakeholders through interviews.

4.2.2.2 Business Capability To-Be Playbook

Step 1: Gap Analysis: Review the capabilities, issues, and parking lot ideas captured during the As-Is analysis to develop a list of capability gaps that could be addressed in the Target State analysis. Validate and prioritize this list with the key team members (either in small group sessions or in larger workshop settings). Step 2: Revisit the Capability Diagram: Determine the impact of the improvements on the capability diagrams and reflect key changes on the To-Be maps. Potential changes include the addition of capabilities, the rearranging of objects, or a change in object form (e.g. document to data). Step 3: Develop a Concept of Operations: In a narrative form, describe the Target State capabilities and key concepts. Include detail about objects and relationships, and how changes to the As-Is state will improve capability performance. Step 4: Derive Functional Requirements (optional): Utilizing the capability definitions and the desired To-Be state, capture the high-level business and functional requirements necessary to achieve the end state.

4.3 Usage of Capability Definition in Decision Making

Capability definitions provide a foundation for analytical analysis at both the Enterprise and Initiative level. At the Enterprise level, capabilities can be assessed for criticality and effectiveness, highlighting specific focus areas for performance improvement. At the initiative level, capabilities can assist with project portfolio management and selection of IT solutions. 1. Criteria for Performance Assessment Capability analysis provides an analytical foundation for performance analysis and improvement opportunity definition. The following types of questions are used to derive information from stakeholders on current and desired performance:



• Business value: o Does the capability differentiate the Bank and influence client satisfaction

including whether countries desire the Bank’s products and services? o Does the capability drive a key performance measure such as project results,

speed and quality of service delivery, or risk tolerance? • Current Performance:

o Is the performance of a capability excellent, inconsistent or poor in terms of the Bank’s needs?

o Is client demand for the capability increasing or decreasing? o Does the capability perform equally well for each customer group (LIC, MIC,

FCS) A ”heat map”9

Primary: those capabilities that the Bank should keep in house and should be the top priority for performance improvement

provides a pictorial representation of capabilities that are highly effective, meet expectations, and others that are potential areas to focus improvement. This tool is effective in situations where a given capability may have different performance characteristics in different customer markets and may require more context-specific analysis. The heat map can also be used to assist with sourcing decisions in terms of:

Shifted: those capabilities that can be transferred to customers, suppliers or operational specialists

Automated: capabilities whose outcomes are highly predictable (in terms of cost, time quality) and are strong candidates for becoming web services or for which the user interface should be automated.

Further details on the application of the Heat Mapping technique are given in Section 5 of this guide. 2. Resource Allocation Analysis An allocation analysis to assess the alignment of proposed IT capital investment to business needs. Capability areas can be aligned to the allocation of IT capital funding, providing a view into strategic alignment of capital spend. The intent is not to provide judgment whether the funds proposed are being invested appropriately but rather to utilize capability analysis as a planning tool to ensure the organization is investing in the right things to realize the business strategy. 3. Progressive Commitment of Resources Elaboration of the high-level business architecture can be used for progressive commitment of funding for an initiative. As shown in Figure 4-2, the high-level business/enterprise architecture proposes a series of initiative concepts, which are described through an Initiative Concept Proposal. This Initiative Concept Proposal is reviewed by the Architecture Review Board who would make a recommendation to the governance body for funding.

9 See Harvard Business Review: June 2008 – The Next Revolution in Productivity



Figure 4-2: Progressive Commitment of Resources The business case associated with the Initiative Concept Proposal addresses the full lifecycle cost of the initiative, but Initiative Concept Proposal focused primarily on the plan and investment required to complete the Initiative Vision. In this way, the organization can approve just the funding for the Initiative Vision Phase. This approach provides a checkpoint between concept approval and detailed design approval before a solution is implemented. Once the Initiative Vision Phase is completed, the business case is updated as now the initiative is understood and the decision can be made whether to fund the full implementation. 4. Technology Solution Selection The analysis completed as part of the Initiative vision sets the foundation for analytical work within the Software Development Life Cycle. The capability definition and ensuing business and functional requirements can be leveraged by the business and information technology organizations to understand and define the scope of a technology solution.

4.4 Model Components – Diagram Symbols and Attributes in Capability Templates

This section describes the components of and notation required to develop Capability Models. Capability Models are composed of Capability diagrams, completed Capability templates, and (in some cases, as-needed) Capability to business requirements or use case mappings. Specific deliverables included at each level of the enterprise Business Capability Model are detailed below:

Level 1 – Enterprise Architecture Segment: No model deliverables



Level 2 – Capability Areas: Capability Area Template (see Figure A-1 in Appendix) Level 3 to Level n – Capability Sub-Areas: Capability Model Templates (See Figure A-2 in Appendix), Capability Model Diagrams, and (as-needed) Business Requirements matrix that maps each requirement to a Business Capability.

An overview of the Business Capability Modeling Notation follows.



The primary elements of a Capability Model are “events” and “objects.” Models also include connectors and capability keys. A generic example of a capability model showing the various components is depicted in Figure 4-3. The description of the various components of the model and their attributes is given below.

Capability Model

The Model itself contains a series of events and objects that depicts what the business does to deliver value to the customer (either internal or external). The model development method can be applied to develop either the components of a Capability Area, or the relevant Capability segments (spread across Capability Areas or architecture segments) that make up a Capability diagram. Key Model Attributes:

Vision / Mission – a brief statement of what the Capability intends to be (vision) or the purpose of the Capability (mission).

Descriptive Attributes

Description of the Capability – an overview of the scope of what the diagram will include. Dependencies (upstream and downstream) – identification of other Capabilities or Capability elements (such as objects or keys) that could influence or are subject to influence by this Capability. Issues / Risks – potential problems or events that threaten the Bank’s ability to realize the capability Parking Lot Ideas – proposals or ideas out of scope for the initiative, but worth capturing for future reference Segment Category – the architecture segment grouping within which the Capability resides (Direction, Core Business, or Support) State Representation – As-Is or To-Be Importance – increasing, stable, declining (with comments – used in the context of reengineering purposes or ranking)

Outputs / Outcomes – the vocabulary that is critical to the Capability

Individual Capability Attributes

Lexicon – terminology specific to the capability Resources – data, information, and objects that are critical to successfully performing the capability Tools and Techniques – systems, job-aids, or training elements that enable the successful execution of the capability

Business Requirement – a description of the operation required for the business result to be achieved

Individual Capability Attributes

Category – (used for on-boarding) Forms Mgmt, Info Presentation, Internal Process, System, Customer Interface, Data Transfer Customer – the primary customer of the business requirement (external or internal to the Bank) (Additional Categories) – additional notes can be added to the template to address issues specific to each initiative



“Capabilities” represent activities that transform objects. Capabilities correspond to Capability Areas or Sub-Areas, or a further decomposition of a Capability within a Sub-Area. For example – a decomposition of a Capability within “Procure Goods and Services” might be “Create Requisition”. Key Capability Attributes: Name – convention is an active verb followed by a noun Description – a brief description of what the Capability produces (for either internal or external customers) Key Attributes – itemized in the templates that appear in Appendix 1.

Outputs

– the physical or abstract resource of value produced by the Capability (typically also identified as an object on the diagram) Outcomes / Performance Measures

(optional, depending on needs of the diagram) – expected results that the Capability will deliver to the customers and/or the metrics by which achieving that result will be measured Resources

(People, Applications and Data ) – elements contributing to the realization of the Capability that focus on the “who, where, and how”; of value to the analysis, but at a level below the business architecture (information, application, network) Tools and Techniques

– job aids, training information, methods, or localized best-practices that enable the Capability

Attributes specific to a Capability Component:

Business Requirements – include a name, description, priority, and category

“Objects” represent the “physical or abstract resources of value”. Objects are bits or groups of information, documents and forms, records, products, and other business resources that flow between and can be transformed by events. Each object has been given a category, largely drawn from Enterprise Content Type listing that supports enterprise search and records management. These categories appear in the legend at the top of each capability map. If multiple objects interact with a single event, they should be stacked as appears in the sample to the left. Key Object Attributes:

Name

– convention is a noun, potentially followed by a descriptor (in parenthesis) Description

– a brief overview of the object

Category

– attributes drawn from Enterprise Content Type listing that supports enterprise search and records management: Documents & Reports, Publications, Communications, Knowledge, Data, Services, People and Communities, and Collections.

Capabilities

Object

Object



Relationships: The arrows represent the relationship between the event and the object.

• Represents "object" required to trigger the event

• The tail of the arrow departs from the object, and the head connects to the event.

• Show the "object" that controls/manages the event

• The heads of the arrow connect both the object and the event.

• Shows the result created through transformation by the event

• The tail of the arrow departs from the event, and the head connects to the object.

Key: The “key” represents a decision or attribute within the Capability chain that lies on the critical path to that Capability’s primary output or outcome. These may be controls that are in place which dictate if a Capability event may continue, dependencies within the Capability that are critical to the eventual outcome to the customer, entry or exit criteria, or the like.

A Capability “key” can represent entry rules, exit rules, critical decision criteria, or barriers to change. Capability keys are identified within the Capability Model on the

top-right hand corner of either the event or object which they apply to.

In the context of Figure 4-1 above, a capability key associated with the object “Pay Invoice” might be that two written approval signatures must be captured before an invoice can be paid (exit rule).

A separate example of a key associated with the capability “Monitor Receipt of Goods and Services” could be that the lack of a claims process impairs any ability to improve inventory control (a barrier to change).

K



# - <Capability Area/Sub-Area> – <Capability> Business Segment – <Business Segment>

Capability B

Capability C

Capability DDocument 1

Knowledge

Document 2

Data 3

LEGEND: Capability Document / Report Publication Communication Knowledge Data Services People / Communities Collections Non-Bank Artifacts

NBA 1

Service 1

Communication 1

Capability A

Community 1

Document 3

Physical Asset

Data 2

Data 1

Figure 4-3 – Generic Capability Model Example

4.5 Extending the Capability Model to Business Requirements

Within each Capability Area or Sub-Area, the Capability Facilitator may wish to derive business requirements that align to Capabilities within the diagram. Though a single business requirement may span multiple Capabilities, this approach of vertically analyzing Capabilities provides a clear framework for eliciting business requirements from business owners. Whereas requirement brainstorming is often abstract and process modeling too detailed, the Capability method allows the business requirement to focus on the “what” of the business – the elements core to successfully realizing the value chain. As Figure 4-4 illustrates, requirements management driven by a Business Capability Model provides a consistent structure and clear alignment back to business operations.

RequirementRequirement








CapabilityCapability CapabilityCapability CapabilityCapability

NEW Requirement

REFINED Requirement

REFINED Requirement

NEW Requirement

Business Requirement


REFINED Requirement



RequirementRequirementRequirementRequirement



RequirementRequirementRequirementRequirement

ObjectObject

ObjectObject

Requirements Brainstorming Requirements Grounded in Business Capabilities

Value - Requirements more comprehensive resulting from alignment to business awareness…

Figure 4-4 - Value of Business Requirements Tied to Capabilities

A business requirement is defined as “a specification of what the business wants, typically expressed in terms of outcomes the activities generate rather than the functions or specific



operations any system or person will perform”. The identification of business requirements – as one of the critical deliverables within the initiative business architecture – later drives capturing functional requirements. A functional requirement is defined as “a specification of a particular system that can include how data or information manipulation, processing, or other behaviors of the system.” The core of the business requirement is the description of the required behavior. The definition of Business Capabilities also drives the definition of use cases, which are a description of a sequence of events that – taken together – lead to a system doing something useful10

. Many requirements will be uncovered during the use case development. As a result, Business Capabilities are critical in both feeding functional requirements and the definition of use cases. These items then drive the work within the system development lifecycle.

10 Kurt Bittner, Ian Spence (2002). Use Case Modeling. Addison Wesley Professional, 2-3. ISBN 0-201-70913-9.

Systems Development Lifecycle

Business Requirements and Use-Cases

Functional

Requirements

Business

Capabilities

http://en.wikipedia.org/wiki/Addison_Wesley�

http://en.wikipedia.org/wiki/Special:BookSources/0201709139�



5 Business Capability Heat Maps

5.1 Introduction – Why Heat Maps

A heat map is a graphical representation of data where values taken by a variable in a two-dimensional map are represented as colors. In the context of the business capability model, each capability is annotated with the values of selected evaluation criteria, with color-coding of capabilities to indicate the overall evaluation. The Capability Heat Map allows us to make more informed decisions about a number of critical business and technology issues, including the following: • Business value: Is the business capability a key contributor to the realization of the

Bank’s strategy, does it differentiate the Bank, and is the demand for the capability increasing?

• Business performance: Is the performance of a capability excellent, inconsistent, or poor in terms of the Bank’s needs and relative to competitors? How much investment is necessary to raise performance to the required level? Would the higher performance justify the investment?

• Leverage: Is the capability a candidate to be leveraged or offered as shared services including using alternate sourcing / partnering arrangements? Would improving the capability result in benefits for other capabilities?

• Technology: How dependent is the capability on IT? How mature are the technologies that support the capability? What level of management or control should be applied to the technology supporting a specific capability?

• Investment priority: How much does a proposed project contribute to addressing the areas identified as needing attention? Are the stakeholders impacted by changes to the capability ready to assimilate the change?

The Heat Map is focused on supporting the architecture planning processes: • What are the capabilities requiring attention (e.g., critical to business, poor performing,

can be leveraged to other parts of the organization)? • How much do the planned initiatives address the areas identified?

The Heat Map can also support more focused, initiative- or capability- specific questions: • How mature is the Enterprise Architecture or Business Architecture within the capability? • For the capabilities requiring architecture attention, which dimension appears to be the

primary focus for improvement (business, human resource, information, application, technology)?

• How should the solution be architecturally configured (enterprise vs. group vs. individual)?

• How do some of the lower-level capabilities perform and how does their complexity impact the rollout strategy?

• Which capabilities deserve the greatest attention from the EA team? However, it is important to realize that the heat map is strictly a tool for identifying areas for attention. By providing an overview of all the activities in a business, it can help managers throughout the organization agree on priorities for an improvement program. However, it does not replace the need for a formal portfolio management process.



Complementary to the use of Heat Maps as a planning tool, Portfolio Management is more focused on resource allocation, relying on analytical approaches other than heat maps in order to answer the following questions: • Which initiatives will deliver the highest value? • Which resources should get allocated where? • Should an initiative continue to get funding based upon its overall performance It is also important to recognize that many of the questions pertain to operational performance. However, it is essential that the managers reviewing the heat map do not look upon it as an operational dashboard. Operational reviews of performance, including portfolio reviews, are likely to be conducted at least monthly. However, the heat map will be generated at most quarterly and often only annually as part of the capital and administrative budgeting process. The key questions that management will use to assess priorities are: Business Value - What level of business value does the capability deliver?

• Does the capability differentiate• Is the capability a

Bank products and services? key contributor

• Is to the Bank’s strategic goals?

demand

for the capability increasing?

Performance - Is the capability performing well or poorly? • Is stakeholder satisfaction• Is the capability

with the capability at a satisfactory level? efficient

• Does the capability meet the ?

compliance

requirements?

Leveraged - Is the capability a candidate to be leveraged? • Is the capability predictable• Is the capability

? integrated

• Does improving the capability ?

enable improvements

to other capabilities?

Annual planning processes can also use Heat Maps to analyze the following questions in an effort to understand if proposed capital projects or initiatives are well aligned with identified business needs and priorities:

• What is the level of requested budget• Does the capability have the

for each initiative, by capability? capacity to assimilate

• What is the

the change (i.e. necessary resources to participate in and sustain the initiative)

relative return-on-investment

(ROI), by capability?

Heat Maps are also used for two other, more specialized purposes. 1). The Enterprise Architecture office and working group can use a heat map to understand architecture configuration and maturity. This use of a heat map answers the following questions: • What is maturity of EA/BA

• What is the

components (ie human resources, information, application and technology)?

consistency• How

of the capability? complex

• What is the is the capability (# suppliers, # vendors, # org’l units)

architectural configuration

of the capability (central vs. local)

2). IT management within ISG can use a different Heat Map to identify the highest areas of IT risk by understanding answers to the following questions:



• Which capabilities are heavily dependent on IT• Which capabilities require

? complex

• Which capabilities have the most IT IT applications and configurations?

problems reported• How

? mature

• Which capabilities have a are the IT platforms supporting the capability?

standard IT platform• Which capabilities have inappropriate IT support (e.g., lack sufficient numbers of

adequately trained resources)?

(e.g. none, some, fully shared)

5.2 Stakeholders for Heat Maps

Heat maps address information needs of the following Bank stakeholders:

– Tier 1: Strategic direction (e.g. ITGG) – uses heat maps to support investment allocation at the enterprise level.

– Tier 2: Right projects (e.g., EA Working Group) – uses heat maps to reconcile the degree to which proposed initiatives are aligned with business needs or to understand the capacity of a capability to assimilate a change.

– Tier 3: Oversight (e.g., OIS, Audit, EA Office) – uses heat maps to assess if there are specific capabilities that appear to present higher levels of risk to the Bank.

– Tier 4: Value delivered (e.g., SPMO) – uses heat maps to compare capability performance, leverageability, maturity, and IT risk ratings before and after an initiative has completed to help assess its success.

5.3 Definition of Heat Map Categories

The categories described in this section of the document allow stakeholders to identify capabilities or capability groups that meet criteria of interest. The following category groups have been identified to encompass the primary realm of analysis:

• Business Value

• Performance

• Leverageable

The categories that support the primary heat map categories are organized into the following groups, encompassing the secondary tier of heat map analysis:

• Assimilating the Change - the degree to which the capability is sufficiently mature to sustain a change, and the degree to which the Bank would benefit from its improvement.

• Maturity – degree to which documentation and implementation of information and technology systems meets Bank standards and industry best-practices.

• Information Technology – the degree to which IT successfully supports the capability

Within each of these heat map categories, the attributes defined in the table below include the following components:

• Category Description – articulates the purpose of the category and the business question it is intended to address.



• Attributes – the characteristics that the capability is measured against in this category, including clarifications (where needed) to describe how these characteristics should be interpreted.

• Anchoring of Values (e.g. scale) – the rating system used to apply a numerical value to an assessment of the attributes

• Data Collection and Data Sources – a description of where and how information can be collected to measure capabilities against each attribute in order to apply a rating

Section 5.7 provides a sample questionnaire that can be used with business users to assess the capabilities.



Table 1 below depicts the categories applicable to developing Heat Maps that support the Annual Planning process:

Table 1 - Annual Planning Heat Map Categories

Description Attributes Anchoring of Values Data Collection / Sources and Comments

BUSINESS VALUE Differentiation - criticality to key stakeholders, customer service delivery, relationship to Bank’s core, customer-facing capabilities

o Stakeholder facing vs not o Impact to Bank’s

reputation o Import to differentiate the

Bank’s value proposition (i.e. independent ratings / assessments / benchmarking against comp’s)

o Generates business (i.e. draws customers)

o Importance for successful delivery of stakeholder outcome

o # of successful new products produced that customers like (innovation)

o High Attention – Key stakeholder/Customer facing (core), impacts Bank’s reputation, differentiates Bank’s value proposition (i.e. independent ratings / assessments / benchmarking against comp’s), draws customers, required for successful delivery of customer outcome;

o Medium Attention – Policy setting and standard setting in a way that’s core to the Bank themes and sectors; develop talent and people (skills as a differentiator); IT infrastructure; sales and marketing; annual meetings;

o Low Attention – Enabling and governing capabilities wholly removed to the customer (facilities, food services, training, fitness centers, other GSD);

o Bank “iPhone” chart o Market research o Independent market

assessment(s) o Customer feedback survey(s) o Departmental business plans o New product listings




Strategic Alignment - Criticality to realization of strategic initiatives

o Fully supports or fundamental to realization of the strategic objective;

o High Attention – Fully supports or fundamental to realization of the strategic objective(s) (if a capability supports multiple objectives, it would also be high);

o Medium Attention – Enables or partially required for the realization of the strategic objective(s) (expert judgment required if a capability partially enables multiple objectives);

o Low Attention – Does not contribute;

o Bank strategic objectives / strategic plan

o Expert judgment of Level 0 and 1 capabilities against objectives

Stakeholder Demand - Stakeholder demand for the capability

o relative throughput change (year to year),

o # of repeat customers (year to year),

o # of transactions (year to year)

o change in budget or staff (year to year);

o High Attention - 5% or better improvement, year to year

o Medium Attention - -5% to 5% change, year to year

o Low Attention - 5% or worse degradation, year to year

o Production volume information o Customer (volume) data o Budget data for organizational

units (and then applied to capabilities they support)

Note – predictability, under analysis, should often be viewed with organizational complexity to see what’s isolated and predictable vs. what’s not.

PERFORMANCE Performance / Service Levels - Capabilities Performance / Service Levels

o Client level expectations (i.e. customer satisfaction ratings, timeliness of delivery, SLAs)

o High Attention – consistently miss performance expectations

o Medium Attention – inconsistently meet expectations

o Low Attention – consistently meet or exceed client level expectations

o Organizational performance information (Balance Scorecard (BSC) – Client)

o Customer feedback surveys o Control performance

information




Efficiency - Efficiency of the Capability

o Existence and measurement of service level (i.e. % of performance targets achieved, including quality)

o Ability to address control needs

o Ability to deliver on time, within budget, within scope;

o High Attention – capability consistently and significantly underperforms with respect to time, budget, and scope.

o Medium Attention – delivery varies with respect to time, budget, and scope;

o Low Attention – consistently delivers on time, within budget, within scope;

o Organizational performance information (Balanced Scorecard (BSC) – Internal Business Process)

o Control performance information

o Capability performance data (likely to be aggregated based on analysis of supporting organizational units’ performance data)

o HR data o Financial performance and

budget data o # reported IT issues o Customer feedback data

Compliance - Subject to compliance requirements

o Subject to laws o Subject to organizational

policies o Subject to government or

industry regulations o Subject to organizational

oversight

o High Attention – high level of oversight, significant numbers of laws, policies, regulations, etc., strong requirement for internal controls

o Medium Attention – some oversight, moderate number of laws, policies, regulations applicable; typical requirements for internal controls

o Low Attention – minimal oversight, minimal numbers of laws, policies, regulations, etc., minimal levels of internal controls required

o (Understanding of) laws and industry regulations that impact capability

o List of Bank policies o List of Bank organizational

charter(s) o Charters of committees

involved with capabilities

LEVERAGEABLE




Predictability - Predictability of the capability11

o Standards level, o Controls level, o Maturity level, o Service level definitions, o Quality levels and

consistency, o (if performed across

business units) consistency

o High Attention – Strong standards, strong controls, highly mature, defined service levels, consistent quality, (if performed across business units) performed consistently

o Medium Attention – reasonable standards, some controls present, less mature, inconsistently service levels, reasonable quality, (if performed across business units) performed with some consistency

o Low Attention – poor standards, few controls present, immature processes, undefined service levels, inconsistent quality, performed differently across business units

o Organizational performance information (BSC)

o Standards documentation o Service level agreement(s) o Quality requirements and

monitoring procedures o Cross-comparison of

organizational performance data (to measure consistency)

11 The answer to the “predictability” question is important because if the outcomes are highly unpredictable, the activity (or at least its user interface) will be difficult to automate. If it cannot be automated according to SOA guidelines, sharing it with other divisions or shifting it to customers or suppliers will be difficult.




Integrated – Capability is commonly utilized

o # of occasions where capability is reused to support other capabilities

o High Attention– capability is utilized in a number of other places, if it is unavailable or performing badly many capabilities would be impacted

o Medium Attention – capability is reused in a few places, but if it is unavailable or performing poorly the related capabilities continue to function with minor impact

o Low Attention – capability is highly isolated and is not shared with other capabilities

o Capability usage analysis within the business architecture

Capability Dependencies - Dependence of other capabilities on the capability

o # of capabilities that will be improved if a single capability is improved

o (of those improved) – to what degree will they improve

Example – enabling capabilities will enhance many other capabilities

o High Attention – many capabilities improved if a single capability improved

o Medium Attention – some capabilities are improved

o Low Attention – no other capabilities are improved

Need to define threshold for successes

o Capability dependency analysis within the business architecture



The table below depicts the categories applicable to developing Heat Maps that support analysis of the degree to which proposed initiatives support identified business needs:

Table 2 - Initiative Alignment Heat Map Categories


ALIGNMENT BETWEEN PROPOSED INITIATIVES AND CAPABILITIES Requested Budget - capital budget levels

o Requested Budget Amount

o $ (relative, analyzed by capability)

o Approved capital budget(s)

ROI - Return on Investment Per Capability

o Return-on-investment value(s)

o Difference between expected (planned) ROI and actual ROI

o Capital project CBAs o (Ability to analyze) Benefits

related to individual capabilities Notes – 1) is data available to produce it (i.e. CBAs) and 2) how would it be bounded in a heat map (many capabilities improved on a cross-cutting basis)

Capacity to Assimilate - Capacity of the capability to support and enable the change

o Availability and willingness of Bank to set resources aside

o Presence of a business / project plan that includes: costs, time, resources, and business case

o Number of initiatives contained within a capability

o Successful history of project implementations

o High Attention – “yes” to availability of resources, with 1 initiative contained

o Medium Attention – some availability of resources and/or 2 or 3 initiatives within a single capability

o Low Attention – inadequate availability of resources and 3+ initiatives within a single capability

o Enterprise resource planning data

o Project de-brief or close-out documentation

o Interviews or discussions with business owners

o Business cases or project management plans



Table 3 below depicts the categories applicable to developing Heat Maps that help analyze the architectural maturity of individual business capabilities:

Table 3 - Architectural Maturity Heat Map Categories


MATURITY BA Maturity – maturity of the capability’s business architecture

o Components defined o Components understood o Components appropriately

owned / used by the business to drive implementation of change (with IT)

o High Attention – Components partially or not defined

o Medium Attention – Components somewhat defined or defined but not used/owned consistently

o Low Attention – Components defined as well as understood and owned/used by the business to drive implementation of change (with IT)

o (Review of) available BA components

o (Analysis of) business understanding of BA components

o (Observation of) business’s use of BA to work with IT

Human Resource Maturity – maturity of the capability’s HR layer

o HR Components defined for the capability

o HR Components understood

o HR Components appropriately owned / used by the business to drive implementation of change (with IT)


o Medium Attention – Components somewhat defined or defined but not used/owned consistently, somewhat or inconsistently used to drive change


o (Review of) available EA components

o (Analysis of) business understanding of EA components

o (Observation of) business’s use of EA to work with IT




Information Resource Maturity – maturity of the capability’s HR layer

o Information components defined for the capability

o Information components understood

o Information components appropriately owned / used by the business to drive implementation of change (with IT)







Application Resource Maturity – maturity of the capability’s HR layer

o Application components defined for the capability

o Application components understood

o Application components appropriately owned / used by the business to drive implementation of change (with IT)










Technology Resource Maturity – maturity of the capability’s HR layer

o Technology components defined for the capability

o Technology components understood

o Technology components appropriately owned / used by the business to drive implementation of change (with IT)







Complexity - Complexity of the capability

o # of suppliers o # of external

dependencies o # of organizational units

involved o volume of regulatory

oversight and compliance o Degree to which skills

required to perform the capability are unique to the needs of the Bank’s mission

o High Attention – large number of supplies / external dependencies, multiple organizational units, high-level of regulatory oversight or compliance requirements.

o Medium Attention – typical number of supplies / external dependencies, one or two organizational units, typical level of regulatory oversight or compliance.

o Low Attention – minimal number of suppliers / external dependencies, single organizational unit, low levels of regulatory oversight or compliance.

o Capability supplier list(s) o Capability (service and

product) vendor list(s) o HR models for the capability o Rating / value associated with

Compliance category o List of job titles and ratio of

internal vs. external resources supporting capabilities (using HR data)




Architectural Control - Geographic location of capability delivery

o Centrally configured vs. mixed configuration (central and regional) vs. exclusively regional configuration

o High Attention – central function requiring high-level of investment and standardization across the bank;

o Medium Attention – partially centralized ;

o Low Attention – local function with little or no integration with other centralized Bank activities;

o SME analysis of geographic distribution supporting capabilities



Table 4 below depicts the categories applicable to developing Heat Maps that help IT management analyze the performance, risks, and maturity of the IT environment supporting a capability:

Table 4 - IT Performance, Risk, and Maturity Heat Map Categories


INFORMATION TECHNOLOGY IT Reliance - Importance of information technology to the capability

o Degree of capability reliance (operations suffer, shut-down, etc)

o High Attention – Capability critically disabled, severe loss of operational capacity, shut-down, etc.

o Medium Attention – Capability moderately impacted, some but not all business activities continue

o Low Attention – Capability marginally impacted, business activities continue, manual workarounds sufficient with minimal or “acceptable” delays

o Registry of IT resources identified within a business capability model

o SME analysis of critical capabilities against critical applications

IT Volume - Volume of use of IT within the capability

o # of IT systems / applications

o High Attention – capability uses over X IT systems

o Medium Attention – capability uses between Y and Z IT systems

o Low Attention – capability uses less than Z IT systems

o Registry of IT resources identified within a business capability model

Note – ideal to understand Volume per community of users. Also, answering this question implies understanding a full view of the EA;




IT Issues - IT Problems per Capability

o # of reported IT issues o of those reported –

severity of IT issues

o High Attention – lots of problems o Medium Attention – some

problems o Low Attention – little or no

problems

o IT helpdesk metrics Note – ideal to understand problems per volume of IT per community of users ; need to define scale, also important to understand criticality of problems reported; recommend doing on an annual basis (?) with some trend analysis

IT Maturity - To what degree is capability supported by mature, standard platforms?

o Fully mature o Bank-standard o Aligns with Bank’s

technology standards and direction(s)

o High Attention – fully mature, Bank-standard, aligns with Bank’s technology standards and direction(s)

o Medium Attention – somewhat mature (ad-hoc customization in areas), generally aligns to Bank’s standards

o Low Attention – immature and frequently not Bank-standard and/or technologies are generally not supported by ISG

o Bank IT standards o Analysis of application and

technology models with Bank standards

o Review of application maturity within capability

IT Platform – capabilities that share or operate on an independent platform

o Degree of platform sharing

o High Attention – Capability operates on a fully shared platform

o Medium Attention – capability operates on a somewhat shared platform

o Low Attention – capability operates on fully independent / none-shared platform

o Application models o Documented relationships

between applications and capabilities




IT Skill Types – degree of risk associated with support of the capability IT resources

o Unique nature of skills required

o Resources available to support

o Relative “current-ness” of systems

o Documentation available on systems

o High Attention – insufficient resources available, significant / boutique skills requirements, outdated systems (no longer supported, companies gone under) used, lack of documentation

o Medium Attention – resources available, moderate skills requirements, many systems up-to-date, some documentation

o Low Attention – resources available, widely-available skill-sets, current systems, extensive documentation

o Application models / registry with contact people, version information, and indication of available documentation

o (Potentially) interviews with support staff



5.4 Approach to Generating Heat Maps

This section describes the approach to generating Heat Maps at the Bank. 5.4.1 Standard maps Figure 5.1 summarizes the key categories and the application of the ratings to arrive at the areas requiring specific architecture attention.

Dependency

Integrated

Predictable

Compliance

Efficiency

Service Level

Demand

Strategic

Differentiation

HighAttention

MediumAttention

LowAttention

Category

PerformanceImprovementOpportunity

Critical to Bank

Sourcing / Automation Opportunity

ValueValue

PerformancePerformance

LeverageLeverage

Figure 5-1 - Heat Map Category Ratings

Though the categories defined above afford the opportunity to generate a wide variety of heat-maps and analyze capabilities across a multitude of different dimensions, there remain a few basic questions that can be considered the standard set of evaluation criteria to be applied. This section identifies that standard set of questions and indicates the filters that need to be applied to answer the requisite business question.

ENTERPRISE PLANNING HEAT MAPS:

• Heat Map 1 – Management Strategy for Investment Allocation o Business Question – What core Bank capabilities are related to the

organization’s strategic objectives and need to be addressed to improve performance?

o Filters – Business Value (in aggregate), then Performance (in aggregate), then Leveragability (in aggregate)

o Level of Application – applied to Level 0 and, as-needed, Level 1 of the Business Architecture



• Heat Map 2 – Alignment of Initiatives to Investment Needs o Business Question – To what degree are the proposed capital projects aligned

with the identified needs of the organization (developed in Heat Map #1) o Pre-requisite – Completed version of Heat Map 1 o Filters – requested budget, capacity to assimilate, and relative return-on-

investment (by capability) o Level of Application – applied to Level 0 and, as-needed, Level 1 of the

Business Architecture

INITIATIVE PLANNING HEAT MAPS:

• Heat Map 3 - EA Maturity o Business Question – How mature is the level of architecture within a Bank

capability? o Filters – EA maturity, BA maturity, capability consistency, complexity of the

capability, and/or architectural configuration (location) of the capability NOTE – no more than 3 of these filters should be used in any one heat

map, in order to simplify aggregate presentation. o Level of Application – applied to Level 1 of the Business Architecture (within

the context of a particular initiative or series of initiatives)

• Heat Map 4 – IT Risk and Needs o Business Question – How exposed to IT risk are different Bank capabilities? o Filters – IT dependency, IT complexity, # of IT problems reported, maturity of

IT platforms, standardization of IT platforms, and/or (adequacy) of IT resource support

NOTE – no more than 3 of these filters should be used in any one heat map, in order to simply aggregate presentation.

o Level of Application – applied to Level 1 of the Business Architecture (within the context of a particular initiative or series of initiatives)

5.4.2 Interpretation of data It is important to realize that the information represented by the map is not always “good” or “bad.” The goal of the heat map is to compare investment opportunities based on different questions and categories of analysis - to inform where people should be focusing their attention. For example:

• High business value is going to have a rating that indicates it demands attention.

• Capabilities that demonstrate immature predictability and immature IT will also receive an indication that they need attention.

• Capabilities that have strong governance and compliance will receive an indication that they need attention.

Conversely, attributes such as “non-core, well-functioning, lacking complexity” are all indicative of a capability that may not merit specific attention or investment. For example:

• If a capability is meeting performing expectations, analysis on that category will indicate that no attention is required.

• Similarly, analysis on the category of dependencies that yields a low rating would again indicate that no immediate attention or investment is required.



5.4.3 Presentation of data Heat maps use quantitative or qualitative data to apply a rating for each attribute in the table above. This section describes how those ratings can be analyzed and aggregated to make a judgment about the question at hand (business value, performance, maturity, etc). A spreadsheet has been developed, shown in Figure 5-2, for architects to assign an “architectural attention” rating to individual capabilities.

Figure 5-2 - Heat Map Calculator Template

Note that the architect fills out a value in each of the 9 sub-categories for the primary heat map (architectural attention), and these values aggregate (through calculations embedded in the template) to a quantitative result. The Architect applies a rating of high (h), medium (m), or low (l) to the business value, performance, and leveragability categories. The scales highlighted in yellow – both the values of high vs. medium vs. low as well as the relative “importance” ratings of business value vs. performance vs. leveragability – can be adjusted by the architect based on the business problem being addressed or the need to conduct “what-if” analysis. Applying a rating to each of the individual criteria creates an aggregate value as illustrated in Figure 5-3 below. The formula used to calculate this aggregate rating sums the following three calculations into a single, overall value:

Capability Biz Value Attention Rating (h = 9, m = 3, l = 1) * Biz Value Significance Weight (= 3), plus

Capability Performance Value Attention Rating (h = 9, m = 3, l = 1) * Performance Significance Weight (= 2), plus

Capability Leveragability Attention Rating (h = 9, m = 3, l = 1) * Leveragability Significance Weight (= 1)



Note that both the attention rating scale (h=9, m=3, l=1) and the weight of each category (business value, performance, and leveragability) can be adjusted within the template. The individual attention ratings are calculated using the following formulas:

• Biz Value Attention Rating12

o If the sum of Differentiation + Strategic Alignment + Stakeholder Demand is between 0 and 2, Biz Value = Low;

:

o If the sum of Differentiation + Strategic Alignment + Stakeholder Demand is between 3 and 7, Biz Value = Medium;

o If the sum of Differentiation + Strategic Alignment + Stakeholder Demand is between 8 and 9, Biz Value = High;

• Performance Attention Rating:

o If the sum of Satisfaction + Efficiency + Compliance is between 0 and 2, Biz Value = Low;

o If the sum of Satisfaction + Efficiency + Compliance is between 3 and 7, Biz Value = Medium;

o If the sum of Satisfaction + Efficiency + Compliance is between 8 and 9, Biz Value = High;

• Leveragability Attention Rating:

o If the sum of Predictable + Integration + Enabling of Other Capabilities is between 0 and 2, Biz Value = Low;

o If the sum of Predictable + Integration + Enabling of Other Capabilities is between 3 and 7, Biz Value = Medium;

o If the sum of Predictable + Integration + Enabling of Other Capabilities is between 8 and 9, Biz Value = High;

Figure 5-3 - Heat Map Calculator, Aggregate Values as Applied to Example

12 These scales can be adjusted using the template. Note that when the scales in the template are adjusted, the multiplier used to normalize the values on a 100pt scale will need to be adjusted as well.



Based on criteria selected and responses applied to each criterion, data should be interpreted according to the following scale13

• No color (rating of 0-25) – does not merit attention or investment

:

• Light Turquoise (rating of 25-50) – may merits some attention or investment

• Light Yellow (rating of 50 – 75) – definitely merits attention or investment

• Light Orange (rating of 75 – 100) – merits significant attention or investment Note that this template as well as the scale (described above) can be adjusted

based on the needs of the individual question being answered. The same template could be used, with slight modifications of headers and scale values, to handle the architectural maturity, IT risk, and readiness for change heat maps.

5.4.4 Adding new criteria This section describes the process for adding new criteria to be used in Heat Maps. The essential steps include the following:

• Identify a new heat map use

• Get approval from Chief EA that new map should be added:

that addresses a specific information need or augments the EA office’s planning and engagement model;

• Identify observable, measurable, or otherwise discernable attributes within a capability that can be used to address the information need;

• Identify criteria used to measure the attributes;

• Add the identified criteria to the method guide;

• Add the criteria to the EA resource model(s) so as to ensure they are captured / updated appropriately as each initiative is undertaken;

5.5 Example Heat Map

A summary of an example heat map, and the steps undertaken to produce it, appear in this section as a reference tool for staff producing heat maps in the Bank. In summary, the following stages were addressed:

• Assess Needs of Bank Capabilities – using the 2008 IDA-14 controls report findings, as well as EA staff member understanding of the Bank’s environment, a summary table was developed to assess business value, performance, and leveragability ratings (see Figure 5.4 below). These ratings were then overlaid on the high-level “Bank on a page” diagram.

13 It is recommended that this same scale be used for other heat maps as well, though of course the tolerance levels between points on the scale can be easily adjusted using the calculator template. For example, in some cases the Bank may choose to say that 0-35 does not merit attention or investment, etc.



Figure 5-4 - Table to Assess Bank Capabilities

• Assess Impact of ECDM – each capability was then analyzed in a separate spreadsheet to indicate high vs. low impact of ECDM programs across capabilities. A scale was developed to reflect which capabilities are critically, highly, and moderately impacted by the ECDM program components. Figure 5-5 below illustrates how this analysis was developed.

Figure 5-5 – Table to Assess Impact of ECDM Projects against Capabilities

• Integrate Heat Map of ECDM Impact against Needs – developed an integrated view of the needs of the high-level business capabilities against the impact of ECDM project components to those same high-level business capabilities. This visualization can help inform investment planning and the rollout strategy. Figure 5-6 below illustrates how this heat map might appear, using a color-scale to illustrate areas of high vs. low attention needs.



Figure 5-6 - Heat Map of Business Capability Needs

After this kind of attention/needs analysis is undertaken, the heat map presents an understanding of where resources (financial, human, and/or information technology solutions) should be applied within the Bank’s business capability environment. The next step is to perform a high-level analysis of the high-priority areas identified via the heat-map in order to elaborate a conceptual-level set of requirements. These high-level requirements would then drive the development of a business case and justification for moving forward with a new initiative.

It should be noted that this example is best applied for a project such as Enterprise Content and Document Management before any software solution has been purchased. The heat map in our example overlays high-level capabilities in need of architectural attention against those capabilities that would most benefit from the sorts of components an ECDM software solution offers. Such an analysis would inform investment planning and rollout strategies across capabilities that span multiple organizational units. 5.5.1 Supporting IT Project Portfolio Investment Decisions



The high-level map has also been used to assess the alignment of proposed IT capital investment to business needs. Figure 5-7 shows the allocation of IT capital funding for FY09-11 to each capability area.

Figure 5-7: Alignment of IT Capital FY09-11 to capabilities Figure 5-8 provides a summary of the relative level of investment by capability group.

IT Capital Project FY09-11

29%

1%65%

0% 2%3%

0%2 Advocacy

3 Convening

4 Advising

5 Financing

6 Implementing

7 Enabling

1 Strategy

Strategy

AdvocacyConvening

Advising

Financing

ImplementingEnabling

IT Capital Project FY09-11

29%

1%65%

0% 2%3%

0%2 Advocacy

3 Convening

4 Advising

5 Financing

6 Implementing

7 Enabling

1 Strategy

Strategy

AdvocacyConvening

Advising

Financing

ImplementingEnabling



Figure 5-8: Relative level of IT Capital Investment (FY09-11) by capability grouping Again the intent here is not to provide judgment whether the funds proposed are being invested appropriately. The intent is to indicate that as a planning tool one of the key requirements of enterprise architecture is that it drives capital investment by ensuring that the organization is investing in the right things to realize the business strategy.

5.6 Extending Heat Maps – Capital Investment and Planning Techniques

The results of the heat-map analysis can be used as a foundation to develop a consistent, Bank-wide approach to distribute limited organizational resources among competing programs or initiatives within the proposed IT capital portfolio. This distribution method applies conditions and business drivers of business owners to decision criterion so as to mathematically calculate the optimal funding levels within each of the Bank’s IT capital projects. In order to do achieve this result, the Bank can use the concept of “decision conferences” within its IT governance committees and tools built around statistically-sound decision-theory to aid decision makers. The broad steps associated with this work, and its relationship to heat-mapping, include the following steps:

1. Build a shared understanding of the key issues where proposed IT-related programs and initiatives must compete for scarce organizational resources.

This is accomplished via Heat Mapping – to identify the areas where improvements are needed.

2. Pre-work by a subject matter expert works to capture in a logical, transparent, malleable decision model all of the options, possible outcomes, costs and benefits that are relevant for evaluating alternative uses of limited resources against the organization’s objectives.

The capability categories within the heat-maps become the foundation for this decision model.

3. Use the model to narrow (through minimal effort and the use of a decision-theory tool) tens of thousands of possible combinations of allocations to proposed programs and initiatives down to the few combinations that would likely provide the most overall value per unit of resource invested.

Data entry by the decision makers is minimized by understanding key drivers and making those variables the ones used to drive alternatives.

4. Reveal which envisaged capabilities or services should be added to initiatives or programs if more resources become available, and which should be postponed or abandoned if budgets are reduced.

Differentiate between 100% gold-plated or straight-lined 80% fulfilled vs. a more intelligent allocation of resources.

5. Update and re-run the allocation model as conditions change, more information becomes available, new initiatives are proposed or older ones are completed or abandoned.

Conduct quick “what-if” analysis.



5.7 Heat Map – Business Questions

1 Business Value - Differentiation ResponseTo what extent does the capability contribute to the delivery of a product or service directly to a key Bank stakeholder?

High contribution Medium contribution Low contribution

To what extent does the capability contribute to differentiating the Banks value proposition? High contribution Medium contribution Low contributionTo what extent does the capability contribute to generating business for the Bank (e.g. new projects, customers)?


To what extent is the capability contribute to the successful delivery of a stakeholder outcome (e.g. timely repayment on a loan, successful implementation of technical assistance advice)?


To what extent does the capability contribute to the successful creation of new Bank products and services?


2 Business Value - Strategic Alignment ResponseTo what extent does this capability contribute to the realization of the Bank's strategic objectives? High contribution Medium contribution Low contribution

3 Business Value - Stakeholder Demand ResponseTo what extent is the demand for the capability increasing (e.g. relative throughput change, number of repeat customers, number of transactions, change in budget or staff)?

>5% -5%-5% <-5%

4 Performance - Service Levels ResponseTo what extent does the capability meet stakeholder expectations for performance (e.g., meeting service levels, timelines of delivery, stakeholder satisfaction rating)?

Consistently exceeds expectations

Inconsistently meets expectations

Consistently misses expectations

5 Performance - Capability Efficiency ResponseTo what extent does the capability operate under defined performance expectations and measure performance?

Measures defined and met Measures defined but not met

Measures not defined

To what extent does the capability address the control requirements? Controls defined and applied Controls defined but not applied

No controls

To what extent does the capability deliver on-time, within budget, within scope? Consistently exceeds expectations

Inconsistently meets expectations

Consistently misses expectations

6 Performance - Compliance ResponseTo what extent is the capability subject to compliance requirements (subject to laws, policies, government or industry regulation, or organizational governance)?

High level of oversight Some oversight Minimal oversight

7 Leverage - Predictability ResponseTo what extent does the capability result in consistent quality of performance when delivered in different environment, by different business units or to different stakeholder groups?

High level of consistency Some consistency No consistency

8 Leverage - Integration ResponseTo what extent is the reused to support other capabilities? Heavily reused Reused in a few places IsolatedTo what extent does this capability impact other capabilities (if it was unavailable or performing badly how many other capabilities would be affected?

Many capabilities impacted A few capabilities impacted No capabilities impacted

9 Leverage - Capability Dependencies ResponseIf the performance of this capability is improved to what degree will other capabilities be improved?

Many capabilities improved A few capabilities improved No capabilities improved

Options

Options

Options

Options

Options

Options

Options

Options

Options



6 Roles and Responsibilities

The roles and responsibilities for Business Capability Modeling are divided into two distinct categories: Business Capability Method Framework and Business Capability Model management. As the guiding principle behind developing Business Capabilities is to enumerate on elements of the business that are more stable over time, it is anticipated that the management of the models and the framework will require fewer lifecycles than a process mapping effort of a similar scope.

6.1 Business Capability Method Framework

The Enterprise Business Capability Method will be owned by the Enterprise Architecture team, including the Capability development framework, deliverables, and training materials. The Enterprise Architecture team will assume responsibility for the management of these materials as well as ensuring longevity of the process through annual reviews and other revisions per Bank strategy. The roles and responsibilities related to the Business Capability Method Framework are outlined in the following table: Role Personnel Responsibilities Method Framework Ownership Group

Enterprise Architecture (EA) Team

• Maintain version control of the Framework documentation including training materials and all job aids

• Perform an annual assessment of the method applicability and initiate necessary changes to the structure and process

• Review and evaluate changes to the Framework

Method Advisory Team

Business Architecture Working Group (EA, BPT, and select business owners)

• Advocate for the use of the Method in other initiatives

• Communicate benefits of the Framework • Identify opportunities for improvement to

the Business Capability Method Framework

Framework Development Team

Comprised of EA team, Others as identified

• Update the BCM Framework at the request of the Model Framework Ownership Group

• Coordinate changes to the Framework with other areas of the business and enterprise architecture

• Leverage Subject Matter Experts as needed

6.2 Business Capability Model Development

At the Enterprise Vision phase, the architecture segments and business capability areas need to be validated a representing the key components of the business architecture for the whole organization. This requires participation from all business sponsors, senior management and specific subject matter experts. The models themselves are built by the business partnership teams supported by the enterprise architecture office. These responsibilities are described in the table below.



Role Personnel Responsibilities Business Sponsor

Business Leaders • Provide strategic direction to the team • Secure commitment of resources to

support the model development • Facilitate the generation of consensus

around the models Subject Matter Experts

Managers and Individual Contributors from the Capability Area

• Provide documentation and expertise on processes, performance measures, and supporting resources

• Participate in meetings and model development sessions

• Review and evaluate deliverables Capability Facilitator

Business Partnership Team (BPT)

• Lead the development of the Business Capability Area and Sub-Area(s) by following the standard method

• Facilitate meetings and model development sessions

• Select and apply appropriate techniques (such as environmental scanning)

• Utilize resources and expertise provided by team members

Enterprise Architects / Architecture Working Groups

Enterprise Architecture (EA) Representatives

• Provide strategic context and expertise in the development of Business Capability Models

• Provide documentation and expertise on technology and systems supporting the Capability Area

• Lend expertise to opportunities, issues and constraints posed by technology


Business Architecture Model Management

Business Partnership Team

• Maintain existing models • Communicate benefits of the Business

Architecture

For each Business Capability Area, a more detailed model of the comprising Business Capabilities should be developed during the Initiative Vision phase. These detailed Capability Models are developed by cross-functional teams made up of both business and information technology (IT) representatives as illustrated in the table below. There is also a role to ensure that the models created as part of the Initiative Vision are integrated into the overall Enterprise Business Architecture. Role Personnel Responsibilities Initiative Sponsor

Capability Area Leader or Designated Representative

• Provide strategic direction to the team • Secure commitment of resources to

support the model development • Facilitate the generation of consensus

around the models Subject Matter Experts

Managers and Individual Contributors from the

• Provide documentation and expertise on processes, performance measures, and



Role Personnel Responsibilities Capability Area supporting resources


• Review and evaluate deliverables

Capability Facilitator

Business Partnership Manager (BPM)

• Lead the development of the Business Capability Model by following the standard method

• Facilitate meetings and model development sessions

• Utilize resources and expertise provided by team members

• Serve as the project manager for the Business Capability Model development within the targeted Capability Area

• Develop Project Schedule • Set meeting schedule

IT Specialist IT Representative with strong knowledge of systems supporting the Capability Area

• Provide documentation and expertise on technology and systems supporting the Capability Area

• Lend expertise to opportunities, issues and constraints posed by technology


• Review and evaluate deliverables Business Architect

Enterprise Architecture (EA) Representative

• Provide strategic context and expertise in the development of Business Capability Models

• Ensure scope of team Business Capability Model development is bounded and relevant

• Validate team deliverables and work products to ensure they align with the business architecture

• Ensure horizontal alignment across capability areas

• Ensure vertical alignment to other work streams and EA components (information, technology, applications)

Business Architecture Model Management

Business Partnership Team

• Identify new areas for Business Capability analysis

• Perform an annual assessment of the Business Capability Models and initiate BCM development teams as needed

• Maintain existing models • Communicate benefits of the Business

Architecture



7 Method and Model Governance

One goal of the Enterprise Architecture practice at the Bank is to establish “an institutionalized IT governance process to evaluate alignment with technology direction”. Information & Technology Governance Group (ITGG) is the legislative governance body reporting to the IPC and represents the Bank’s lines of business. The primary areas of responsibility of ITGG are to review and provide funding to IT projects, set policy and guidance related to IT, provide oversight to IT work program and budgets, and promote institutional awareness to the organization. The Governance process for the business capability models and business architecture leverages existing organization and governance structure to provide oversight and management to the Capability Modeling efforts across the Bank. The Business Capability Method, including the process by which Capability Models are developed, will be issued and owned by the Enterprise Architecture team. Changes or modifications to the Method or completed Business Capability Models will be managed through the governance process. The relationship between the main governance bodies is depicted in Figure 6-1.



Business Architecture GovernanceWorld Bank

Membership: Business Partnership Managers, Enterprise Architecture Team, Information Policy, Information Security, Enterprise Applications, Enterprise Technology, etc.Meets: As requiredMission: Review and approve the Enterprise Vision and make recommendations on funding for the creation of an Initiative Vision for the priority initiatives. Review and approve Initiative Visions and make recommendations on approving implementation budget. Monitor project execution health and make recommendations to adjust the project portfolio.

Architecture Review Board2.

Membership: Team lead and project team members Meets: As needed/weekly throughout Enterprise/Initiative Vision PhaseMission: Develop the deliverables of the Enterprise/Initiative Business Architecture. Liaise with the other groups to ensure consistency with other architecture components

Enterprise / Initiative Project Team5.

Membership: Line of Business BPMMeets: As requiredMission: Facilitate the development of the initiative business architecture and make sure the the business needs are captured

Business Partnership Manager (BPM)

3.Membership: Process Area OwnersMeets: As requiredMission: Review and approve business architecture. Commit business resources to participate in the project

Business / Initiative Sponsor4.

Membership: Voting Members both elected and assigned by Line of Business and Units, Line of Business RepresentativesMeets: As requiredMission: The executive decision making body for capital planning and IT investments Performs review and approval of business cases arising from work on the Enterprise and Initiative Vision and sets criteria for prioritization of initiatives for funding.

Information and Technology Governance Group (ITGG)1.

Figure 6-1 –Business Architecture Governance

Key decisions for these bodies are aligned with specific stage gate milestones in the Integration Framework. Figure 6-2 shows the key stage gates and the types of questions that the Architecture Review Board, through direction from the ITGG, is seeking to address at each stage.



Figure 6-2 –Stage Gate Decisions

8 Change Configuration Process

This section highlights the general procedures and principles necessary to establish and maintain consistency of the corporate Capability Model’s utility throughout its lifespan. These procedures apply to models developed either by Bank Staff or by external resources (consultants, contractors, etc).

8.1 Change Control Baseline

The first stage in the configuration management process is the identification of attributes and standards as a baseline for comparison. This document serves to meet some of those needs – notation standards, glossary of terms, model components, attributes of the model components, and field definitions in each of the Capability templates. In addition, the following baseline documentation (contained in Appendix 2) should be defined and referenced by the Bank:

• Master model repository – an electronic location for storage of completed and approved Business Capability Models. This repository would be subject to Change Control procedures.

• Repository management guidelines – a 1-page checklist for documenting decisions taken and artefacts chosen to be removed from or eventually returned to the Master repository. This ensures an ability to audit historical decisions and track the evolving nature of the repository over time.

• Model standards documentation – a comprehensive list of naming conventions, required attributes and samples of best-practice descriptions, model size and/or complexity guidelines, logic guidelines, etc.

• Reference guide for modellers – “best practice” advice on what differentiates a good model vs. a bad model. This should be revisited periodically, after each initiative.



• Training materials – the training course for business capability modelling within the overall curriculum of training for a business architect.

8.2 Business Capability Repository Change Control

The change control process involves taking information from, manipulating information within, or adding new information back to the Bank’s “master” Business Capability Model repository. Most typically these events are triggered by a new project or initiated when a change is required to an existing Business Capability Model. Change control during a project is most critical at the start, during the peer review process of primary deliverables, and during close-out. The key steps for each project stage are outlined below:

• Establish business need, At project kick-off – model initiation (or edits to existing model forms):

• Broadly define scope, • Engage EA office to develop Capability Model strategy (existing parts to be used,

new parts envisioned to be added) • “Check-out” sub-model components for manipulation

During peer reviews – EA office performs “QADuring project – model development:

14

o Notation ”

o Naming conventions o Logical structure o Review of descriptions o Completed templates

Align final model (both new additions and updates to existing components) to enterprise-level framework (and review for any potential changes or impact)

At conclusion of project – EA officer performs “Final QA”

o Review opportunities for Capability overlap or re-use across segments o Confirm any changes to the enterprise vision and Capability Areas

Review same elements included during the peer review QA Apply numbering scheme to model artifacts (diagrams and templates)

14 Standards document will need to be developed in concert with the EA Office and BA Review Board.

Check – Out – Diagrams, Templates, Requirements

Check – In – Diagrams, Templates, Requirements

Enterprise Master Business Capability

Repository

Project / Initiative Sub-Model



Store in the repository (maintain file naming conventions, diagram naming conventions)

o Diagrams and templates – store project files o Models and completed descriptions – store in BCM repository o All files - tie to IRIS records as-needed

More information regarding the Model Repository can be found in Appendix 2, Section 10.1.

8.3 Capability Model Notation

This section introduces the numbering scheme for Capability Models at the Bank.

• Level 1 – Architecture Segments – “#”. Example: 1 – Enterprise Business Management

• Level 2 – Capability Areas – “#.#”

Example: 1.1 – Corporate Procurement

• Level 3 – Capability Sub-Areas – “#.#.@” Example: 1.1.a. – Procure Goods and Services

Though many Capability Models will have a one-to-one relationship with Capability Areas and Sub-Areas, some models may also include parts of Capability Areas from a separate architecture segment. In these cases, the numbering scheme of the Capability Model should follow from the architecture segment that includes the majority of the Capabilities shown within the model. Using the example in Figure 4-1 from an earlier section in this document, then, the model would be numbered according to the Enterprise Business Management number scheme because 2 of the 3 depicted Capabilities are contained in the Enterprise Business Management architecture segment. More information regarding Capability Model notation can be found in Appendix 2.



9 Glossary of Terms

Term Description

Architecture Segment Highest grouping level in the Enterprise Business Capability Model, mapping to the lines of business within the organization. The segments are usually categorized into three main areas:

1. Direction – those functions that the business performs to create the organizations direction and guide the organization towards realizing its vision

2. Core – those functions that the business performs to deliver its products and services to its external customers

3. Enabling – those functions that the business performs to enable efficient, effective operations in the other areas

Business Architecture A logical framework for documenting and analyzing business functions and related objects in order to structure accountability over the individual aspects of the activities such as processes, data, systems, and organizations.

Business Capability What the business does to perform something of value to that business. Business Capability mapping is the process of modeling what a business does to reach its objectives (its capabilities), instead of how it does it (its business processes). The goal of this approach is to model the business on its most stable elements.

Business Capability Area

Level 1 drill down of the Architecture Segment that defines the primary groupings of work that directly support the delivery of products and services core to that Architecture Segment. This is the highest level of Capability within a business.


Defines the Business Capabilities associated with an architecture segment, including relationships across Capabilities, dependencies, objects, and resources. A typical Business Capability Model will include diagram(s), descriptive templates, and (for lower-level Capabilities) business requirements listings.

Business Capability Sub-Areas

Level 2 drill down from the Business Capability Areas that further define the groupings of work. It can be represented by a collection of individual Capabilities.

Business Capability Template

Form used by Capability Facilitators to ensure complete data capture during Capability Modeling projects

Business Intelligence Technologies, applications and practices for the collection, integration, analysis, and presentation of business information and (also, sometimes) of the information itself. The purpose of business intelligence is to support better business decision making.


Specification of what the business wants, typically expressed in terms of outcomes the activity generates rather than functions or specific operations any system or person will perform

Business Process A series of activities bringing about a result. A business process



Term Description

model describes how the business performs or implements the given Capability or how Capabilities connect to deliver a desired outcome

Capability Component An individual activity or process step within a Capability that contributes to the realization of that Capability. Capability components often have a one-to-one relationship with business or functional requirements, depending on the level of granularity at which the model is developed.

Capability Connector Links between Capabilities that focus on information exchange in terms of inputs (what is consumed) , outputs (products and outcomes) and controls (policies, standards, approvers, etc.).

Capability Diagram Visual depiction of the interaction between objects and Capabilities

Capability Key Decision , control, , or other attribute within the Capability chain that lies on the critical path to the primary output or outcome

Concept of Operations

A description, typically in both narrative and pictorial format, that characterizes the target state vision or an initiative vision in a more granular fashion to show the relationships between the main components and focuses on the functions and attributes of the system, mock-ups or prototypes of interface components, process descriptions, implications to roles and responsibilities, and policy changes.

Dependencies In the context of a Business Capability, other Capabilities or elements of Capabilities that can influence or are subject to influence

Enterprise Architecture

The alignment of information technology with business strategy, including integration and standardization of the relationships between various business entities with other layers of the architecture – strategy, information, application, and infrastructure.

Enterprise Vision An integrated view of the entire enterprise including relationships between the high-level business and IT components

Heat Map A graphical representation of data where the values taken by a variable in a two dimensional map are represented as colors.

Importance Indicates the future state importance of each Capability , which can be characterized as increasing, stable, or declining

Initiative Vision Defines a single initiative to a level of detail that would support its acquisition, including describing the high-level business and functional requirements for each initiative.

Integration Framework

A method for organizing and expressing the business, information, application and technology infrastructure architecture of an enterprise. The scope of the architecture described using the framework may be very large (for example, entire enterprise) or focused on a single solution or initiative. The level of detail in the description will increase as the scope decreases to focus on a single initiative.



Term Description

Lexicon Vocabulary and terminology that is specific to and critical for understanding and/or describing a Capability Area, Capability Sub-Area, or Capability itself

Model Standards Comprehensive list of attributes required for each model and the descriptions of these attributes to include naming conventions, required vs. optional fields, sample best practice descriptions, model size, complexity guidelines, and logic guidelines

Object Within a Capability Model, objects represent the physical or abstract resources of value in the categories of data, documents, service, knowledge, learning, people, communications or publications

Outcomes Expected results that a Capability will deliver to the customer as noted in a performance measure, either qualitative than quantitative

Outputs The physical or abstract resource of value produced by the Capability, often noted as an object on the Capability diagram

Repository Management Guidelines

Checklist for documenting decisions and artifacts chosen to be removed from or returned to the master repository

Resources People, Applications, and Data contributing to the realization of the Capability

Segment Category The architecture segment grouping of the Capability:

1. Direction – those functions that the business performs to create the organizations direction and guide the organization towards realizing its vision

2. Core – those functions that the business performs to deliver its products and services to its external customers

Enabling – those functions that the business performs to enable efficient, effective operations in the other areas

Tools and Techniques Job aids, training, methods, or localized best practices that enable the Capability

Work Products The deliverables associated with an initiative (at either the enterprise or initiative level) of a phase or task within an initiative. Work products typically take the form of documents, diagrams and tabular listings of descriptive content. The content of a work product varies according to the phase or task it flows from. The integration framework defines the structure and required content of each work product to varying levels of detail.



10 Appendix 1 – Business Capability Model Templates

10.1 Template I – High-Level Capabilities

The template below is used to describe Business Capability Areas (Level 2) as outlined in Section

Level 1 Capability <<Name>> Capability description A short description of mission/vision of the capability

Outputs (products/services)

A description of the main clients and the products/services delivered to them

Triggers A description of any suppliers and key input that is required for the capability to be provided

Business Value What level of business value does the capability deliver? • Does the capability differentiate

• Is the capability a

Bank products and services?

key contributor

• Is

to the Bank’s strategic goals?

demand for the capability increasing? Performance Is the capability performing well or poorly?

• Is stakeholder satisfaction

• Is the capability

with the capability at an acceptable level?

efficient• Does the capability meet the

? compliance requirements?

Leverage Is the capability a candidate to be leveraged in other parts of the organization? • Is the capability predictable• Is the capability

? integrated

• Does improving the capability ?

enable improvements to other capabilities?

Performance characteristics & resource issues

Provide a summaryl assessment of the efficiency and effectiveness of the capability plus any indicators or factors that should be considered as part of the performance improvement. These are often captured as constraints upon the resources such as cycle time, throughput, peak periods, volumes, resources available and costs.

Enabling Components Processes & Management Controls

Identify the specific processes and management controls (e.g. laws, policies, standards) that apply to capability. Identify the key performance indicators or other criteria used to measure the performance of the capability

Information Resources Identify by name the subjects and key entities from the enterprise information model that used by this capability. Designate the nature of the use in terms of create, update, read or delete. Note if this information is currently provided. Note any issues or specific considerations with regard to the information that could improve capability performance

Human Resources Identify the business unit that is responsible or involved in the



delivery of this capability. Designate the involvement in terms of RACI (Reviewer, Approver/Accountable, Concur, Informed). Identify the various personas that need to be considered by the concept of operations. Note any issues or specific considerations with regard to the human resources that could improve capability performance

Application Resources Identify by name the applications from the enterprise application model that support this capability. Note any issues or specific considerations with regard to the applications that could improve capability performance

Technology Resources Identify by name any specific technologies from the enterprise technology model that support this capability. Note any issues or specific considerations with regard to the technologies that could improve capability performance

Figure A-1 - Business Capability Area Template



10.2 Template II – Detailed Capability Analysis

The template below is used to capture Business Capability attributes outlined in Section 3.3 of this document.

Business Capability Model - Detailed TemplateWorld Bank - Business Architecture Development

Capability Team Facilitator (or designated author):

Date Created:Last Updated:

Vision/Mission

Capability Description

Dependencies (upstream / downstream)

Lexicon

Architecture SegmentCapability Importance

Issues/Risks

Parking Lot Ideas

Capabilities

Capability Components

OutputsOutcomes / Performance Measures

Resources

Tools & Techniques

ObjectsName

DescriptionCategory


State Representation As-Is / To-Be

<Business Capability Name>

Identify and document issues or risks pertaining to the capability documented in this template.

Identify and document issues or improvement opportunities gathered when defining this capability but that are NOT in scope for this capability.

Related Business Capability Areas: (Reference related Architecture Segments)

Figure A-2 - Business Capability Model Template



11 Appendix 2 – Model Reference Documents

Items in this appendix were finalized through the proof of concept (Task 2) and training process (Task 4) and amended to this document in June 2008. All of the items contained in this Appendix are available as stand-alone documents. The following documents are included:

• Repository Management Guidelines - describes a series of activities for documenting decisions taken related to the Business Architecture, removing artifacts from the Master repository, and eventually returning them to the Master repository. Activities related to repository management are described in the context of the Bank’s IT Capital Project lifecycle.

• Modeler’s Quick Reference Guide - This document identifies how a modeler should prepare for a Business Capability Modeling project and describes best-practices for creating and managing individual diagrams.

• Business Capability QA Checklist - This table describes a series of steps that should be taken during peer review and final quality assurance reviews of all business capability models.

• Business Capability Modelling – One page Reference Guide – the one-page reference guide is available with the BCM training materials in the Bank’s Enterprise Architecture Master Repository.

11.1 Repository Management Guidelines

Purpose This document describes a series of activities for documenting decisions taken and artifacts chosen to be removed from or eventually returned to the Master repository. This ensures an ability to audit historical decisions and track the evolving nature of the repository over time. Audience This document is primarily targeted at the administrators of the Business Architecture Master Repository. Related Documents and References • Business Capability Modeling Method Guide • Guide for Capability Modeling Standards (appendix within the Method Guide) Contents

Introduction and Context Business Architecture Repository Management and Procedures

o Stage I – ITGG Planning o Stage II – Architecture Review Board o Stage III – Project Initiation o Stage IV – Project Closure



11.1.1 Introduction and Context The repository management process involves taking information from, manipulating information within, or adding new information back to the Bank’s “Master” Business Capability Model repository. Most typically these events are triggered by a new project or initiated when a change is required to an existing Business Capability Model. In other cases, however, repository management can result from changes to enterprise objects or components that flow from the products of enterprise governing bodies such as the Information and Technology Governance Group (ITGG) and the Architecture Review Board15

This document provides an introduction to the sorts of tasks that are required at each stage of the repository management lifecycle:

.

o Enterprise Repository Administration – the maintenance of business components stemming from stages I, II, and IV of the IT capital project lifecycle.

o Project Lifecycle Repository Administration - the processes involved in initiating a project, removing a sub-model from the master BA repository, performing a mid-project review of the model, and eventually merging the model and its relevant artefacts back into the enterprise repository (stages III and IV).

15 For the purposes of this document, it is assumed the Architecture Review Board serves the following roles: 1) Makes actionable the recommendations of the ITGG with respect to specific budgets and allocations to different projects, and 2) serves as a project portfolio management body for the Bank. To the degree that the Bank has other roles that perform these operations, their names can be substituted in this document.

Stage I – ITGG Capital Planning

Stage II – Architecture Review Board

Stage III – Project Initiation

Stage IV – Project Closure

BA Repository Administration

Lifecycle

Figure 4 - Relating the Repository Management Lifecycle to Business Architecture Governance Stages



Business Architecture Repository Management Procedures 1. Stage I – ITGG Capital Planning

The ITGG capital planning stage includes the following activities (as defined in the Business Capability Modelling Method Guide): The executive decision making body for

capital planning and IT investments. Performs review and approval of business cases arising from work on the Enterprise Initiative Vision (strategic direction for the Bank) and sets criteria for prioritization of initiatives for funding.

As a by-product of this work, the following types of updates to the Business Architecture Master Repository could be triggered (note that all updates resulting from the ITGG’s work exist at the Enterprise level and are not applicable to the work products of individual projects): Business Capability and Sub-Capability Definitions – discussions about the work of

the Bank and its ongoing operations may illuminate a necessary change to the high-level business capability model. Once identification for such a change is made, it would need to be reviewed with the relevant business owners. If approved, the master model would then be updated.

Business Principles and Management Controls – review of individual business cases

within the ITGG may also highlight the need for a new or updated business principle (a change to policy or new management directive) as well as new or updated management controls (similar circumstances to the business principle). These set of changes would be reviewed by the Enterprise Architecture Office and updated, as needed, to the master model.

Common Enterprise Components – the Enterprise Initiative Vision may include a

strategic direction for the capture and review of a new or updated set of common enterprise components, such as standards around document integration, consistency of shared knowledge, workflow of transactional review procedures, etc. Awareness of this strategy impacts the planning of individual projects and the addition of new common components to the registry in the BA Master Repository.

2. Stage II – Architecture Review Board

The Architecture Review Board stage includes the following activities (as defined in the Business Capability Modelling Method Guide): Review and approve the enterprise

vision and make recommendations on funding for the creation of an Initiative Vision for the priority initiatives (as outlined in the ITGG). Review and approve Initiative Visions (individual capital projects) and make recommendations on approving the implementation budget. Monitor project execution and health and make recommendations to adjust the project portfolio.

As a by-product of the work of the Architecture Review Board, the following types of updates to the Business Architecture Master Repository could be triggered:

Stage I – ITGG Capital Planning

Stage II – Architecture Review Board



Enterprise Repository Administration:

Business Capability and Sub-Capability Definitions – (drivers leading to an update and the steps required to approve an update mirror those at the ITGG level).

Business Principles and Management Controls – (drivers leading to an update and

the steps required to approve an update mirror those at the ITGG level). Common Enterprise Components – (drivers leading to an update and the steps

required to approve an update mirror those at the ITGG level).

Project Lifecycle Repository Administration:

Business Capability Models – periodic review of projects, their scope, and their relationship to the high-level capability model may lead to a new or different understanding about the linkages among the lower-level capabilities and their high-level parent objects. In these cases the Business Architecture staff in the EA office would need to analyze the suggested changes or additions and, as-needed, make the relevant adjustments within the Master Repository.

3. Stage III – Project Initiation

The Business Partnership Manager, in conjunction with the Business Sponsor and the Project team, perform the following activities as outlined in the Business Capability Modelling Method Guide:

Facilitate the development of the initiative business architecture and ensure that the business needs are captured;

Review and approve the business architecture, and commit the resources to fulfil the project needs;

Develop the deliverables of the business architecture, and liaise with other project teams to manage dependencies, risks and points of interaction.

Within this context, the following types of interactions are typically required as part of the project initiation and implementation lifecycle:


Business Capability and Sub-Capability Definitions – identify a strategy for how the scope of the initiative will relate to the enterprise capability model, and use that model as an analytical too to help structure the project goals. Updates to the model may result from this analysis, and would need to be approved by business owners before they are implemented by the EA office.

Business Principles, Management Controls, and Common Components – review

the registry of enterprise principles, controls and components that are associated with the capabilities to be addressed within the project. Develop a strategy for their use within the development of project models and deliverables. Updates to the registries may also result from this analysis.

Stage III – Project Initiation




Business Capability Models – the following activities are performed: o Engage EA office to develop Capability Model strategy - existing parts of the

Master Repository to be used, new parts envisioned to be added o “Check-out” sub-model components for manipulation - capability diagrams and

completed templates o Identify business architecture artifacts of use for reference during the project:

o Enterprise capability diagram – the “Bank on a page” o Completed enterprise capability sub-area templates and diagrams o Registries of enterprise business components o Use-case or requirements examples

o During project – model development: peer reviews, EA office performs “QA16

o Notation ”

o Naming conventions o Logical structure o Review of descriptions and completed templates

Business Process Models – the following activities are performed:

o Engage EA office to develop Process Model strategy - existing parts of the Master Repository to be used, new parts envisioned to be added

o Identify business architecture artifacts of use for reference during the project: o Archived process or capability models o Use-case or requirements examples

o During project – model development: peer reviews, EA office performs “QA17

o Notation ”

o Naming conventions o Logical structure o Review of descriptions and diagram contents

16 Standards document will need to be developed in concert with the EA Office and BA Review Board. 17 Standards document will need to be developed in concert with the EA Office and BA Review Board.

Check – Out – Diagrams, Templates, Requirements

Check – In – Diagrams, Templates, Requirements

Enterprise Master Business Capability

Repository

Project / Initiative Sub-Model

Figure 5 - Overview of the Lifecycle of a Business Capability Master Model and Sub-Model



Use Cases and Requirements Documentation – extract the relevant Use Cases (including templates, if they exist) and Requirements documents (including templates, if they exist) for use during the project’s execution.

4. Stage III – Project Closure

The Business Partnership Manager, in conjunction with the Business Sponsor and the Project team, will have performed the following activities as outlined in the Business Capability Modelling Method Guide: Develop the deliverables of the business architecture, and

liaise with other project teams to manage dependencies, risks and points of interaction. Within this context, the following types of interactions are typically required as part of the project closure lifecycle:


Business Capability and Sub-Capability Definitions – lessons learned and the final, approved contents of the capability and process model(s) may identify a need to also update the contents of the enterprise capability diagram.

Business Principles, Management Controls, and Common Components – lessons

learned and the final, approved contents of the capability and process model(s) may identify a need to also review the contents of the enterprise principles, controls, and common components registries. Updates to the registries typically result from this analysis.


Business Capability Models – the following activities are performed: o Deliver completed model to EA office o Conduct final QA o Align final model (both new additions and updates to existing components) to

enterprise-level framework (and review for any potential changes or impact) o Address any changes to the enterprise vision and capability areas o Review opportunities for capability overlap or re-use across segments

o Merge model back into BA repository o Apply numbering scheme to model artifacts (diagrams and templates) o Store in the repository (maintain file naming conventions, diagram

naming conventions) Diagrams and templates – store project files Models and completed descriptions – store in BCM repository All files - tie to IRIS records as-needed

Business Process Models – the following activities are performed:

o Deliver completed model to EA office o Conduct final QA o Align final model (both new additions and updates to existing components) to

capability-level framework (and review for any potential changes or impact) -

Stage IV – Project Closure



address any implications to potential changes to higher-level capability diagrams

o Merge model back into BA repository o Apply numbering scheme to model artifacts (diagrams and templates) o Store in the repository (maintain file naming conventions, diagram

naming conventions) Models and completed descriptions – store in BCM repository All files - tie to IRIS records as-needed

Use Cases and Requirements – the following activities are performed: o Review project outputs and store, as-needed, relevant artefacts that add

value to the Master Repository for future reference or re-use



11.2 Modeller Reference Guide

Purpose This document identifies how a modeler should prepare for a Business Capability Modeling project and describes best-practices for creating and managing individual diagrams. Audience All internal Bank staff and consultants who develop Business Capability Model diagrams at the World Bank. Related Documents and References

Business Capability Modeling Method Guide Task 2 - Proof of Concept Deliverable for Business Capability Modeling Project

Contents

Modeling at the Bank Overview of Capability Models Getting Started Preparation for a Successful Project Tips and Best Practices Revision History

Modeling at the Bank Overview of Models A business capability is "what the business does to perform something of value to that business". This is in contrast to a business process, which describes how

the business performs or implements the given capability or how capabilities connect to deliver a desired outcome. Business capabilities describe the stable elements of the business to model your organization and provide the critical layer that aligns application services to business operations, and hence drives the development of a service-oriented architecture.

A business capability is expressed in terms of outcomes and service levels, to create value for the customer (who may be internal or external). Business-capability mapping is the process of modeling what a business does (its capabilities), to reach its objectives. Links between capabilities are defined as capability connectors that focus on information exchange in terms of inputs (what is consumed) and outputs (products and outcomes) and controls (policies, standards, approvers, etc.). The Enterprise Vision defines the Capabilities of the organization in levels 1 (architecture segments) and 2 (Capability Areas). These compose the essential elements of the “high-level” enterprise Business Capability framework for the Bank. In reality, however, most Capability Diagrams contain elements that cross Architecture Segments, or that cross Capability Areas within Segments. As a result, each Capability that is identified for modeling purposes needs to be analyzed by the Capability Facilitator18

18 See Section 5.2 of this document for a description of the role of the Capability facilitator.

in the context of this broader framework to ensure alignment across segments.



Getting Started Because there are many different staff and consultants modeling at the Bank, the Enterprise Architecture Office at the Bank has developed modeling best-practices to which all diagrammers and analysts are directed so that diagrams are consistent when they are merged into the Bank Master Repository. The process for modeling at the Bank requires that staff and consultants do the following:

Attend training

—the EA Office has BCM training available to consultants starting a major modeling effort in the Bank. The training is a practical, hands-on session covering use of the Business Capability Modeling approach and how to meet the Bank’s requirements.

NOTE - Timing and attendance for the training is critical: Project kick-off is often too early for modeler training. Training should be conducted as modeling is about to get started so the skills can be easily transferred. It is imperative that all modelers be present at the training.

Orient the Capability Framework with EA Staff

—The EA staff member overseeing the modeling effort will work with you to determine which previously developed diagrams residing in the Master Repository are associated with the modeling effort. Once these diagrams are identified, the EA staff member pulls the diagrams into a folder or workspace in which you create and modify diagrams.

Preparation for a Successful Modeling Project When approaching an As-Is or To-Be modeling project, it is important to have a good understanding of the following before you start diagramming:

Scope of the study—Know the goal of the study and how the modeling will support that goal. This will help keep the modeling on track, as frequently more information is provided by the client than is required for the specific study at hand. Breakdown of the major components of the process—Understand the major components of the process to be diagrammed, so you can determine how the process should be split up, or “chunked”, into separate diagrams. This will help you structure your data gathering around specific topics, and minimize the number of client participants that have to attend any one interview session. Appropriate level of detail for diagramming—Have a sense for how many processes and how much detail for each capability should be diagrammed. Will the documentation be at a high level (e.g., just identifying the main steps) or will it be at a more detailed level (e.g., showing handoffs and swim lanes more typical of a process model)? Knowing the level of detail will help guide the data gathering stage. Meaning of the different modeler shapes and notation—Know how to “read” a business capability diagram by knowing the shapes for capabilities, connectors, objects, and the contents of the underlying models. Modeling will be relatively easy if you have the shapes and notation in mind when gathering information from the client. A summary of the model notation scheme appears in Section 4.2.

Tips and Best Practices for Using Business Capability Modeling Planning your Diagram



Diagrams should be scoped using a top-down approach to the analysis. This allow the modeler to understand the “big picture” by identifying the beginning and terminating capability within the project scope, analyzing the capabilities between these boundaries, and developing a high-level model to illustrate this straw-man diagram.

Consider working off a single diagram at the beginning of the project to see inter-relationships among capabilities on a single view before creating detailed drill-downs of individual capabilities.

Diagram Descriptions & Names

Diagram descriptions should be in present tense and provide an overview of the capability shown in the diagram with any diagram-specific details.

Diagram names are usually the same as the capability name from which they drill down.

A detailed diagram description should be incorporated in the underlying capability template.

Higher-level or aggregate capability diagrams do not necessarily require a detailed capability template to be completed. This decision is left, initially, to the discretion of the modeler.

Diagram Titles

Diagram titles should appear on all process diagrams. Title boxes should appear in the bottom left corner of the diagram, aligned with the

near-corner of the canvas. The size of the title box should be made to fit the title text.

Diagram Appearance

The natural flow of a capability diagram output goes from left to right, top to bottom. Therefore, it is prudent (where possible) to arrange the objects on the diagram in order from left to right, top to bottom to minimize the amount of manual re-ordering of processes that must be done to finalize the Procedure Manual.

Diagrams must be scaled to be easily read. Test-print your diagram prior to completion to ensure it remains legible and printer friendly.

Diagram objects should constructed using the templates provided in the BCM Model Sample diagram, contained in the EA Master Repository.

So that all diagrams produced by staff and consultants have the same look and feel, the pre-defined diagram defaults should not be changed.

Diagram Version Control Boxes

A Version Control Box should appear on all diagrams A Version Control Box is added to the bottom, right-hand corner of the diagram. The Version Control Box should include the date created, modeler name, and date

last updated. Capabilities

Capability names should begin with a verb and end with a noun. Capability names should avoid any prepositions or forms of the verb “to-be” Capability names should avoid the use of the verb “perform. A list of

recommended verbs appears as an attachment to this document. Objects



Frame objects on the diagram so that when multiple objects serve as an input to a capability they overlap diagonally, descending downward.

Categorize objects according to the information architecture categories maintained by the EA Office. These same categories appear as legends on the diagram.

It should be up to the diagrammer’s discretion as to whether or not a free-text comment next to any one object helps add clarity to the diagram. Questions about the use of such comments should be direct to the EA Office.

Connectors

Connectors sometimes benefit from a description that articulates one of the following elements:

The object is only conditionally transformed by a capability, and that condition is not self-evident without a description;

The object is not consistently transformed by the capability, or is somehow “consumed” by the capability in a way that merits an explanation on the diagram;

The capability may reject the object, which is in turn re-submitted to the capability on an iterative basis – the condition that allows this iteration to cease may be worth highlighting.

In any of these cases, a description should only be added it provides a critical level of understanding to the reader and illuminates a critical component of the capability flow. A minimal volume of descriptive text is desirable on any connectors. It is equally desirable to minimize the number of connectors with a description.

Revision History © 6/18/08 First draft of bulletin



11.3 Business Capability QA Checklist

This table describes a series of steps that should be taken during peer review and final quality assurance reviews of all business capability models. # QA Process Step Outcome Findings

1. Before giving the checklist to new staff or consultants, indicate if any criteria will not apply

Document exceptions

2. Make sure that no non-standard object types or symbols have been added.

Document any unauthorized additions or exceptions and ask Enterprise Architecture officers if the non-standard items have already been approved.

3. Check that capabilities were captured correctly:

• Capabilities captured on more than one diagram are described consistently

• Capabilities follow the correct Verb Noun naming convention

• The first word of each capability is capitalized

• Capability names avoid references to technologies, people, or organizational units

Document any deviations from the standards.

4. Check for the following within each of the capability templates: • Capabilities without descriptions • Capability diagrams missing any of the

template header information • Capabilities without business

requirements • Acronyms listed on the capability

diagram are described in the capability template

Correct and fill any information gaps in the capability templates

5. Check that the diagrams are structured correctly.

List issues identified and proposals for



# QA Process Step Outcome Findings

• Diagram title in lower left-hand corner of the map

• Diagram version control box in the lower right-hand corner of the map

• Legend at the top of each diagram

• No “floating” objects or capabilities (objects or capabilities not connected to one another)

• Objects that serve as an input to a capability generally enter the left-hand side of the capability hexagon, and objects that are transformed by a capability generally exit from the right-hand side of the capability hexagon.

Check that the names of all diagrams are in the correct format.

resolution of each issue.

6. Check that diagram flows are logically correct.

• Objects that terminate at the end of a capability chain on one diagram are likely (thought not required) to begin as objects that initiation a new capability chain on another diagram;

• Objects that are transformed by multiple capabilities are adequately explained in the text of the diagram template;

• Non-bank artifacts and Bank physical artifacts appear in the correct symbol type and not as the more common rectangular object type.

List issues identified and proposals for resolution of each issue.

7. Validate that the model contents are filed and stored in the Enterprise Architecture master repository.



11.4 Business Capability Modeling – One page Reference Guide

This reference guide elaborates the purpose and key steps for each main activity within Business Capability Modeling, the best practices for execution, and the deliverables for each activity. Note: This document is formatted to Legal size for readability.



Business Capability Modeling – Project Lifecycle Reference Guide Purpose Steps Best Practices Work Products

Kic

ko

ff

• Understand the strategic context for the project

• Assemble a Project Team • Set the scope and target deliverables

1. Meet with the Project Sponsor to discuss the vision and timeline for the project 2. Identify Potential Team Members 3. Recruit and Assemble Team 4. Define Roles and Responsibilities 5. Determine Project scope

• Be practical on scope – set strong boundaries based on project timeline

• Keep team size limited to approximately 7 core individuals

• Draw out the project scope visually

• Meeting Notes from discussion with the Project Sponsor

• Team Member list with Roles and Responsibilities

• Project Scope diagram and narrative • High Level Project Plan

Inte

rvie

ws • Gather knowledge from team members

and other Subject Matter Experts • Document current practices and potential

improvements • Build enthusiasm for the project

1. Develop and prioritize a stakeholder interview list 2. Determine objectives for each interview and compose agendas 3. Schedule and conduct interviews 4. Document interview notes and validate with stakeholders

• Utilize interviews to communicate key project goals • Interview the stakeholders in order of knowledge

about the area • Focus more on the capabilities and the critical

inputs/outputs, less on the process • Keep interviews short and follow up as needed

• Interview list with rationale • Interview agendas with key questions • Interview notes with Follow up information • Initial draft of a “To Be” Diary containing

improvement ideas identified so far

Dia

gra

mm

ing

• Document the Business Capability in the form of Business Capability Diagrams

• Identify the capabilities, key objects, and their relationships

1. Use interview content and scope notes to develop strawman diagrams 2. Identify key objects for each Capability 3. Develop a diagram for each Capability (and as-needed, at a more aggregate level) 4. Validate the diagrams with stakeholders

• Brainstorm first on sticky notes or a dry erase board to develop strawman outline

• Use the modeling notation guide to limit rework • Work with a team member • Validate diagram drafts with stakeholders outside of

the workshops

• Capability Area diagram(s) • Capability diagram(s) for each Capability

Area • Identified capabilities, objects, and

relationships • Completed As-Is capability template(s)

Wo

rksh

op

s • Engage business owners, stimulate discussion, and garner buy-in

• Validate information gathered through interviews

• Discuss key issues and ideas • Develop a go-forward strategy

1. Plan purpose and schedule of project workshops 2. Set firm agendas and send invitations to key stakeholders 3. Prepare wall charts 4. Facilitate session(s) 5. Send follow up actions and notes

• Limit Workshops to 2-3 hours, and assume 2 hours prep for each 1 hour in session

• Utilize wall space versus handouts to keep discussion engaged

• Have a designated note-taker • Use sessions for validation and consensus building

• Workshop plan and schedule • Workshop agenda(s) • Wall charts • Meeting notes and issue documentation • Updated diagrams and templates

Co

nce

pt

of

Op

era

tio

ns • Develop a business vision for the future

state • Document key ideas and focus areas • Identify near term and long term

improvement opportunities

1. Perform a Gap Analysis on the As-Is Capabilities 2. Identify and prioritize improvement ideas from the customer perspective (sessions & interviews) 3. Gain consensus amongst team and key stakeholders 4. Develop To-Be templates and diagrams

• Focus on improving the customer experience (and understanding who the real customers are)

• Maintain a To-Be Diary to capture ideas • Scope and phase ideas into logical groupings • Be realistic and practical • Refer often to the scope of the project

• Updated To-Be Diary (improvement ideas) • Future state Concept of Operations • Phasing approach for improvements • To-Be Capability Diagrams • Narrative summary of key changes

(capabilities remain relatively stable)

Cap

ab

ilit

y D

ocu

men

tati

on

• Produce formal document summarizing the project work

• Provide historical records • Document metrics, lexicon, resources,

and tools used for each capability

1. Finalize the Capability Template (including all content attributes) for each capability 2. Validate with Stakeholders 3. Define Business Requirements 4. Obtain Sign-off and complete documentation

• Documentation is an iterative process that may require multiple revisions

• Speak & write in the language of the business • Identify key issues and downstream impacts for

each capability • Identify business requirements by translating

interview and workshop notes

• Completed Capability Templates • Documented business requirements • Documentation sign off • Finalized package of project deliverables

Task 1 - BCM Method_Guide v5e Final

Documents

Transcript of Task 1 - BCM Method_Guide v5e Final