OPG Creating a BA Roadmap, release 3 - Oracle · Creating a BA Roadmap 1-1 1 Creating a BA Roadmap...

Oracle® Practitioner GuideCreating a BA Roadmap

Release 3.0

E40625-03

July 2013

Creating a BA Roadmap, Release 3.0

E40625-03

Copyright © 2013 Oracle and/or its affiliates. All rights reserved.

Primary Author: Dave Chappelle

Contributing Authors: Stephen G. Bennett, Cliff Booth, Bob Hensle, Anbu Krishnaswamy, Mark Wilkins

Warranty Disclaimer

THIS DOCUMENT AND ALL INFORMATION PROVIDED HEREIN (THE "INFORMATION") IS PROVIDED ON AN "AS IS" BASIS AND FOR GENERAL INFORMATION PURPOSES ONLY. ORACLE EXPRESSLY DISCLAIMS ALL WARRANTIES OF ANY KIND, WHETHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. ORACLE MAKES NO WARRANTY THAT THE INFORMATION IS ERROR-FREE, ACCURATE OR RELIABLE. ORACLE RESERVES THE RIGHT TO MAKE CHANGES OR UPDATES AT ANY TIME WITHOUT NOTICE.

As individual requirements are dependent upon a number of factors and may vary significantly, you should perform your own tests and evaluations when making technology infrastructure decisions. This document is not part of your license agreement nor can it be incorporated into any contractual agreement with Oracle Corporation or its affiliates. If you find any errors, please report them to us in writing.

Third Party Content, Products, and Services Disclaimer

This document may provide information on content, products, and services from third parties. Oracle is not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services. Oracle will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services.

Limitation of Liability

IN NO EVENT SHALL ORACLE BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL OR CONSEQUENTIAL DAMAGES, OR DAMAGES FOR LOSS OF PROFITS, REVENUE, DATA OR USE, INCURRED BY YOU OR ANY THIRD PARTY, WHETHER IN AN ACTION IN CONTRACT OR TORT, ARISING FROM YOUR ACCESS TO, OR USE OF, THIS DOCUMENT OR THE INFORMATION.

Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners.

iii

Contents

Send Us Your Comments ........................................................................................................................ ix

Preface ................................................................................................................................................................. xi

Purpose ......................................................................................................................................................... xiAudience....................................................................................................................................................... xiHow to Use This Document....................................................................................................................... xiDocument Structure .................................................................................................................................... xiRelated Documents .................................................................................................................................... xiiAcknowledgements .................................................................................................................................. xiiiConventions ............................................................................................................................................... xiii

1 Creating a BA Roadmap

1.1 BA Roadmap Drivers ................................................................................................................. 1-11.1.1 Top-Line Drivers.................................................................................................................. 1-11.1.2 Bottom-Line Drivers............................................................................................................ 1-21.1.3 Agility Drivers...................................................................................................................... 1-21.1.4 IT Drivers .............................................................................................................................. 1-21.2 BA Roadmap Defined ................................................................................................................ 1-31.3 Roadmap Creation Process........................................................................................................ 1-41.3.1 Current State Assessment................................................................................................... 1-51.3.1.1 Overview ....................................................................................................................... 1-61.3.1.2 Details............................................................................................................................. 1-61.3.1.3 Output ............................................................................................................................ 1-91.3.2 Future Vision Definition ..................................................................................................... 1-91.3.2.1 Overview ....................................................................................................................... 1-91.3.2.2 Details............................................................................................................................. 1-91.3.2.3 Output ......................................................................................................................... 1-121.3.3 Gap Analysis ..................................................................................................................... 1-121.3.3.1 Overview .................................................................................................................... 1-121.3.3.2 Details.......................................................................................................................... 1-131.3.3.3 Output ......................................................................................................................... 1-171.3.4 Activity Selection and Scheduling ................................................................................. 1-171.3.4.1 Overview .................................................................................................................... 1-181.3.4.2 Details.......................................................................................................................... 1-181.3.4.3 Output ......................................................................................................................... 1-24

iv

1.4 Closing Comments................................................................................................................... 1-24

A BA Maturity Model

A.1 Capabilities ................................................................................................................................. A-1A.2 Domains ...................................................................................................................................... A-2A.3 Maturity....................................................................................................................................... A-4A.4 Adoption ..................................................................................................................................... A-4

vi

List of Figures

1–1 BA Roadmap Program and Project Scope............................................................................... 1-31–2 Roadmap Creation Process........................................................................................................ 1-51–3 Current State Assessment Process............................................................................................ 1-61–4 Future Vision Definition Process .............................................................................................. 1-91–5 Example BA Vision Summary................................................................................................ 1-121–6 Gap Analysis Process .............................................................................................................. 1-131–7 Vision versus Current Maturity............................................................................................. 1-131–8 Capabilities Scatter Plot .......................................................................................................... 1-151–9 Capabilities Heat Map............................................................................................................. 1-161–10 Activity Scheduling Process ................................................................................................... 1-181–11 Increasing Maturity Over Time ............................................................................................. 1-191–12 Program Activity Overview and RACI Chart ..................................................................... 1-201–13 Project / Activity Dependency Analysis .............................................................................. 1-211–14 Roadmap Phase 1 Schedule.................................................................................................... 1-231–15 BA Roadmap Subsequent Phases .......................................................................................... 1-24A–1 Integrated Analysis Capability ................................................................................................ A-2A–2 BA Capability Domains ............................................................................................................ A-3

vii

List of Tables

1–1 Typical Interview Participants ................................................................................................. 1-71–2 Typical Relevant Documents ................................................................................................... 1-81–3 BA Goal Statements ................................................................................................................ 1-101–4 BA Initiative Scope.................................................................................................................. 1-101–5 Example BA Benefits .............................................................................................................. 1-111–6 Example BA Guiding Principles ........................................................................................... 1-111–7 Remediation per Domain....................................................................................................... 1-17

ix

Send Us Your Comments

Creating a BA Roadmap, Release 3.0

E40625-03

Oracle welcomes your comments and suggestions on the quality and usefulness of this publication. Your input is an important part of the information used for revision.

■ Did you find any errors?

■ Is the information clearly presented?

■ Do you need more information? If so, where?

■ Are the examples correct? Do you need more examples?

■ What features did you like most about this document?

If you find any errors or have any other suggestions for improvement, please indicate the title and part number of the documentation and the chapter, section, and page number. You can send comments to us at [email protected].

xi

Preface

A Business Analytics (BA) Roadmap provides the guidance to advance the maturity of the BA program and promote greater success with BA-related projects and technologies. This roadmap creation process examines both the business and technical aspects of a BA initiative. It addresses many forms of BA, including descriptive, predictive, prescriptive, and exploratory analytics. It also recognizes the efforts that pertain to information management in support of BA initiatives.

Building such a roadmap requires a solid understanding of the current situation, a clear vision of what must be done to be successful, and a structured approach to defining the iterations that comprise the path to greater success and widespread adoption.

PurposeThe purpose of this document is to describe a repeatable process for constructing a BA Roadmap. The process described follows the standard four steps used within the industry to create roadmaps, i.e. establish the current state, define the future vision, analyze the gap, and define the phases and schedule of the roadmap. It is the particulars within each phase of the overall process that provide the uniqueness and value of the approach described in this document.

AudienceThis document is intended for Program Managers and Enterprise Architects that want to understand how to build a fact-based BA Roadmap. Some level of understanding of BA is required since this document does not provide any BA background or primer material.

