Task 1 - BCM Method - Guide V5e Final
Task 1 - BCM Method - Guide V5e Final
Task 1 - BCM Method - Guide V5e Final
Reviewed By
Business Architecture Team EA Office EA Office EA Office World Bank - Project Manager World Bank - Project Manager World Bank - Project Manager
Version 5
Change Description Completed items in Appendix 2 based upon outputs from Tasks 2 & 4 Added Sections 4.2.1, 4.2.2, 4.3 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)
Page 1 of 86
Official Use Only Information Solutions Group The World Bank Table of Contents
1 2 3 4 5 6 7 8 9 10 11
INTRODUCTION .............................................................................................. 3 METHOD OVERVIEW ....................................................................................... 5 APPROACH .................................................................................................... 12 TECHNIQUES AND NOTATION ....................................................................... 19 BUSINESS CAPABILITY HEAT MAPS .............................................................. 31 ROLES AND RESPONSIBILITIES .................................................................... 58 METHOD AND MODEL GOVERNANCE ............................................................. 61 CHANGE CONFIGURATION PROCESS ............................................................. 63 GLOSSARY OF TERMS .................................................................................... 66 APPENDIX 1 BUSINESS CAPABILITY MODEL TEMPLATES........................... 69 APPENDIX 2 MODEL REFERENCE DOCUMENTS ........................................... 72
Page 2 of 86
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.
Page 3 of 86
Page 4 of 86
2 Method Overview
2.1 Introduction
In todays 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 initiatives 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 crosscutting 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:
Page 5 of 86
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 projects 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.
Page 6 of 86
Figure 2-2 illustrates the Integration Frameworks 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.
Page 7 of 86
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:
Page 8 of 86
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.
Page 9 of 86
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.
Page 10 of 86
Performance
Enterprise Mission, Vision & Objectives Extended Enterprise Value Chain Products & Services Outcomes Map (strategy map)
Business
Enterprise Architecture Segments Business Capability Areas Business Capabilities Business Principles
Business Capability Model Business Process Model Business Use Cases Functional Requirements
Human Resource
Organizational Culture & Principles Organizational Structure Organizational Roles Employee Personas Human Resource Relationships Matrix
Organizational Structure Organizational Roles Employee Personas Human Resource Relationships Matrix Initiative Change Management Strategy Initiative Communication Plan
Information
Information Principles Conceptual Data Model (Subject/Entity) Data Taxonomy & Dictionary Information Exchange Matrix Information Relationships Matrix
Logical Data Model (Subject/Entity/Attribute) Data Taxonomy & Dictionary Information Relationships Matrix
Applications
Technology
Technology Principles Technology Standards Technology Component Model Technology Component Relationships Matrix
Integration Plan
Target State Concept of Operations Target State Change Impacts Integration Sequence Plan Initiative Concept of Operations Initiative Business Case
Initiative Concept of Operations Initiative Change Impacts Initiative Transition Plan Initiative Business Case
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.
Page 11 of 86
Syst
Enterprise Vision
Initiative Vision
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.
Participants
Business Sponsors Business Managers Operational Subject Matter Experts Business Partnership Teams EA Office
Deliverables
Enterprise Architecture Segment Business Capability Areas Business Capabilities Business Principles
Page 12 of 86
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 analysis 1: 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. Affinity analysis 2: is a data analysis and data mining technique that discovers cooccurrence 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. Business scenario analysis 3: 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. Customer value analysis 4: 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. 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 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 Scorecard 5: 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) Porter, Michael, Competitive Advantage: Creating and Sustaining Superior Performance, The Free Press, 1985 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
1
Page 13 of 86
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:
Business Capability
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
Business Principle 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
Page 14 of 86
Figure 3-3 shows the key elements involved in developing the initiative business architecture.
Page 15 of 86
Participants
Initiative Sponsor Subject Matter Experts - Initiative Business Managers - Business Users Business Partnership Teams Enterprise Architecture Office Information Technology Specialists
Deliverables
Business Capability Model Business Process Model Business Use Cases Functional Requirements
Figure 3-3 Initiative Business Architecture Core techniques to support Initiative Business Architecture include: Stakeholder analysis 6 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. 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 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
Page 16 of 86
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
Use Case
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
Functional Requirements
Page 17 of 86
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 thats technologys implementation
Use Cases
Business Requirements
Business Process
Derived from
Derived from
Derived from
Functional Requirements
Technology Solution
Configuration Design
Solution Configuration
Solution Implementation
Page 18 of 86
See Section 5.2 of this document for a description of the role of the Capability facilitator.
Page 19 of 86
Capability Sub-Area: 1 - Procure Goods and Services 2 - Monitor Receipt of Goods and Services
Capability Diagram
Level 4 to n Capability
Requisition / SOW
Sample Capability Obtain and Pay for Goods and Services: From Order to Invoice
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 Banks 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 lenses 8, develop an initial model to define the main markets/clients and the highlevel products and services that are delivered to these markets / clients. Review this model with key business stakeholders for accuracy, relevance, and potential additions.
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.
Page 20 of 86
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 interviewees desired outcome from the project Review of Draft Capability Diagrams to orient each interviewee to the highlevel capability diagram Questions specific to the interview to clarify questions, fill gaps, and analyze capabilities
Page 21 of 86
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.
Page 22 of 86
Business value: o Does the capability differentiate the Bank and influence client satisfaction including whether countries desire the Banks 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 Banks 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 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: Primary: those capabilities that the Bank should keep in house and should be the top priority for performance improvement 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.
See Harvard Business Review: June 2008 The Next Revolution in Productivity
Page 23 of 86
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.
Page 24 of 86
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.
Page 25 of 86
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. 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: Descriptive Attributes Vision / Mission a brief statement of what the Capability intends to be (vision) or the purpose of the Capability (mission). 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 Banks 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) Individual Capability Attributes Outputs / Outcomes the vocabulary that is critical to the Capability 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 Individual Capability Attributes Business Requirement a description of the operation required for the business result to be achieved 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
Capability Model
Page 26 of 86
Official Use Only 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
Capabilities
Object Object
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.
Page 27 of 86
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 Capabilitys 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. K 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).
Page 28 of 86
Knowledge
Data
Services
People / Communities
Collections
Non-Bank Artifacts
Service 1 Communication 1
Knowledge Document 2
Document 1
Capability D
Community 1
Capability B
Document 3
Capability A
Capability C
Requirement Requirement
Capability Capability
Requirement Requirement Requirement Requirement
Capability Capability
Capability Capability
Object Object
Requirement Requirement
NEW Requirement REFINED Requirement Requirement Requirement Business Requirement Requirement Requirement REFINED Requirement Requirement Business Requirement Requirement
NEW Requirement
Requirement Requirement
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
Page 29 of 86
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 useful 10. 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.
Business Requirements and Use-Cases Systems Development Lifecycle
Business Capabilities
Functional Requirements
Kurt Bittner, Ian Spence (2002). Use Case Modeling. Addison Wesley Professional, 2-3. ISBN 0-201-70913-9.
10
Page 30 of 86
Page 31 of 86
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 Bank products and services? Is the capability a key contributor to the Banks strategic goals? Is demand for the capability increasing? Performance - Is the capability performing well or poorly? Is stakeholder satisfaction with the capability at a satisfactory level? Is the capability 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 for each initiative, by capability? Does the capability have the capacity to assimilate the change (i.e. necessary resources to participate in and sustain the initiative) What is the 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 components (ie human resources, information, application and technology)? What is the consistency of the capability? How complex is the capability (# suppliers, # vendors, # orgl units) What is the 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:
Page 32 of 86
Which capabilities are heavily dependent on IT? Which capabilities require complex IT applications and configurations? Which capabilities have the most IT problems reported? How mature are the IT platforms supporting the capability? Which capabilities have a standard IT platform (e.g. none, some, fully shared) Which capabilities have inappropriate IT support (e.g., lack sufficient numbers of adequately trained resources)?
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.
Page 33 of 86
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.
Page 34 of 86
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 o o o o o o Bank iPhone chart Market research Independent market assessment(s) Customer feedback survey(s) Departmental business plans New product listings
BUSINESS VALUE Differentiation - criticality to key stakeholders, customer service delivery, relationship to Banks core, customer-facing capabilities o o o Stakeholder facing vs not Impact to Banks reputation Import to differentiate the Banks value proposition (i.e. independent ratings / assessments / benchmarking against comps) Generates business (i.e. draws customers) Importance for successful delivery of stakeholder outcome # of successful new products produced that customers like (innovation) o High Attention Key stakeholder/Customer facing (core), impacts Banks reputation, differentiates Banks value proposition (i.e. independent ratings / assessments / benchmarking against comps), draws customers, required for successful delivery of customer outcome; Medium Attention Policy setting and standard setting in a way thats core to the Bank themes and sectors; develop talent and people (skills as a differentiator); IT infrastructure; sales and marketing; annual meetings; Low Attention Enabling and governing capabilities wholly removed to the customer (facilities, food services, training, fitness centers, other GSD);
o o
Page 35 of 86
The World Bank Description Strategic Alignment Criticality to realization of strategic initiatives Attributes o
Official Use Only Anchoring of Values 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); Medium Attention Enables or partially required for the realization of the strategic objective(s) (expert judgment required if a capability partially enables multiple objectives); Low Attention Does not contribute; High Attention - 5% or better improvement, year to year Medium Attention - -5% to 5% change, year to year Low Attention - 5% or worse degradation, year to year Data Collection / Sources and Comments o o Bank strategic objectives / strategic plan Expert judgment of Level 0 and 1 capabilities against objectives
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
o o o
o o o
Production volume information Customer (volume) data 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 whats isolated and predictable vs. whats not.
PERFORMANCE Performance / Service Levels - Capabilities Performance / Service Levels o Client level expectations (i.e. customer satisfaction ratings, timeliness of delivery, SLAs) o o o High Attention consistently miss performance expectations Medium Attention inconsistently meet expectations Low Attention consistently meet or exceed client level expectations o Organizational performance information (Balance Scorecard (BSC) Client) Customer feedback surveys Control performance information
o o
Page 36 of 86
Official Use Only Anchoring of Values o High Attention capability consistently and significantly underperforms with respect to time, budget, and scope. Medium Attention delivery varies with respect to time, budget, and scope; Low Attention consistently delivers on time, within budget, within scope; Data Collection / Sources and Comments o Organizational performance information (Balanced Scorecard (BSC) Internal Business Process) Control performance information Capability performance data (likely to be aggregated based on analysis of supporting organizational units performance data) HR data Financial performance and budget data # reported IT issues Customer feedback data (Understanding of) laws and industry regulations that impact capability List of Bank policies List of Bank organizational charter(s) Charters of committees involved with capabilities
o o
Existence and measurement of service level (i.e. % of performance targets achieved, including quality) Ability to address control needs Ability to deliver on time, within budget, within scope;
o o
o o o o Compliance Subject to compliance requirements o o o o Subject to laws Subject to organizational policies Subject to government or industry regulations Subject to organizational oversight o High Attention high level of oversight, significant numbers of laws, policies, regulations, etc., strong requirement for internal controls Medium Attention some oversight, moderate number of laws, policies, regulations applicable; typical requirements for internal controls Low Attention minimal oversight, minimal numbers of laws, policies, regulations, etc., minimal levels of internal controls required o
o o o
LEVERAGEABLE
Page 37 of 86
Official Use Only Anchoring of Values o High Attention Strong standards, strong controls, highly mature, defined service levels, consistent quality, (if performed across business units) performed consistently Medium Attention reasonable standards, some controls present, less mature, inconsistently service levels, reasonable quality, (if performed across business units) performed with some consistency Low Attention poor standards, few controls present, immature processes, undefined service levels, inconsistent quality, performed differently across business units Data Collection / Sources and Comments o o o o o Organizational performance information (BSC) Standards documentation Service level agreement(s) Quality requirements and monitoring procedures Cross-comparison of organizational performance data (to measure consistency)
Standards level, Controls level, Maturity level, Service level definitions, Quality levels and consistency, (if performed across business units) consistency
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.
11
Page 38 of 86
Official Use Only Anchoring of Values o High Attention capability is utilized in a number of other places, if it is unavailable or performing badly many capabilities would be impacted 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 Low Attention capability is highly isolated and is not shared with other capabilities High Attention many capabilities improved if a single capability improved Medium Attention some capabilities are improved Low Attention no other capabilities are improved Data Collection / Sources and Comments o Capability usage analysis within the business architecture
# of capabilities that will be improved if a single capability is improved (of those improved) to what degree will they improve
o o
Page 39 of 86
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 Description Attributes Anchoring of Values Data Collection / Sources and Comments o Approved capital budget(s)
ALIGNMENT BETWEEN PROPOSED INITIATIVES AND CAPABILITIES Requested Budget capital budget levels ROI - Return on Investment Per Capability o Requested Budget Amount o $ (relative, analyzed by capability)
Return-on-investment value(s)
o o
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
Availability and willingness of Bank to set resources aside Presence of a business / project plan that includes: costs, time, resources, and business case Number of initiatives contained within a capability Successful history of project implementations
High Attention yes to availability of resources, with 1 initiative contained Medium Attention some availability of resources and/or 2 or 3 initiatives within a single capability Low Attention inadequate availability of resources and 3+ initiatives within a single capability
o o o o
Enterprise resource planning data Project de-brief or close-out documentation Interviews or discussions with business owners Business cases or project management plans
Page 40 of 86
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 Description MATURITY BA Maturity maturity of the capabilitys business architecture o o o Components defined Components understood Components appropriately owned / used by the business to drive implementation of change (with IT) o o High Attention Components partially or not defined Medium Attention Components somewhat defined or defined but not used/owned consistently Low Attention Components defined as well as understood and owned/used by the business to drive implementation of change (with IT) High Attention Components partially or not defined Medium Attention Components somewhat defined or defined but not used/owned consistently, somewhat or inconsistently used to drive change Low Attention Components defined as well as understood and owned/used by the business to drive implementation of change (with IT) o o (Review of) available BA components (Analysis of) business understanding of BA components (Observation of) businesss use of BA to work with IT Attributes Anchoring of Values Data Collection / Sources and Comments
o o o
HR Components defined for the capability HR Components understood HR Components appropriately owned / used by the business to drive implementation of change (with IT)
o o
o o
(Review of) available EA components (Analysis of) business understanding of EA components (Observation of) businesss use of EA to work with IT
Page 41 of 86
The World Bank Description Information Resource Maturity maturity of the capabilitys HR layer Attributes o o o
Official Use Only Anchoring of Values o o High Attention Components partially or not defined Medium Attention Components somewhat defined or defined but not used/owned consistently, somewhat or inconsistently used to drive change Low Attention Components defined as well as understood and owned/used by the business to drive implementation of change (with IT) High Attention Components partially or not defined Medium Attention Components somewhat defined or defined but not used/owned consistently, somewhat or inconsistently used to drive change Low Attention Components defined as well as understood and owned/used by the business to drive implementation of change (with IT) Data Collection / Sources and Comments o o (Review of) available EA components (Analysis of) business understanding of EA components (Observation of) businesss use of EA to work with IT
Information components defined for the capability Information components understood Information components appropriately owned / used by the business to drive implementation of change (with IT)
o o o
Application components defined for the capability Application components understood Application components appropriately owned / used by the business to drive implementation of change (with IT)
o o
o o
(Review of) available EA components (Analysis of) business understanding of EA components (Observation of) businesss use of EA to work with IT
Page 42 of 86
The World Bank Description Technology Resource Maturity maturity of the capabilitys HR layer Attributes o o o
Official Use Only Anchoring of Values o o High Attention Components partially or not defined Medium Attention Components somewhat defined or defined but not used/owned consistently, somewhat or inconsistently used to drive change Low Attention Components defined as well as understood and owned/used by the business to drive implementation of change (with IT) High Attention large number of supplies / external dependencies, multiple organizational units, highlevel of regulatory oversight or compliance requirements. Medium Attention typical number of supplies / external dependencies, one or two organizational units, typical level of regulatory oversight or compliance. Low Attention minimal number of suppliers / external dependencies, single organizational unit, low levels of regulatory oversight or compliance. Data Collection / Sources and Comments o o (Review of) available EA components (Analysis of) business understanding of EA components (Observation of) businesss use of EA to work with IT
Technology components defined for the capability Technology components understood Technology components appropriately owned / used by the business to drive implementation of change (with IT)
o o o o o
# of suppliers # of external dependencies # of organizational units involved volume of regulatory oversight and compliance Degree to which skills required to perform the capability are unique to the needs of the Banks mission
o o o o o
Capability supplier list(s) Capability (service and product) vendor list(s) HR models for the capability Rating / value associated with Compliance category List of job titles and ratio of internal vs. external resources supporting capabilities (using HR data)
Page 43 of 86
The World Bank Description Architectural Control Geographic location of capability delivery Attributes o
Official Use Only Anchoring of Values o High Attention central function requiring high-level of investment and standardization across the bank; Medium Attention partially centralized ; Low Attention local function with little or no integration with other centralized Bank activities; Data Collection / Sources and Comments o SME analysis of geographic distribution supporting capabilities
Centrally configured vs. mixed configuration (central and regional) vs. exclusively regional configuration
o o
Page 44 of 86
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 Description Attributes Anchoring of Values Data Collection / Sources and Comments o Registry of IT resources identified within a business capability model SME analysis of critical capabilities against critical applications
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. Medium Attention Capability moderately impacted, some but not all business activities continue Low Attention Capability marginally impacted, business activities continue, manual workarounds sufficient with minimal or acceptable delays High Attention capability uses over X IT systems Medium Attention capability uses between Y and Z IT systems Low Attention capability uses less than Z IT systems
# of IT systems / applications
o o o
Note ideal to understand Volume per community of users. Also, answering this question implies understanding a full view of the EA;
Page 45 of 86
Official Use Only Anchoring of Values o o o High Attention lots of problems Medium Attention some problems Low Attention little or no problems Data Collection / Sources and Comments 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 o o Bank IT standards Analysis of application and technology models with Bank standards Review of application maturity within capability
o o o
Fully mature Bank-standard Aligns with Banks technology standards and direction(s)
High Attention fully mature, Bank-standard, aligns with Banks technology standards and direction(s) Medium Attention somewhat mature (ad-hoc customization in areas), generally aligns to Banks standards Low Attention immature and frequently not Bank-standard and/or technologies are generally not supported by ISG High Attention Capability operates on a fully shared platform Medium Attention capability operates on a somewhat shared platform Low Attention capability operates on fully independent / none-shared platform
o o
o o
Page 46 of 86
The World Bank Description IT Skill Types degree of risk associated with support of the capability IT resources Attributes o o o o
Official Use Only Anchoring of Values o High Attention insufficient resources available, significant / boutique skills requirements, outdated systems (no longer supported, companies gone under) used, lack of documentation Medium Attention resources available, moderate skills requirements, many systems up-todate, some documentation Low Attention resources available, widely-available skill-sets, current systems, extensive documentation Data Collection / Sources and Comments o Application models / registry with contact people, version information, and indication of available documentation (Potentially) interviews with support staff
Unique nature of skills required Resources available to support Relative current-ness of systems Documentation available on systems
Page 47 of 86
Category
Differentiation
Value Value
Low Attention
Medium Attention
High Attention
Critical to Bank
Performance Performance
Leverage Leverage
Integrated Dependency
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 organizations 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
Page 48 of 86
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-oninvestment (by capability) o Level of Application applied to Level 0 and, as-needed, Level 1 of the Business Architecture
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.
Page 49 of 86
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)
Page 50 of 86
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 Rating 12: 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;
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.
Page 51 of 86
Based on criteria selected and responses applied to each criterion, data should be interpreted according to the following scale 13:
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 that addresses a specific information need or augments the EA offices planning and engagement model; Get approval from Chief EA that new map should be added: 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;
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.
13
Page 52 of 86
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.
Page 53 of 86
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 Banks 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
Page 54 of 86
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.
0%
3% Convening 0% 2%
Advising
29% Financing
Enabling
65%
1% Implementing
7 Enabling 1 Strategy
Page 55 of 86
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.
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 organizations 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.
Page 56 of 86
High contribution
Medium contribution
Low contribution
High contribution
Low contribution
3 Business Value - Stakeholder Demand To 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)?
Response >5%
Options -5%-5%
<-5%
4 Performance - Service Levels Response To what extent does the capability meet stakeholder expectations for performance (e.g., meeting Consistently exceeds service levels, timelines of delivery, stakeholder satisfaction rating)? expectations 5 Performance - Capability Efficiency To what extent does the capability operate under defined performance expectations and measure performance? To what extent does the capability address the control requirements? To what extent does the capability deliver on-time, within budget, within scope? Response
Options Measures defined but not met Controls defined and applied Controls defined but not applied Consistently exceeds Inconsistently meets expectations expectations Measures defined and met Options Some oversight
6 Performance - Compliance To what extent is the capability subject to compliance requirements (subject to laws, policies, government or industry regulation, or organizational governance)? 7 Leverage - Predictability To 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?
Minimal oversight
No consistency
8 Leverage - Integration To what extent is the reused to support other capabilities? To what extent does this capability impact other capabilities (if it was unavailable or performing badly how many other capabilities would be affected? 9 Leverage - Capability Dependencies If the performance of this capability is improved to what degree will other capabilities be improved?
No capabilities improved
Page 57 of 86
Business Architecture Working Group (EA, BPT, and select business owners) Comprised of EA team, Others as identified
Page 58 of 86
Official Use Only Responsibilities Provide strategic direction to the team Secure commitment of resources to support the model development Facilitate the generation of consensus around the models Provide documentation and expertise on processes, performance measures, and supporting resources Participate in meetings and model development sessions Review and evaluate deliverables 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 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 Participate in meetings and model development sessions Maintain existing models Communicate benefits of the Business Architecture
Capability Facilitator
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 Initiative Sponsor Personnel Capability Area Leader or Designated Representative Managers and Individual Contributors from the Responsibilities Provide strategic direction to the team Secure commitment of resources to support the model development Facilitate the generation of consensus around the models Provide documentation and expertise on processes, performance measures, and
Page 59 of 86
Official Use Only Responsibilities supporting resources Participate in meetings and model development sessions Review and evaluate deliverables 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 Provide documentation and expertise on technology and systems supporting the Capability Area Lend expertise to opportunities, issues and constraints posed by technology Participate in meetings and model development sessions Review and evaluate deliverables 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) 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
Capability Facilitator
IT Specialist
Business Architect
Page 60 of 86
Page 61 of 86
1.
2.
3.
4.
5.
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.
Page 62 of 86
Page 63 of 86
Training materials the training course for business capability modelling within the overall curriculum of training for a business architect.
During project model development: During peer reviews EA office performs QA 14 o Notation o Naming conventions o Logical structure o Review of descriptions o Completed templates At conclusion of project EA officer performs Final QA Align final model (both new additions and updates to existing components) to enterprise-level framework (and review for any potential changes or impact) 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) Standards document will need to be developed in concert with the EA Office and BA Review Board.
14
Page 64 of 86
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.
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.
Page 65 of 86
9 Glossary of Terms
Term Architecture Segment Description 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. 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. 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. 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. Form used by Capability Facilitators to ensure complete data capture during Capability Modeling projects 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 A series of activities bringing about a result. A business process
Business Capability
Page 66 of 86
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. 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.). Visual depiction of the interaction between objects and Capabilities Decision , control, , or other attribute within the Capability chain that lies on the critical path to the primary output or outcome 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. In the context of a Business Capability, other Capabilities or elements of Capabilities that can influence or are subject to influence 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. An integrated view of the entire enterprise including relationships between the high-level business and IT components A graphical representation of data where the values taken by a variable in a two dimensional map are represented as colors. Indicates the future state importance of each Capability , which can be characterized as increasing, stable, or declining 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. 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.
Capability Connector
Dependencies
Enterprise Architecture
Integration Framework
Page 67 of 86
Vocabulary and terminology that is specific to and critical for understanding and/or describing a Capability Area, Capability SubArea, or Capability itself 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 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 Expected results that a Capability will deliver to the customer as noted in a performance measure, either qualitative than quantitative The physical or abstract resource of value produced by the Capability, often noted as an object on the Capability diagram Checklist for documenting decisions and artifacts chosen to be removed from or returned to the master repository People, Applications, and Data contributing to the realization of the Capability 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
Model Standards
Object
Outcomes
Job aids, training, methods, or localized best practices that enable the Capability 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.
Page 68 of 86
Performance
Leverage
Information Resources
Human Resources
Page 69 of 86
Official Use Only 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 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
Technology Resources
Page 70 of 86
Vision/Mission
Capability Description
Lexicon
State Representation Identify and document issues or risks pertaining to the capability documented in this template.
As-Is / To-Be
Identify and document issues or improvement opportunities gathered when defining this capability but that are NOT in scope for this capability. Capabilities
Capability Components Outputs Outcomes / Performance Measures Resources Tools & Techniques Objects Name Description Category Business Capability Model
Page 71 of 86
Contents Introduction and Context Business Architecture Repository Management and Procedures o o o o Stage I ITGG Planning Stage II Architecture Review Board Stage III Project Initiation Stage IV Project Closure
Page 72 of 86
The repository management process involves taking information from, manipulating information within, or adding new information back to the Banks 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 Board 15. This document provides an introduction to the sorts of tasks that are required at each stage of the repository management lifecycle: o o Enterprise Repository Administration the maintenance of business components stemming from stages I, II, and IV of the IT capital project lifecycle. 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).
Stage IV Project Closure BA Repository Administration Lifecycle Stage III Project Initiation
Figure 4 - Relating the Repository Management Lifecycle to Business Architecture Governance Stages
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.
15
Page 73 of 86
Business Architecture Repository Management Procedures 1. Stage I ITGG Capital Planning 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 ITGGs 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 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:
Page 74 of 86
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. Stage III Project Initiation 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:
3.
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: Enterprise Repository Administration: 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.
Page 75 of 86
Project Lifecycle Repository Administration: 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 QA 16 o Notation o Naming conventions o Logical structure o Review of descriptions and completed templates Enterprise Master Business Capability Repository
Check Out Diagrams, Templates, Requirements
Figure 5 - Overview of the Lifecycle of a Business Capability Master Model and Sub-Model 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 QA 17 o Notation o Naming conventions o Logical structure o Review of descriptions and diagram contents
16 17
Standards document will need to be developed in concert with the EA Office and BA Review Board. Standards document will need to be developed in concert with the EA Office and BA Review Board.
<Task 1 - BCM Method_Guide v5e Final.doc > Business Capability Method
Page 76 of 86
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 projects execution.
4. Stage III Project Closure Stage IV 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: Enterprise Repository Administration: 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.
Project Lifecycle Repository Administration: 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) -
Page 77 of 86
address any implications to potential changes to higher-level capability diagrams 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
Page 78 of 86
Business Capability Modeling Method Guide Task 2 - Proof of Concept Deliverable for Business Capability Modeling Project Modeling at the Bank Overview of Capability Models Getting Started Preparation for a Successful Project Tips and Best Practices Revision History
Contents
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 highlevel 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 Facilitator 18 in the context of this broader framework to ensure alignment across segments.
18
See Section 5.2 of this document for a description of the role of the Capability facilitator.
<Task 1 - BCM Method_Guide v5e Final.doc > Business Capability Method
Page 79 of 86
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 trainingthe 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 Banks 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 StaffThe 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 studyKnow 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 processUnderstand 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 diagrammingHave 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 notationKnow 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
Page 80 of 86
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 interrelationships among capabilities on a single view before creating detailed drilldowns 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
Page 81 of 86
Frame objects on the diagram so that when multiple objects serve as an input to a Categorize objects according to the information architecture categories maintained It should be up to the diagrammers 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
Page 82 of 86
2.
Document any unauthorized additions or exceptions and ask Enterprise Architecture officers if the non-standard items have already been approved. Document any deviations from the standards.
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
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
5.
Page 83 of 86
Official Use Only QA Process Step Outcome resolution of each issue. 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 righthand side of the capability hexagon.
Check that the names of all diagrams are in the correct format. 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.
Page 84 of 86
Page 85 of 86
Business Capability Modeling Project Lifecycle Reference Guide Purpose Steps 1. Meet with the Project Sponsor to discuss the Understand the strategic context for the vision and timeline for the project project 2. Identify Potential Team Members Assemble a Project Team 3. Recruit and Assemble Team Set the scope and target deliverables 4. Define Roles and Responsibilities 5. Determine Project scope
Kickoff
Interviews
Gather knowledge from team members and other Subject Matter Experts Document current practices and potential improvements Build enthusiasm for the project Document the Business Capability in the form of Business Capability Diagrams Identify the capabilities, key objects, and their relationships
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 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 asneeded, at a more aggregate level) 4. Validate the diagrams with stakeholders 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 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 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
Diagramming
Workshops
Engage business owners, stimulate discussion, and garner buy-in Validate information gathered through interviews Discuss key issues and ideas Develop a go-forward strategy Develop a business vision for the future state Document key ideas and focus areas Identify near term and long term improvement opportunities Produce formal document summarizing the project work Provide historical records Document metrics, lexicon, resources, and tools used for each capability
Capability Documentation
Concept of Operations
Page 86 of 86