How to Use This DocumentThis document is intended to be read from start to finish. However, the first two sections in Chapter 1 can be read standalone if the goal is only to get a high level understanding of the roadmap creation process.

Document StructureThis document is organized chronologically. It describes the BA Roadmap building process from start to finish. Specifically,

■ Chapter 1 describes the process for creating a BA Roadmap.

xii

■ Appendix A describes the BA Maturity Model that is used to evaluate the current state and identify capabilities that are lacking or lagging.

Related DocumentsIT Strategies from Oracle (ITSO) is a series of documentation and supporting collateral designed to enable organizations to develop an architecture-centric approach to enterprise-class IT initiatives. ITSO presents successful technology strategies and solution designs by defining universally adopted architecture concepts, principles, guidelines, standards, and patterns.

ITSO is made up of three primary elements:

■ Oracle Reference Architecture (ORA) defines a detailed and consistent architecture for developing and integrating solutions based on Oracle technologies. The reference architecture offers architecture principles and guidance based on recommendations from technical experts across Oracle. It covers a broad spectrum of concerns pertaining to technology architecture, including middleware, database, hardware, processes, and services.

■ Enterprise Technology Strategies (ETS) offer valuable guidance on the adoption of horizontal technologies for the enterprise. They explain how to successfully execute on a strategy by addressing concerns pertaining to architecture, technology, engineering, strategy, and governance. An organization can use this material to measure their maturity, develop their strategy, and achieve greater levels of adoption and success. In addition, each ETS extends the Oracle Reference Architecture by adding the unique capabilities and components provided by that particular technology. It offers a horizontal technology-based perspective of ORA.

■ Enterprise Solution Designs (ESD) are cross-industry (applicable to many industries) and industry-specific (focused on a single vertical industry) solution perspectives based on the Oracle Reference Architecture. They adhere to the ORA principles and also draw on the best practices and guidelines provided in ETS collateral. They define the high level business processes, business functions, and software capabilities that are required to build enterprise-wide industry solutions. ESDs map the relevant application and technology products against solutions to illustrate how capabilities in Oracle's complete integrated stack can best meet the business, technical, and quality-of-service requirements.

This document is one of the series of documents that comprise the Business Analytics Enterprise Technology Strategy. The BA ETS includes reference architecture

xiii

documents (ORA Business Analytics Foundation and ORA Business Analytics Infrastructure) as well as “how to” documents such as this guide to creating a BA Roadmap.

Please consult the ITSO web site for a complete listing of ORA documents as well as other materials in the ITSO series.

Of particular relevance to this document are the following documents which provide additional information for the BA Roadmap creation process:

■ BA Maturity Model Capabilities - This spreadsheet contains the specific capabilities that are measured as part of the current state analysis. For each capability a description is provided for each level of maturity and adoption.

■ BA Maturity Model Analysis - This spreadsheet is used to analyze the scores for the capabilities on both maturity and adoption. The spreadsheet contains various graphical depictions of the scores.

AcknowledgementsThis document is based on a variety of materials that have been created by many different individuals and groups. Thanks to all who contributed. The purpose of this document is to catalogue the materials and describe the process for using the materials together to create a BA Roadmap.

ConventionsThe following typeface conventions are used in this document:

Convention Meaning

boldface text Boldface type in text indicates a term defined in the text, the glossary, or in both locations.

italic text Italics type in text indicates the name of a document or external reference.

underline text Underline text indicates a hypertext link.

www.oracle.com/goto/itso

http://www.oracle.com/goto/itstrategies

1

Creating a BA Roadmap 1-1

1Creating a BA Roadmap

Business analytics (BA), as the name suggests, is very much a business-driven strategy. The drivers for pursuing BA are predominantly business focused. The user community is usually business focused, e.g. executives, managers, and financial planners. Even the most sophisticated "power-users", those that most fully understand data modeling and technology, use the system in support of business initiatives.

However, the ability to provide the level of intelligence a modern business requires can involve a great amount of time and effort from IT. For example, a simple business requirement to track sales of an item can involve hundreds of hours of time from database administrators, data stewards, developers, and operations personal, in order to get the right information to the right people in the right way, at the right time. This makes it vitally important to have a clear and effective line of communication between the business and IT communities. It also underscores the need for effective planning in order to ensure that IT is focused on what the business really needs. In addition, business and IT communities must coordinate well in order to adapt to changing business requirements and advances in technology.

This chapter describes the process used to create an effective BA Roadmap. It takes into account several business factors and an evaluation of the current state in order to prioritize efforts that will best serve both the business and IT communities.

1.1 BA Roadmap DriversA number of drivers affect how a BA Roadmap is defined and executed. The ultimate goal of the roadmap is to provide a strategic path to achieve the goals of the business and to provide incremental value to gain competitive advantage. BA can positively affect both the top line and bottom line of the business, and make it more agile and competitive. The roadmap is greatly influenced by how these benefits can be quickly realized.

The roadmap is also influenced by the reality of achieving these goals in a manner that is both practical and sustainable. Given that these issues tend to fall on the shoulders of IT, they are described below as IT drivers.

1.1.1 Top-Line DriversBA strategies are often used to drive top-line growth. This is achieved in many ways, including:

■ Improved marketing strategies based on statistical analysis, trend analysis, and data mining

■ Improved sales based on analysis of pricing, placement, and cross-sell/up-sell indicators

BA Roadmap Drivers

1-2 Creating a BA Roadmap

■ Improved product strategies based on predictive analytics, historical analysis, and sentiment analysis

■ The discovery of new product and/or service opportunities based on data mining and text mining various forms of data

■ Just-in-time insight and decision making based on real-time event processing, business activity monitoring, and business rules

■ Business strategy development and tracking using key performance indicator (KPI) definition and monitoring

■ Effective financial planning, customer management, and improved service

1.1.2 Bottom-Line DriversBA contributes to improving the bottom line through cost reductions in several ways. It provides insight into forecasting that can be applied to inventory management, headcount, and resource optimization. It can be used to improve decision making in areas that reduce expenses, such as transportation costs, shipping costs, and asset management. It can also be used to automate decision making, thereby reducing costs associated with common business processes that would ordinarily require human intervention. BA has also been used to reduce costs by combating fraud, theft, and detecting various types of security threats.

1.1.3 Agility DriversBA improves business agility by helping businesses respond faster to changes in market conditions. This requires continuous monitoring of market conditions, sensing when change occurs, and determining if/when/what actions are required. Business Activity Monitoring (BAM) and Complex Event Processing (CEP) underpin the analysis framework necessary to detect and respond to real-time market conditions.

Agility can be gained via automation, as described, and via human decision making as well. BAM and CEP can feed real-time information to knowledge workers, who in turn use this information for making more informed decisions. Real-time and historical information can also be combined in order to recognize abnormal behavior or new opportunities. Business decisions can change based on current conditions as opposed to periodic reports or statically defined business rules.

1.1.4 IT DriversIn order for IT to deliver the benefits of BA, it must ensure that information is collected, organized, cleansed, and delivered in a manner that produces accurate and insightful analysis. The capacity for doing so may not already exist within the organization, therefore, the BA Roadmap may be influenced by a number of IT-related drivers, such as:

■ The ability to collect data from operational systems

■ The ability to semantically organize and cleanse operational data

■ The ability to manage the volume of data required for historical analysis

■ The ability to process and deliver analysis queries as quickly as needed

■ The ability to provide end user capabilities via all necessary delivery channels

■ The ability to integrate real-time processing with business analytics

BA Roadmap Defined


IT drivers often require the roadmap to prioritize and coordinate the deployment of software and infrastructure in order to achieve business goals in a beneficial, practical, and sustainable manner.

1.2 BA Roadmap DefinedA BA Roadmap provides guidance to the BA initiative, allowing multiple projects to progress in parallel yet remain coordinated. This ultimately results in a common end goal that provides value greater than the sum of the individual projects. The BA Roadmap helps to coordinate two types of activities:

1. Program-level activities that address cross-cutting concerns such as strategy and planning.

2. Project-level activities that pertain to the delivery of specific infrastructure or application related assets.

The relationship for these fundamental parts is illustrated in Figure 1–1.

Figure 1–1 BA Roadmap Program and Project Scope

In most organizations, BA solutions are created in silos in order to address the needs of specific departments or users. Little thought is given for how those solutions affect the rest of the enterprise eco-system or how they might positively or negatively impact the larger program. This shortsightedness may necessitate follow-on projects to rationalize data stores, sort out data integration issues, or duplicate design and development efforts due to lack of communication or coordination between projects.

The BA Roadmap is designed to provide the coordination and communication necessary to avoid project silos. It does this by defining a common vision for how the organization should handle all aspects of BA. The processes, projects, and infrastructure to support BA are organized and managed in order to incrementally achieve the target vision. The intent is to improve BA maturity over time while delivering projects that align with the vision and support ongoing business initiatives.

Roadmap Creation Process


Activities included in the program-level scope are intended to advance BA maturity through proper strategy and planning. They include, (but are not limited to), the definition of:

■ A reference architecture that describes the recommended architecture capabilities, components, principles, technologies, and infrastructure for designing BA solutions

■ An engineering method used to guide the development of BA solutions

■ A governance model that describes how information and solution artifacts will be properly governed

■ Guidance on how information and analysis artifacts should be modeled in order to promote sharing and reuse

■ Guidance on how KPIs should be described, monitored, and managed

The enterprise may already have some of these assets in various stages of completeness and relevance. Some may be deemed important and necessary while others may be less so. The intent of the roadmap process is to determine which program level activities need to be addressed and in what order.

In addition, the organization will likely have several BA projects that are either ready to begin or are slated for the near future. The roadmap will endeavor to establish a logical ordering of activities that benefits both program and project level objectives. For example, infrastructure to manage BA assets may be deployed in support of program level objectives. It may be prioritized ahead of certain projects that most need this capability, or it may be included in a project in order to provide this capability for future projects. In either case, establishing a roadmap helps to facilitate coordination and communication between program-level and project-level activities.

Projects in support of BA may be divided into two groups: those that pertain to the delivery of BA assets, and those that pertain to the delivery of enterprise information management (EIM) assets. The former group focuses on applications, tools, reports, dashboards, etc. that enable various forms of analysis. The latter group focuses on the acquisition, integration, cleansing, management, access, and governance of information assets.

The two types of projects can be delivered in tandem, in support of a common set of requirements, or they can be delivered as separate initiatives, prioritized according to needs. Either way, the organization should strive to get the most value out of these projects by ensuring that they are aligned with the vision. The BA Roadmap offers a means to effectively coordinate these different types of projects following program-level guidance.

Generally, the most effective planning horizon for a BA Roadmap is 2-3 years. This could be longer or shorter depending on the planning cycles for each organization. The initial phases (e.g. first six months) of the roadmap will contain much greater detail than the later phases. This is appropriate and by design. The BA journey is often a journey of discovery, incremental improvement, and regular course corrections. The BA Roadmap should be regularly reviewed and updated. The business never stays static, so do not expect the BA Roadmap to remain static either.

1.3 Roadmap Creation ProcessAs depicted in Figure 2, there are four main phases in the roadmap creation process: Current State Assessment, Future Vision Definition, Gap Analysis, and Activity Selection & Scheduling.



Figure 1–2 Roadmap Creation Process

The current state is measured based on the Oracle BA Maturity Model. Using this approach to assess the current state of the BA initiative provides a consistent measurement scale while keeping the effort focused on capabilities important to BA success and avoiding the scope creep that frequently undermines current state evaluation efforts.

The Future Vision Definition phase is used to establish the high-level goal and reason for the BA program. While a fully fleshed out future vision is needed eventually, the initial roadmap creation only requires the high-level vision since the development of the detailed vision can itself be part of the BA Roadmap. Of course, if the current state of the BA initiative includes a more detailed future vision, that vision can be leveraged when creating the roadmap.

The Gap Analysis phase evaluates the gap between the current state and the future vision for each of the capabilities. Generally the capabilities exhibiting the largest gap are given highest priority during the roadmap creation phase. However, part of the gap analysis also includes evaluating the relative importance for each of the capabilities for this particular organization. Size, organizational structure, existing assets, funding priorities, even politics can significantly impact the relative importance of capabilities.

The final phase is the Activity Selection & Scheduling phase. This phase uses the output from the Gap Analysis phase to create a logical ordering of work to be done. Emphasis is placed on the program-level efforts for the initial phases to establish the assets and processes used across projects. Projects are evaluated for business benefit, IT benefit, and risk and are then prioritized based on that evaluation.

The BA Roadmap creation process is itself an iterative process. The first iteration may have very limited detail on the project portfolios and focus heavily on the program level efforts. As the roadmap is reviewed and updated, additional details will be added for the project portfolios. As maturity increases and adoption spreads, it is also likely that later phases will include additional program-level activities.

1.3.1 Current State AssessmentAttempting to capture a full, detailed description of the current state of an IT environment of a large company can lead to analysis paralysis. To avoid this problem, the method described here uses a focused scope and a pragmatic, time-boxed approach. The underlying goal is not to fully capture an IT environment current state;



rather it is to evaluate the current state relative to the capabilities that are required to successfully advance BA maturity.

1.3.1.1 OverviewThe current state assessment is based on the Oracle BA Maturity Model. (See Appendix A for a description of the BA Maturity Model.) The BA Maturity Model includes over eighty capabilities that capture the best practices that Oracle has collected over many years working with a wide variety of companies. These capabilities provide the detail necessary to accurately measure and guide the progress of a BA initiative. Focusing the current state assessment on these specific capabilities ensures a focused scope for the assessment.

Further, the current state assessment should be tightly time-boxed to ensure timely completion of this phase. The size and complexity of an organization determines the actual amount of time that must be allocated to the assessment. Nominally, two weeks is the amount of time required.

An overview of the current state assessment process is shown below:

Figure 1–3 Current State Assessment Process

1.3.1.2 DetailsThis section details the steps defined in the previous section.

1.3.1.2.1 Define Scope

Before beginning the actual assessment, it is vital that the scope of the assessment is determined and that all involved parties agree to the defined scope. For example, the scope could be limited to a single division or line-of-business within a larger enterprise. Or, the scope could be limited to a single geographic location. The scope defines both the scope of the assessment and, ultimately, the scope of the roadmap.

1.3.1.2.2 Identify Interview Participants

Once the scope has been determined, the participants in the assessment can be identified. The participants are chosen to ensure that all capabilities within the BA Maturity Model can be accurately scored. The following table describes the typical areas of interest and interview participants:



1.3.1.2.3 Determine Interview Schedule

Once the interview participants have been identified, the next step is to create a schedule for when each participant will be interviewed. The goal is to limit the length of the assessment phase by creating a compacted schedule. It may be necessary to delay the start of the assessment to get times on the participants' schedules that fit into a two week (or so) period. Time before or between interviews can be productive time spent reviewing documentation (i.e. the next step).

1.3.1.2.4 Gather and Review Relevant Documents

Before beginning the interview process, the assessment team should gather and review all the existing documents that describe various aspects of the current IT environment and BA initiative. This allows the assessment team to ask more focused questions in the interviews and also provides the opportunity to ask questions about the written

Table 1–1 Typical Interview Participants

Area of Interest Typical Participant

Business Objectives VP of Business Unit(s)

LOB IT

IT Objectives CIO

VP of Application Development

VP of IT Infrastructure

Enterprise Architecture VP of Enterprise Architecture

Enterprise Architect(s)

Information Architecture VP of Information Architecture

Data Analyst(s)

Data Scientist(s)

Database Architect(s)

Data Steward(s)

Data Integrator(s)

Program Management PMO Manager

Project Manager(s)

Development Process Application Architect(s)

Business Analyst(s)

Development Lead(s)

Methodologist

Build Manager

CM Manger

QA Manager

Operations Director of Operations

Administrator(s)

Security Chief Security Architect



material for clarification or to resolve conflicting information. The following table gives some examples of the types of documents that should be gathered and reviewed:

1.3.1.2.5 Perform Interviews

Before each interview the assessment team should review the BA Maturity Model to identify capabilities that are particularly relevant for the person being interviewed. It is NOT recommended that the assessment team simply ask a question for each of the capabilities. Rather the interview team should ask open ended questions that allow the interviewee to describe how things are currently done and to identify any problems that currently exist. Remember, the interviewees are the experts on what goes on within the organization being evaluated, so encourage them to explain the current situation.

1.3.1.2.6 Assign Capability Scores

Once the interviews have been completed and the documents have been reviewed, each of the capabilities in the BA Maturity Matrix should be scored for both maturity and adoption. These scores provide the raw data that can then be analyzed in the gap analysis phase of the roadmap creation process.

The BA Maturity Model includes a description for each level of maturity and each level of adoption for each capability. When scoring a capability, the scores selected should be the scores where the descriptions of maturity level and adoption level most accurately match the current situation based on the information collected in interviews and from the documents reviewed. Although there is always some level of subjectivity when measuring capability, the goal is to provide an objective measure. This allows future measurements to be performed by a different assessment team, yet still provide results that can be used to accurately measure progress.

Frequently when the assessment results are presented there are questions and even disagreements about the score that was assigned. Therefore, it is also important that in addition to the score, the assessment team also record the rational for assigning the maturity and adoption scores. This rational could include quotes from interviews or specific sections from the documents that were reviewed.

Table 1–2 Typical Relevant Documents

Typical Documents to Review

Balanced Score Card, Strategy Map (or similar business strategy/goals document)

Enterprise Architecture Document(s)

Information Architecture Document(s)

Project Management Handbook(s)

Software Development Process Document(s)

Information Management Proces Document(s)

Operational Process and Procedures Document(s)

Corporate Security Policies

Organizational Structure Document

BA Program Document(s)

Information and BA Governance Document(s)



1.3.1.3 OutputThe output of the current state assessment is the maturity and adoption score for each of the capabilities in the BA Maturity Matrix. Additionally, the assessment team will have an understanding of the current state and should have collected known issues and problems that were identified and discussed during the interview process.

1.3.2 Future Vision DefinitionFor the BA Roadmap creation process, the future vision definition phase focuses solely on the high level goals and principles that will be used to guide the entire BA initiative. This phase does not attempt to create a detailed future state vision. While a more detailed future vision is required to achieve successful BA adoption, it is not something that must be created prior to creating the initial BA Roadmap. The initial phases of the BA Roadmap may focus on creating the detailed BA future vision. (See Figure 4)

Figure 1–4 Future Vision Definition Process

1.3.2.1 OverviewThe BA vision definition answers the following questions:

1. What is goal of the BA initiative?

2. What is the organizational scope of the BA initiative?

3. What are the benefits that BA is expected to deliver to the organization?

4. What are the guiding principles for the BA initiative?

These questions must be answered by the executive(s) leading the BA initiative. This is accomplished in a facilitated workshop. Nominally the workshop should take about two hours, but may take longer if there is substantial disagreement on either of the goals, scope, benefits, or principles for BA.

1.3.2.2 DetailsThis section provides greater detail on how to collect answers to the questions that the previous section introduced.

1.3.2.2.1 Goal of the BA Initiative The goal being defined is the goal for the BA initiative by the end of the roadmap. The recommended roadmap planning horizon is 2-3 years; therefore the goal should be the goal of the BA initiative 2-3 years from now. The following table provides goal statements from which to choose.



The goal statements in the above table are used to gauge the extent and complexity of the entire BA initiative and are listed in order of increasing difficulty. It should be obvious that accomplishing the first goal statement is far less difficult that accomplishing the fifth goal statement. Greater organizational maturity is required to achieve the more difficult goals for BA. Of course, the benefits provided by BA are commensurably greater as well. The 'Score' column in the table is used (and will be explained) in the gap analysis phase.

1.3.2.2.2 Organizational Scope of the BA Initiative The organizational scope defines which departments, divisions, lines-of-business, etc. are included in the BA initiative. The most common scopes are either division or enterprise, but other options are possible depending on the company's organizational structure. The following table provides example levels of scope for the BA initiative.

Defining the scope of the BA initiative is essential to determining a roadmap. With greater scope, the number of organizational boundaries that must be crossed increases. This increases the complexity of the effort, and, therefore, requires greater organizational maturity. The 'Score' column in the table is used (and will be explained) in the gap analysis phase.

1.3.2.2.3 Expected Benefits of the BA Initiative There are many different benefits that an organization can realize by successfully adopting BA. However, not all benefits can be realized in parallel. When creating a BA Roadmap emphasis should be placed on the benefits that are highest priority and leave the lower priority benefits for later phases. The table below lists possible benefits from BA adoption:

Table 1–3 BA Goal Statements

Goal Statement Score

Develop experience using BA to provide a foundation for further investments in BA technologies.

1

Standardize and consolidate technology and methodology for BA according to best practices in order to reduce operational costs and improve overall efficiency.

2

Drive widespread sharing and reuse of BA assets by consistently applying architecture, engineering, and governance processes across the organization.

3

Improve business/IT alignment and drive business value by measuring and managing to key performance indicators.

4

Maximize revenue, optimize operations, and create competitive advantage through timely insight and intelligent decision making.

5

Table 1–4 BA Initiative Scope

SOA Initiative Scope Score

A small number of projects will be involved in the BA initiative. 1

One or more business units will be included in the BA initiative. 2

The BA initiative will span all business units within a single division. 3

The BA initiative will span multiple divisions within the enterprise. 4

The BA initiative will span the entire enterprise. 5



The benefits in the above table can be used as a starting place to identify the benefits that an organization hopes to achieve via the BA initiative. The above table is only a start on the possible benefits and is by no means a complete list. Part of the vision definition is to create a list of possible BA benefits and prioritize the list.

Once a list has been created, the benefits should be prioritized based on the business and IT objectives of the organization. The easiest way to prioritize the benefits is to assign a high, medium, or low prioritization to each possible benefit. Roughly one third of the possible benefits should be in each prioritization i.e. it does no good to list all the possible benefits as high priority.

1.3.2.2.4 Guiding Principles for the BA Initiative The guiding principles are derived from the top priority benefits and provide enforceable guidance to the BA initiative. The following table provides some example guiding principles.

The guiding principles should be sufficiently clear and detailed that the principles can be enforced across the entire scope of the BA initiative and on specific projects that fall under the purview of the initiative. The principles should also serve as a foundation to make more specific decisions in the future.

Table 1–5 Example BA Benefits

Better visibility into business processes Reduce time to acquire data to make decisions

Accurate and timely financial reporting Real-time intelligence insight

Predictive analytics Single version of the truth

Improve business simulation & forecasting Visibility into success of current business strategy

Real-time alerts Optimization of business processes

Analysis of public sentiment regarding products and services

Support for analysis using mobile devices

Achieve cross-department collaboration on analysis

More effectively translate business questions into useable intelligence

Analysis to support business objectives Ability to test business hypotheses

Table 1–6 Example BA Guiding Principles

The quality of data and accuracy of analysis must be known

Accommodate all forms of data

Provide data abstraction and loose coupling

Unified view of information

Consistent and complete information and analysis

Provide security secure access to information and analysis

Define and share information and analysis constructs and semantics

Enable insight to action

All changes that affect analysis must be properly governed

Analysis must be available when and where it is needed

Infrastructure resources must be pooled across departments and business units



1.3.2.3 OutputThe output from the vision definition phase is the overall goal of the initiative, the scope of the initiative, the expected benefits, and the guiding principles to achieve the goal and the benefits. This vision for the BA initiative can be captured in a single summary slide and used to educate and align the organization with the BA initiative. An example of this summary slide is shown in Figure 5.

Figure 1–5 Example BA Vision Summary

This clearly shows the goal and scope of the BA initiative. It also shows that the BA principles will be enforced across the entire BA initiative and that the BA initiative is expected to deliver the prioritized benefits.

1.3.3 Gap AnalysisThe gap analysis phase compares the current state of the BA initiative (as measured in the assessment phase) with the goal for the initiative (defined in the vision phase). The gap between these two is then analyzed to determine the causes and remediation approaches are identified.

1.3.3.1 OverviewThe maturity and adoption scores from the current state assessment phase measure the progress of a BA initiative and, more importantly, identify specific capabilities that are lacking or lagging and are therefore inhibiting the BA initiative. The gap between where the organization is currently and where they need to be to achieve their goal is broken down by capability domain (from the BA Maturity Model) to identify lagging domains. It is further broken down by individual capability to identify specific capabilities that are lacking or lagging. The following diagram illustrates the process:



Figure 1–6 Gap Analysis Process

Once the lagging capabilities have been identified, a remediation approach for each of the identified inhibitors is determined from industry best practices and prior Oracle experience.


1.3.3.2.1 Identify Problem Domains

The first step in the gap analysis phase is to identify the domains that exhibit the largest gap between current maturity and the maturity needed to achieve the BA goal. The gap for the domains can be visually represented by a spider (aka radar) graph as shown Figure 1–7.

Figure 1–7 Vision versus Current Maturity

The 'Vision' level is determined by the following formula:



Where GS is the score from the goal statement (see Table 1–3) and SS is the score from the scope of the BA initiative (see Table 1–4). This formula maps the goal statement to a level of maturity necessary to reach that goal. The scope of the initiative is used as a modifier if the scope score is greater than the goal score i.e. it takes greater maturity to achieve success on a broader scope. The vision score (VS) is then mapped to the maturity levels in the BA Maturity Model by applying the simple formula: 1=Ad Hoc, 2=Opportunistic, … , 5=Optimized.

For the example spider graph shown in Figure 1–7, the 'Vision' level was derived using this formula as follows:

Goal Statement: Maximize revenue, optimize operations, and create competitive advantage through timely insight and intelligent decision making.

Scope Statement: The BA initiative will span multiple divisions within the enterprise.

So GS = 5 and SS = 4. Therefore, since GS is greater than SS, VS = GS. The GS score of 5 mapped to the maturity levels yields a vision maturity of Optimized. This 'Vision' level of maturity is what is plotted across all domains in Figure 1–7.

The 'Current Maturity' level for each domain is calculated by simply averaging the maturity score for each capability within the domain. This provides an average maturity for each of the eight domains which is then plotted in the spider graph.

Plotting the Current Maturity relative to the Vision (as shown in Figure 1–7) provides a visual representation of the gap between where the organization is with respect to BA and where it needs to be to meet the goal of the BA initiative. In this example, the graph clearly shows that the Business & Strategy, Information, and Governance domains require the most attention.

This analysis is fed into the roadmap creation phase. In this example, initial activities in the roadmap should center on addressing the lagging capabilities in the Business & Strategy, Information, and Governance domains.

1.3.3.2.2 Outlier Capabilities

Outlier capabilities are capabilities where the maturity and the adoption are significantly out of sync. This usually indicates a capability that should receive attention early in the roadmap. The outlier capabilities can be easily detected by plotting the maturity and adoption score for each capability in a scatter plot as shown in Figure 1–8.



Figure 1–8 Capabilities Scatter Plot

As shown in the above graph, the maturity and adoption scores for capabilities usually fall along the diagonal when plotted against each other. In the above example, there are two scores that are significantly off the diagonal, one well above the diagonal and one well below the diagonal. The capability well above the diagonal is a capability from the Architecture domain. The capability well below the diagonal is a capability from the Organization domain. The analyst will need to review the actual capability scores to identify exactly which capabilities yielded the outlier points on the graph.

A capability that falls well above the diagonal indicates a capability that is done very well within a relatively small area of the organization. In this example, there is a capability at a 'Managed' level of maturity done within a single project. Fostering greater adoption of this capability provides an easy win for the BA initiative i.e. there is no need to develop greater competency for this capability within the organization since it already exists within the organization. Some training or mentoring can spread the ability more broadly within the organization.

A capability well below the diagonal indicates a capability that is done poorly (or in a non-compliant fashion) very broadly. In this example, there is a capability being done at an 'Ad Hoc' level of maturity across the entire enterprise. Corrective action needs to be taken for this capability since if left uncorrected, it will inhibit (and probably already has inhibited) the BA initiative.

Capabilities that plot nearer the lower left corner are capabilities that are either non-existent or are lagging behind the other capabilities. These capabilities will be addressed in the next step of the gap analysis process.

The capabilities that plot toward the upper right corner are capabilities that are currently being done well. No remediation is required and the organization should continue business as usual for those capabilities.

1.3.3.2.3 Low Maturity Capabilities

The capabilities that plot nearer the lower left corner in the scatter plot are capabilities that require attention in early phases of the roadmap. Capability heat maps can be used to visually identify these low maturity capabilities as shown in Figure 1–9.



Figure 1–9 Capabilities Heat Map

The capabilities heat map colors each of the capabilities based on the maturity score recorded for that capability. The above diagram shows the color coding legend as well as each capability with color coding applied. The capabilities are organized by the domains used in the BA Maturity Model.

The heat maps draw immediate attention to the capabilities that require attention. In the above example, there is one capability in the Governance domain (Governance Principles) that scored at the 'No BA' level of maturity. These capabilities should be addressed in early phases of the BA Roadmap. Likewise, there are several capabilities in other domains that scored at the 'Ad Hoc' level of maturity. These capabilities should also be addressed in early phases of the BA Roadmap. It should come as no surprise that the Business & Strategy, Information, and Governance domains were also identified in Figure 1–7 as lagging domains.

It is important to point out that not all capabilities are of equal importance for a particular organization. In fact, there may be capabilities that are deemed unimportant or even not applicable for a particular organization. Thus, it is necessary to review each capability with a low score and determine whether it is a top priority, a low priority, or unimportant from a roadmap creation perspective.

If a capability is deemed unimportant for a particular organization, it should be removed from the maturity model and the graphics should be regenerated. This should be done with caution. A capability should only be removed if it is clearly not appropriate for the BA initiative at this organization.

1.3.3.2.4 Determine Remediation Activities

At this point in the gap analysis process, the problem domains have been identified and the problem capabilities within each domain have also been identified. The next step is to identify remedies for each problem domain and capability. The remedies, obviously, depend on the problem being addressed and also frequently have some aspect that is organization specific. Thus, unfortunately, it is not possible to provide a prescriptive approach to determining remediation activities for all 80+ capabilities.

However, there are some general guidelines based on the domains that can usually be applied to creating remediation activities.



1.3.3.3 OutputThe output from the gap analysis phase is an understanding of which domains and which individual capabilities are inhibiting the successful achievement of the goal of the BA initiative. Additionally, remediation activities have been identified to address the lagging domains and capabilities. These remediation activities provide the primary input into the roadmap creation process.

1.3.4 Activity Selection and SchedulingThe remedies identified in the gap analysis phase are prioritized and used to create a plan, called the BA Roadmap. Projects are then evaluated to determine which remedies are immediately pertinent and beneficial to the projects. BA Roadmap scheduling and prioritization are derived from the combination of remedies and projects.

Table 1–7 Remediation per Domain

Domain Remediation Comments

Business & Strategy

Remediation for this domain and the capabilities within this domain usually requires executive management decisions and directives. A common remediation activity is a facilitated workshop with appropriate executives to define the necessary strategies, make decisions, and formulate directives.

Architecture Low scores in this domain usually indicate the lack of a reference architecture for the BA initiative, or if the reference architecture exists, it lacks completeness and details. Remediation usually entails workshops with Enterprise Architects to specify a complete, detailed reference architecture.

Infrastructure Low scores in this domain usually indicate that the BA infrastructure is lacking significant elements. Infrastructure installation and configuration type projects are common remediation activities.

Information Low scores in this domain usually indicate issues with the information architecture, data quality approach, and/or information stewardship. Common remediation activities are workshops to address the causes for the low scores and/or EIM projects to improve architecture capabilities.

Operations, Administration & Management

Remediation activities for low scores in this domain usually entail definition, documentation, and enforcement of BA compatible OA&M procedures. Low scores could be due to lacking BA knowledge/skills or could be due to a low maturity of OA&M in general.

Projects, Portfolios & Services

Low scores in this domain usually indicate a lack of BA compatible management and delivery processes. Common remediation activities entail workshops to modify existing management and delivery processes to inject BA best practices.

Organization Low scores in this domain usually indicate that roles and responsibilities appropriate for BA have not been instituted within the organization. There may also be a lack of BA knowledge/skills. Common remediation activities include developing training plans and workshops to define the necessary roles and responsibilities. Remediation may also require organization restructuring.

Governance Most organizations have existing IT governance in place, so low scores in this domain usually indicate that governance has not been extended to cover BA. Remediation usually requires a workshop to define and institute the governance extensions required for BA.



1.3.4.1 OverviewThere are five steps in this final phase of the process to create a BA Roadmap. These five steps are illustrated in Figure 1–10.

Figure 1–10 Activity Scheduling Process

As shown in the diagram, the main inputs to this phase are the remediation activities identified in the gap analysis phase and the portfolio of BA projects that have already been identified. The final step is to determine timelines and dependencies and organize all the activities into a schedule.


1.3.4.2.1 Determine Program-Level Activities

The program-level activities are determined by prioritizing the remediation activities identified in the gap analysis phase. Top priority is usually given to remediation activities that focus on the domain with lowest current maturity score. Top priority remediation activities are usually the first activities in the roadmap since the results from these activities are leveraged across the project delivery efforts.

Program-level activities frequently entail changes with wide ranging impacts. For example, changing the software development process (to inject newly defined best practices) impacts all development teams within the scope of the BA initiative. Organizational changes can be even more taxing. Therefore, it is usually necessary to undertake these changes in a series of iterations. These iterations become the phases of the overall BA Roadmap. At a high level, this can be shown graphically as illustrated by Figure 1–11.



Figure 1–11 Increasing Maturity Over Time

The graph illustrates three iterations each increasing maturity of one or more domains until the desired 'vision' level of maturity is achieved. Notice that the first phase focuses on bringing all domains up to the 'Systematic' level of maturity. This means that the first phase will primarily include remedy activities for the Business & Strategy, Information, and Governance domains. Once near parity is achieved across domains, follow-on phases address the eight domains more uniformly to keep the BA initiative progressing smoothly.

The amount of change introduced by an iteration must not exceed the organization's ability to absorb that change; therefore the scope of each iteration must be carefully planned. Likewise, the duration of each iteration must be long enough to accomplish some meaningful progress, yet remain short enough to minimize risk and maintain a continuous pace of incremental progress.

1.3.4.2.2 Create Program Activity Overview

Once a set of program-level activities for this iteration has been determined, further information will need to be captured for each activity in order to create a roadmap. This information includes the earliest likely start date, the expected time until completion, the list of deliverables, and any dependencies that the activity has on other activities.

Some of this information, particularly the begin and end dates, may depend on who, or which group, is doing the work. Therefore, it is beneficial to determine who the responsible parties are for each activity. A RACI chart can be used for this purpose. This form of chart captures who is responsible, accountable, consulted, and informed for each activity. Figure 1–12 illustrates a sample RACI chart that captures the information described in this section.



Figure 1–12 Program Activity Overview and RACI Chart

The chart includes six remediation activities that have been selected for this iteration of the roadmap. Each activity has been assigned one person that is accountable for ensuring that the activity is completed properly. This person may or may not be responsible for actually completing the activity. The person who is accountable may delegate responsibility for completing the activity to one or more other persons.

In addition to the accountable and responsible parties, the chart recognizes that some people may need to be consulted prior to the completion of the activity. The 'consulted' parties are recognized for their potential interest, input, and guidance on how the activity is performed. Others may need to be informed when the activity has been completed. The 'informed' parties are noted as having an interest in the completed work as they may be directly affected by the outcome.

1.3.4.2.3 Identify Remediation Projects

There are several different types of remediation activities that can be performed. Some may be performed through workshops, meetings, and strategy sessions. Others may require the definition and delivery of a project.

Remediation activities for Infrastructure and Information domains are the most likely to result in project delivery. They identify many capabilities of BA that are more directly supported by various types of infrastructure. Other domains may also identify capabilities that are indirectly supported or enhanced using infrastructure, therefore they may also contribute to remediation project requirements.

Remediation projects can be classified as either program-level or project-level activities. If the project delivers a solution that is primarily intended to benefit the BA program and other projects, then it should be classified as a program-level activity. However, if the project delivers a solution that primarily addresses specific business needs, then it should be classified as a project-level activity. Funding may also factor into the classification if program and project funding are provided by different sources.

1.3.4.2.4 Identify Project and Activity Dependencies

The purpose of this step is to determine if there are any relationships or dependencies between the remediation activities that have been defined and the BA projects that are currently scheduled to begin or are already in flight. This enables the gains in maturity that are obtained via remediation activities to be recognized by the projects, as applicable. It also helps to avoid any rework or duplication of effort that may occur if work that is being performed as part of a project happens to be included in, or affected by, a remediation activity.



When considering the effect a remediation activity has on a particular project, a number of factors may be considered:

■ Will the activity make the project easier to complete? For instance, will it help reduce complexity or provide features or functionality that the project would otherwise need to develop?

■ Will it help reduce (or increase) project cost or delivery time?

■ Will it improve the project results? For example, will it make analysis more consistent or accurate? Will it make analysis more agile or interactive? Will it produce a higher quality deliverable?

■ Will it increase the likelihood that the project will be viewed as a success?

■ Will it improve any of the non-functional project qualities such as reliability, availability, scalability, performance, and security?

The remediation activity, applied to a particular project, may also have great benefits or consequences to the larger BA program. For instance, if a project requires the deployment of new infrastructure, and a remediation activity is defined to evaluate infrastructure vendors and recommend a technology standard, then it would be very beneficial to the program to ensure that the project uses the technology standard that is evaluated and selected for the program. Otherwise, the project may deploy a technology that is soon afterward rejected as a standard. In addition to the cost and effort of potential rework, the program will be set back in its effort to raise its level of maturity. The project may also inadvertently undermine the goals and principles that the program has just defined.

To aid in dependency analysis, the overview chart from the previous step has been modified to identify project relationships in place of RACI assignments, as shown in Figure 1–13.

Figure 1–13 Project / Activity Dependency Analysis

The chart includes five projects that happen to be defined in the BA Project Portfolio. They are projects that are either scheduled to begin during this iteration of the roadmap or have recently begun. Each remediation activity is assessed for each project. The objective is to determine how important it is to the program and the project for the remediation activity to be completed and applied to the project.

A determination is made given the time constraints each project has, and the applicability and value of each remediation activity. The determination may follow a simple 4-option choice:

■ Must. The project must leverage the outcome of the remediation activity. Scheduling issues must be resolved in order to make this happen.



■ Should. The project should leverage the outcome of the remediation activity. A variance may be requested and obtained if circumstances make it infeasible.

■ Could. The project could leverage the outcome, if it is conveniently available.

■ Won't. The project will not be affected by the remediation activity, or a variance to avoid being affected has been obtained.

As indicated in Figure 1–13, there are four instances where a remediation activity has a 'must' relationship with a project. Furthermore, a special relationship exists between Project 3 and RA 3. RA 3 is actually a remediation project that is designed to deliver a shared data warehouse for unstructured data. Project 3 happens to require such a data warehouse. Therefore, RA 3 will base its initial set of requirements on the needs of Project 3, and it will deliver the data warehouse in time for Project 3 integration testing.

Since, in this example, projects are funded by the line of business, RA 3 is tracked as a remediation activity rather than a project. The BA program will be able to accomplish one of its objectives using an existing, funded project.

1.3.4.2.5 Create the Combined Schedule

The combined schedule illustrates the orchestration of program-level activities and projects over time to achieve the greatest overall benefit. The schedule is based on information assembled in Figure 1–13 and refined in order to account for program-level deliverables that are desired by projects but may not be available until after the project is underway.

The first step is to create a timeline, beginning with the current time, and spanning the first iteration of the roadmap. Weekly time intervals are generally convenient to work with. Next, overlay the program-level activities and projects according to their start times and durations. Begin with only the activities that are not dependent on other activities. Add in the dependent activities afterward so that they do not begin until the deliverables they are dependent upon are scheduled to be completed.

Once this is finished, the dependencies between program-level activities and projects can be addressed. Start with dependencies that are rated a 'must' as shown in Figure 1–13. Ensure that the deliverable from the program-level activity will be available at the time the project needs it. Deliverables will not always be needed at the start of the project, particularly if they address issues in later stages of the project, such as testing, deployment, and maintenance.

Adjustments may need to be made to the schedule, or to the scope of the deliverable, in order to have it completed by the project's 'need by' date. Negotiate the necessary changes and adjust the schedule and activity overview accordingly. Complete all of the 'must' relationships before moving on to the 'should' relationships.

Repeat the same procedure for instances where a project 'should' leverage the output of a program-level activity. Make adjustments to the schedule as needed in order to accommodate as many cases as possible. For those cases where scheduling does not permit the inclusion of program-level deliverables into the project, determine a best effort alternative and grant a variance.

Lastly, identify the areas where projects can use program-level activity deliverables as indicated by a 'could' relationship. Since these instances are by definition 'best effort', it isn't necessary to go to great lengths to accommodate these requests.



Figure 1–14 Roadmap Phase 1 Schedule

Figure 1–14 serves as a basic example of how the roadmap may be organized. It is divided into two sections: the top section contains program-level activities, and the bottom section contains projects. The program-level activities are identified using remediation activity (RA) numbers for sake of simplicity. RA-3, in this example, is also identified as an infrastructure project.

Hard dependencies, e.g. 'must' relationships, between activities and projects are denoted with solid lines. The lines originate from the point in time where the deliverable is completed to the point in time where it is needed. In some cases the 'needed by' date is the beginning of an activity or project, while in others cases it is some point in time during the life cycle of the project. In contrast, dashed lines are used to indicate a 'should' relationship.

Three additional activities have been added to the diagram: "BA Leadership", "Align Program Accomplishments and Deliverables with Projects", and "Phase 2 Planning". The first two identify ongoing activities that are required in order to continually advance the program. Additional such activities may be added to represent the work of a 'Center of Excellence' or similar group that is chartered with mentoring and establishing best practices. Phase 2 Planning represents a reassessment of BA Maturity as a result of the first phase of remediation. The deliverable from this activity is the detailed roadmap for the second phase.

In Figure 1–14 the link between program-level deliverables and projects is mediated by the alignment activity. The intent is to actively facilitate the use of these deliverables in order to advance the program. The diagram includes vertical arrows to represent the acceptance of program-level deliverables. It uses the same arrows to indicate where deliverables are used by projects, representing the 'could' relationship from the previous section.

As mentioned earlier, the detail in the initial phase of the BA Roadmap will be much greater than the detail provided for the later phases. The later phases likely include additional program-level activities and more projects, but will contain less detail since precise dates are more difficult to predict. An example of such a schedule is shown in Figure 1–15.

Closing Comments


Figure 1–15 BA Roadmap Subsequent Phases

The first phase schedule was broken down into weeks but only covered two quarters. This schedule covers the entire planning horizon (three years) but with significantly less detail.

The program-level activities chosen for the first phase were meant to address the most pressing needs and deficiencies. The activities undertaken in subsequent phases may be selected based on knowledge of specific projects and business initiatives that are being planned. This foresight can be used to make the dependency analysis and scheduling process more beneficial and advantageous.

1.3.4.3 OutputThe output from the roadmap creation phase is the BA Roadmap that includes a detailed initial phase and less detailed subsequent phases. The BA Roadmap provides guidance for achieving the goal of the BA initiative via a series of much smaller transitions. Ideally, each of the smaller transitions has its own individual business benefit, but it is frequently necessary to invest a little up front to reap larger benefits down the line.

1.4 Closing CommentsIt is important to keep the end goal in mind when applying this roadmap creation process. The end goal is achieving the goal of the BA initiative. It is NOT to attain a particular score on the BA Maturity Model. The success of the BA initiative is measured by the realization of the prioritized BA benefits identified in the Future Vision Definition phase. The BA Maturity Model and the various frameworks are merely tools to help build a plan to achieve the goal.

Finally, and perhaps most importantly, this is an incremental approach. The process described in this document to create a BA Roadmap should be regularly re-applied and the roadmap should be updated to reflect the changing reality. This allows each iteration of the process to focus on the most pressing needs. Areas not of immediate concern can be relegated to future iterations, thereby reducing the size and complexity of the current iteration.

A

BA Maturity Model A-1

ABA Maturity Model

The Oracle BA Maturity Model defines the following key concepts: capabilities, domains, maturity, and adoption.

A.1 CapabilitiesThe BA Maturity Model includes over eighty capabilities that capture the best practices that Oracle has collected over many years working with a wide variety of companies. There is still considerable debate on what constitutes BA best practices and standards, and products change fairly regularly, therefore the BA Maturity Model remains technology, standards, and product agnostic while still capturing the major tenants of a complete BA strategy.

Additional capabilities are added as the field of BA evolves. Thus, the details of the BA Maturity Model will continue to evolve as new technologies and capabilities emerge. This allows the specifics to morph and improve as industry and Oracle knowledge of BA advance. One of the capabilities from the maturity model is shown in Figure A–1.

Domains

A-2 Creating a BA Roadmap

Figure A–1 Integrated Analysis Capability

As shown in the above figure, for each capability included in the model, a description for each level of maturity and each level of adoption is provided. (The maturity and adoption levels are defined below.) Although there is always some level of subjectivity when measuring a capability, these descriptions minimize the subjectivity injected, and thereby provide, as best as possible, an objective measure of both maturity and adoption.

A.2 DomainsThe BA Maturity Model uses the concept of domains to classify and organize the related capabilities. As depicted in Figure 17, there are eight domains in the maturity model:

Domains


Figure A–2 BA Capability Domains

■ Business & Strategy - Contains capabilities that provide the high-level constructs that allow the BA initiative to proceed. This includes such things as business motivation, expected benefits, guiding principles, expected costs, funding model, etc.

■ Architecture - Contains capabilities concerning the definitions of the overall architecture and guidelines for various practitioners to ensure adherence to the architecture.

■ Infrastructure - Contains capabilities concerning the infrastructure and tools that provide the technical foundation for the BA initiative.

■ Information - Contains capabilities concerning the information aspects of BA, e.g., providing information acquisition, management, virtualization, and access capabilities.

■ Projects, Portfolios & Services - Contains capabilities concerning the planning, building, and delivery of BA projects and services.

■ Operations, Administration & Management - Contains capabilities concerning the post deployment aspects of BA solutions i.e. the Operations, Administration, and Management aspects of BA.

■ Organization - Contains capabilities concerning the development of corporate competency around BA including the organizational structure and skills development.

■ Governance - Contains capabilities concerning the governance structures and processes that support and guide the BA efforts. Maturity and adoption of an adequate amount of governance is a leading indicator of the overall BA success.

These eight domains, although interrelated, are sufficiently distinct. To succeed at BA adoption, an organization must make adequate progress in all of these domains. Inevitably an organization will be more advanced in some domains (and further in some of the capabilities within a domain) than others. Therefore, it is important to be able to measure the relative maturity within each domain (and capabilities therein)

Maturity


and across domains to identify areas that are lagging. Once the lagging areas have been identified it is possible to formulate remedies and thereby improve the success of the overall BA program.

A.3 MaturityWithin the software industry, maturity is frequently related to the Capability Maturity Model (CMM) and the CMM successor, the Capability Maturity Model Integration (CMMI). The BA Maturity Model parallels this understanding and measures BA capability against defined maturity levels. The levels of maturity used in the BA Maturity Model (from highest to lowest) are:

■ Optimized - Metrics are being consistently gathered and are being used to incrementally improve the capability. Assets are proactively maintained to ensure relevancy and correctness.

■ Managed - The capability is being measured and quantitatively managed via some type of governance structure. Appropriate metrics are being gathered and reported.

■ Systematic - The approach has been reviewed and accepted by affected parties. There has been buy-in to the documented approach and the approach is always (or nearly always) followed.

■ Opportunistic - An approach has been decided upon and is being opportunistically applied. The approach has not been widely accepted nor adopted. It may be incomplete, informally defined, or if documented, may exist primarily as "shelf ware".

■ Ad Hoc - Decisions are based on individual perceptions and practices. There is no common BA strategy, data definitions, or formal measures defined.

■ No BA - There is no BA approach being taken. Decisions and forecasts are based on intuition and/or routine.

The maturity levels progress from 'No BA' up to 'Optimized.' These levels define the path an organization usually takes moving toward BA maturity. BA by its very nature requires coordination, cooperation, and a common vision to be successful; therefore, it is necessary to define the strategy before it is possible to be truly successful at repeating it and then ultimately optimizing it.

A.4 AdoptionAdoption measures how widely BA best practices are being defined, accepted, embraced, and applied within the enterprise. For smaller organizations within a single line-of-business, maturity and adoption are usually tightly related since there is a single approach to BA being followed by the entire organization.

However, within large companies with multiple divisions or lines-of-business this is not usually the case. It is common to have one or more divisions that are relatively mature in BA while other divisions are less so. The BA Maturity Model handles these situations by providing a separate measure for adoption level. This allows a single division to be effectively evaluated for BA maturity while still capturing the lack of widespread adoption as a separate measure.

The levels of adoption used in the BA Maturity Model are:

■ Enterprise Level - The capability is implemented consistently across the enterprise i.e. all divisions or business units are applying the same approach.

Adoption


■ Cross Division - The capability is implemented by multiple divisions using a common approach i.e. the approach is being shared or is spreading to multiple divisions.

■ Division Wide - The capability is implemented consistently across a division or business unit. A division or business unit is led by an executive at the VP level or higher.

■ Department Level - A directive for adoption exists at a lesser scope than the division. The scope may be a department or program within a division with leadership at the manager or director level.

■ Individual Level - No formal directive for adoption exists or is being followed. Uniformity is a function of the sharing and voluntary adoption of best practices amongst individuals or projects / solutions within an organization.

■ No Implementation - There is no current implementation anywhere in the organization of the capability being measured.

For small organizations, it may be desirable to ignore the adoption dimension altogether and simply measure maturity. Conversely, for very large organizations with a goal of achieving enterprise-wide BA adoption, it may be desirable to measure the maturity for each division or line-of-business separately and then provide a single measure of adoption across the enterprise. It should be noted, however, that for the realization of many of the key BA benefits, a level of adoption across the organization is critical. For example, it is possible to have two divisions with mature but incompatible capabilities in which case the adoption is lower (division-wide) and that will inhibit an enterprise-wide BA initiative.

Thus, to properly measure the overall progress of BA initiative in a large organization, the maturity of the individual capabilities and the degree of adoption of such capabilities across the organization is vital.

Adoption


OPG Creating a BA Roadmap, release 3 - Oracle · Creating a BA Roadmap 1-1 1 Creating a BA Roadmap...

Documents

Transcript of OPG Creating a BA Roadmap, release 3 - Oracle · Creating a BA Roadmap 1-1 1 Creating a BA Roadmap...