Oracle Business Analytics Strategy Whitepaper

8/9/2019 Oracle Business Analytics Strategy Whitepaper

1/18

IT Strategies from Oracleto Business Analytics


2/18

IT Strategies f rom Oracle Oracles Approach to Business Analytics

Introduction ....................................................................................... 2

Business Analytics Program .............................................................. 3

Business Analytics Roadmap ............................................................ 4

Capabilities .................................................................................... 5

Domains ........................................................................................ 5

Maturity ......................................................................................... 6

Adoption ........................................................................................ 6

Measuring Progress ...................................................................... 7

BA Strategy and Planning.................................................................. 8

Oracle Reference Architecture ....................................................... 8

BA Reference Architecture ............................................................ 9

BA Engineering ........................................................................... 12

BA Governance ........................................................................... 14

BA Projects and Infrastructure ......................................................... 16

Conclusion ...................................................................................... 16


3/18

IT Strategies from Oracle Oracles Approach to Business Analytics

2

Introduction

The advent of new technologies and opportunities with Big Data has ushered in a new wave of

interest in business analytics. Many companies are in the midst of deploying new solutions or

are starting to determine how they can leverage these new technologies. Meanwhile, IT

organizations are also dealing with ongoing information management and business intelligence

demands, often sidestepping the larger problems of database sprawl, the complexity of

integration, and concerns about information governance. They are split between moving ahead

with new types of solutions while trying to manage existing technologies. They need an

approach that will allow them to do both in a clear and logical manner.

It is quite common for new technologies to take root within an organization from the ground up,

i.e. progressive minded individuals tease out various ideas that may end up providing some

benefits to the business. This activity may spawn projects that are more formally defined with

the intent of exploiting these new capabilities. The challenge is: what happens next? Once an

organization finds value in a new technology, how does it go from a skunk works project to

mainstream IT, and how does it affect existing IT operations?

This is where enterprise architecture comes into play. Enterprise architecture involves strategic

planning to look at the bigger picture of how to capitalize on the new technology and

incorporate it into the larger ecosystem of IT. It helps to properly position business analytics

within the organizations business, application, information, and technology architectures. Italso looks at how to best incorporate new technologies into the stable of existing technologies,

solutions, and preferred products. It aims to avoid having new technologies sprout up and

diverge in ways that add unnecessary risk and complexity to IT.

Strategic planning has obvious benefits but one must not ignore that fact that there are also

tactical issues to be addressed. Projects must continue forward and IT must continue to deliver

value. Therefore, Oracle recommends a pragmatic approach - one that focuses on a strategic

vision, yet tactically delivers value in a manner that drives the organization toward the vision in

achievable increments.

Oracles approach to business analytics (BA) provides the process necessary to help develop

a strategy that aligns IT initiatives with business goals. It provides a means to measure the

proficiency of the organization with respect to business analytics. It offers insights into several


4/18


3

key aspects of BA strategy and planning. And, it provides a means to pragmatically deliver

value and improve proficiency over time.

Figure 1 - Oracle's Approach to Business Analytics

Figure 1 illustrates how the approach is partitioned into three focus areas, each with its own

defined scope. Assets at the Enterprise Scope pertain to strategic IT and enterprise

architecture plans and roadmaps that span the breadth of IT. They apply to all programs and

initiatives within the organization; hence they act as inputs to the Business Analytics Program.

The focus area entitled Business Analytics Program Scope pertains to a subset of IT strategythat applies specifically to business analytics. It includes activities for roadmap creation,

strategy development, and planning. In terms of organizational breadth, the program may span

the entire enterprise; however in terms of operational scope, it is focused solely on business

analytics.

Project Scope refers to activities at the project level, and in particular, projects that have

business analytics capabilities.

Business Analytics Program

To maximize the value of information technology within an organization, steps must be taken

to discover, communicate, and adopt best practices. This enables the organization to learn

from both successes and failures and to focus resources on the most important activities at

hand.


5/18


4

While an enterprise architecture group can fulfill this role, it is generally focused on higher level

activities that pertain to the goals and initiatives of IT. In addition, the enterprise architecture

group may not consist of all of the most knowledgeable people for a specific technology

strategy. Given this, it makes sense to recognize groups of people and aspects of technology

that share a common purpose. These people can be brought together (physically or logically)

to form a program. The program does not require organizational changes or hiring for new

positions; it can be comprised of a virtual team that is represented by people across existing

organizational structures. The intent of the program is to address all aspects of a given

strategy that will enable the organization to achieve the greatest benefits and turn the new

technologies into an organizational strength. The enterprise architecture group can help staff

the program and provide strategic guidance based on IT strategy and an overall IT roadmap.

A business analytics program focuses on all forms of business analytics. This includestraditional business intelligence reports, dashboards, and applications, as well as current

trends in Big Data and advanced analytics. It can encompass aspects of information

management, such as data warehousing and data quality management, or it can work in

conjunction with other programs that address related forms of information architecture.

In order to understand the maturity of the organization with respect to the program, Oracles

approach to business analytics includes a maturity model. It also includes various subjects of

strategy and planning which help to define, improve, and standardize ones approach to

business analytics.

Business Analytics Roadmap

Oracle has created a BA Maturity Model that can be used to measure the progress of a BA

initiative and, more importantly, can identify specific capabilities that are lacking or lagging.

These lagging capabilities will often impede the efficiency and/or effectiveness of the BA

initiative. A remediation approach for each of the identified inhibitors can be determined from

industry best practices and prior experiences. These remedies can then be prioritized and

used to create a plan, called the BA Roadmap, to put the BA initiative on track.

Having a BA Roadmap based on a comprehensive BA Maturity Model that is constructed using

a proven approach and is based on years of collected experience enables the organization to

incrementally improve the maturity of the program while simultaneously delivering new BA

solutions.


6/18


5

Capabilities

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. 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 more best practices emerge. Thus, the details of the BA

Maturity Model will continue to evolve over time. This allows the specifics to morph and

improve as the industry and Oracles breadth of experience advances.

For each capability included in the model, a description for each level of maturity and each

level of adoption is provided. Although there is always some level of subjectivity when

measuring a capability, these descriptions minimize the subjectivity injected, and therebyprovide, as best as possible, an objective measure of both maturity and adoption.

Domains

The BA Maturity Model uses the concept of domains to classify and organize the related

capabilities. As depicted inFigure 2,there are eight domains in the maturity model.

Figure 2 - BA Capability Domains


7/18


6

These eight domains, although interrelated, are sufficiently distinct. To be truly successful, 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) 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 initiative.

Maturity

Within 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 maturity levels progress from 'None' 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.

Adoption

Adoption measures how widely BA best practices are being accepted, embraced, and appliedwithin 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 with BA while

other divisions lag behind. 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.

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

consistent 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


8/18


7

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

Measuring Progress

In order to properly measure the overall progress of the 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. Maturity and adoption levels for some or all of the capabilities or forthe domains can be plotted as shown inFigure 3.

Figure 3 - BA Maturity Model - Measures both maturity and adoption levels


9/18


8

Generally, the most effective planning horizon for a BA Roadmap is 1-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 Roadmap should be regularly reviewed and

updated. The business never stays static, so do not expect the BA Roadmap to remain static

either.

It is important to keep the end goal in mind when applying this roadmap creation process and

especially when executing against the roadmap. 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 BA Roadmap is designed to coordinate many types of activities based on various

business and technical priorities. The activities span several disciplines including strategy andplanning, infrastructure deployment, and project delivery. An important aspect of the roadmap

is the ability to balance both strategic and tactical objectives to progress toward a strategic

vision while delivering solutions to meet todays business needs.

For more details, please refer to the Oracle Practitioner Guide: Creating a BA Roadmap.

BA Strategy and Planning

BA strategy and planning comprises a number of means to define a strategic vision and help

guide the delivery of projects toward that vision. BA strategy and planning includes the

definition of a reference architecture and the refinement of engineering and governance

processes. These strategy and planning activities can be performed in parallel to the

development of the BA Roadmap. They can also be scheduled and performed as part of the

roadmap in order to address deficiencies or inconsistencies that are identified during the

maturity assessment.

Oracle Reference Architecture

Oracle Reference Architecture (ORA) is a product-agnostic reference architecture based on

architecture principles and best practices that are widely applicable and that can be

implemented using a wide variety of products and technologies. ORA addresses the building of

a modern, consistent IT architecture while minimizing the risk of product incompatibilities and

obsolescence.


10/18


9

ORA is designed to be extensible to support new and emerging technologies. It includes

documents that describe core computing capabilities, such as information management,

integration, and security. It also includes several perspectives. These perspectives extend the

core material by adding capabilities that enhance the computing environment. Perspectives

often describe new, optional, or revolutionary computing strategies such as service-oriented

architecture (SOA), business process management (BPM), or Cloud Computing. ORA includes

a business analytics perspective that describes a BA reference architecture and presents

architectural concepts. It highlights the specific details of BA as an elaboration of the ORA core

concepts with respect to this technological approach.

BA Reference Architecture

The ORA Business Analytics perspective is comprised of the BA Foundation and BA

Infrastructure documents. The BA Foundation document includes concepts, standards,definitions, and the conceptual view of the architecture. The BA Infrastructure document

relates the capabilities, as defined by the business-centric conceptual view, to technology-

centric logical architecture views. It also provides architecture principles, a deployment view,

and a mapping of the logical view to Oracle products.

The BA reference architecture helps organizations avoid common problems associated with

technology initiatives, such as:

Accidental Arch itectures: When business requirements are captured and

implemented locally by individual project teams, over time they evolve into an

architecture that is less than efficient. Accidental architectures and technology silos

are avoided by adopting a common reference architecture that can be applied across

the enterprise.

Myopic Solutions: When project teams dont think strategically, they build myopic

solutions that may not be future-proof. This means that the solutions will need to

change often, as the business or other parameters change.

Quality Issues: Without a reference architecture, core principles and best practices

may not be followed. This may lead to software quality issues that are costly to fix.

Compliance Violations: A BA reference architecture ensures that any requirements

related to architecture compliance are captured and the architecture components to

satisfy those requirements are clearly identified.


11/18


10

Incompatibility: A reference architecture ensures that various solution components

can be integrated amongst themselves and to the external solution components using

standards-based interfaces.

Technology Obsolescence: Systems may get obsolete faster than one thinks. It is

important to ensure that the enterprise is running on the latest and greatest

technologies to give the business the competitive edge that it requires. If technology

trends are not taken into account when architecting solutions, it may lead to brittle

architecture that may break in the near future.

Redundancy: Redundant efforts lead to duplication and inconsistency and cost time

and money to the enterprise. If the learning and experiences from the project teams

are not documented and distributed appropriately, this will result in reinventing of the

wheel as each project is going to duplicate efforts and try to solve the same problems.

Inconsistent Terminology: Terminology inconsistency may lead to larger issues from

a communications problem to major architectural flaws that will hinder integration of

applications and systems.

Product Misuse: BA infrastructure products may be misused or not fully leveraged.

It is important that the BA reference architecture is documented from multiple views. Each view

might include multiple models to illustrate the concepts and capabilities that are important for

that view. The particular choice of views depends on what material is being covered and which

views best convey the information. Example views include conceptual, logical, product

mapping, and deployment views. SeeFigure 4 for an example high-level conceptual view that

shows the key feature sets of the BA reference architecture.


12/18


11

Figure 4 - BA Reference Architecture - Conceptual View

Refer to the Oracle Reference Architecture document: ORA Business Analytics Foundation for

a complete description of the conceptual view.

Figure 5 illustrates one of the logical views. This view provides a technical representation

depicting logical components that provide the capabilities of the conceptual view. It includes

component relationships based on the conceptual layering. The logical view is product

agnostic so as to describe the solution architecture without being dependent on any specific

products. The BA product mapping view provides the mapping of Oracle products to the logical

components.


13/18


12

Figure 5 - BA Reference Architecture Example Logical View

Refer to the Oracle Reference Architecture document: ORA Business Analytics Infrastructure

for information on all of the logical architecture views.

The BA reference architecture must be seen as a living document whereby incremental

releases of the reference architecture will be produced at regular intervals during the execution

of the BA Roadmap.

BA Engineering

Software engineering for BA solutions is not radically different from traditional software

engineering, but some steps may be needed to ensure that the organization deploys solutions

that are complete and consistent with adopted best practices. These steps support variations

in the software development life cycle (SDLC) such as:

The recognition that requirements and design should be examined from both the

analytics and information viewpoints. These viewpoints may be somewhat different

and abstracted from each other.


14/18


13

A division of labor between end users and IT staff. Traditional projects are often

performed entirely by IT staff, whereas analytics solutions may be crafted by end users

with only supporting roles fulfilled by IT. Care should be taken to follow the reference

architecture regardless of which group is responsible for delivery. Otherwise, a

shadow IT can emerge as more and more business solutions are designed and

deployed without the knowledge or guidance of IT.

A build-vs.-buy step that acknowledges the fact that some solutions can be purchased

to satisfy some or all business requirements. Pre-built analytics solutions often include

reports, dashboards, data models, and data movement processes for popular

applications.

An examination of existing SOA Services to satisfy some of the information or analysis

needs. Conversely, an evaluation of requirements to determine if SOA Services should

be developed to support reuse of assets on future projects.

The deployment of solutions following either traditional or Cloud-based models. The

choice of deployment scenario can greatly affect SDLC activities.

Steps to accommodate cataloging and reuse of analytics and/or information assets

across projects.

Figure 6 highlights engineering tasks that should be added or examined for delivering BA

solutions.

Figure 6 BA Engineering Tasks

Topics covered at the program scope should include:


15/18


14

Inception: provides a checklist of items that should be considered when stating the

requirements of a project.

Elaboration: proposes a set of activities that allow the project to be delivered in

different ways by providing both the checkpoints to ensure that proper architecture and

governance are being applied and decision points that enable the project to proceed

along the most appropriate course depending on factors that are unique to the project.

Construction & Transition: provides information to guide the development of projects

and activities that follow the transition to a production state.

BA Governance

Like any other technology initiative, BA initiatives need to be governed to ensure that the

benefits envisioned are realized and maximized. BA assets should be managed to promote

consistency and accuracy. They should also be documented and cataloged in order to provide

reuse across the organization.

Oracle has defined a generic unified governance framework that applies to all enterprise

technology strategies. This framework is illustrated inFigure 7.

Figure 7 - Unified Governance Framework

The governance model can be categorized as five inter-related groups as explained below.

Asset Portf ol io Governance: A key area for BA Governance is in the area of BA

Portfolio Management, which manages BA projects, assets, and associated metadata

in a holistic manner and is a key enabler for asset discovery and consumption. In


16/18


15

addition, Asset Portfolio Management must support dependency tracking and impact

analysis, and measure and communicate compliance.

Design-Time Governance: Design-Time Governance requires the visibility and

traceability of assets throughout the entire lifecycle. The SDLC process must be

tweaked if necessary to include additional gates and roles to ensure quality and

compliance of BA solution delivery.

Operational Governance: Once deployed, BA infrastructure and solutions must be

managed and monitored. Policy management and enforcement is required to ensure

that constituent components operate as intended, within design parameters. This is

critical for visibility into policy compliance and Quality of Service (QoS) metrics.

Vitality Governance: It is imperative that the BA investments made by an enterprise

are routinely reviewed, and remains current, accurate, and most importantly, relevant.

In essence enterprises should view their BA investments as living assets and execute

a continuous improvement feedback loop to maintain their value and relevance.

Organization Governance: BA Governance requires the establishment of a viable

and pragmatic organizational and change management model. It may require updates

or creation of new governance structures to define/monitor and enforce policies

surrounding the enablement of the BA initiative. BA generally does not require radical

changes to the organizational structure but may benefit from minor adjustments. Tools

must be utilized to ease and automate as many processes and policies as possible.

BA Governance Continuous Improvement Loop enables enterprises the ability to define and

deploy their own focused and customized BA Governance model. This is illustrated inFigure 8.

Figure 8 - BA Governance Continuous Improvement Loop


17/18


16

BA Projects and Infrastructure

BA projects and infrastructure both provide analytics capabilities to the organization. Projects

tend to be scoped to a particular business need or set of business requirements. Infrastructure,however, is often used by multiple projects. The intent is to provide a set of capabilities that

can be leveraged across projects that will make future deliverables better, easier to produce,

more consistent, less risky, etc.

Projects and infrastructure are closely related and sometimes refer to the same thing. For

instance, infrastructure may be installed as one part of a larger project, or it may represent the

entire scope of a project. The latter case can be termed an infrastructure project.

BA infrastructure should not be taken lightly, rather it should be seen as the "realization" of the

reference architecture which is aligned with IT and business strategies. As such, Oracle

recommends developing a reference architecture and deploying infrastructure in a manner that

both supports the BA strategy and the BA projects that are soon to be developed. The BA

Roadmap is used for the purposes of coordinating project and infrastructure timelines.

Conclusion

Business analytics is proving itself to be a key differentiator in todays business environment.

The emergence of Big Data and real-time analytics is providing new revenue streams and

making existing revenue streams more effective. As with all new technologies, businessesneed to capitalize on the opportunities while reducing risk. Likewise, IT must find a way to

balance strategic planning with tactical execution.

Oracles approach to BA offers a pragmatic approach to achieve both strategic goals and

tactical initiatives. It is based on a systematic maturity assessment that paves the way for a

strategic roadmap to accelerate the maturity and adoption of BA in your enterprise. Oracle has

defined the BA Reference Architecture that describes a unified environment where traditional

data warehouse technologies and Big Data work in concert to satisfy modern-day BA needs.

Oracles software, hardware, and engineered systems provide the capabilities required to

implement a scalable and reliable BA infrastructure to support the needs of the business.

Oracle also offers expert services to help you create your architecture vision, plan your BA

Roadmap, and execute on that plan. Please contact your local sales representative for more

information on Oracles products and services.


18/18

Oracles Approach to Business Analytics

September 201

Author: Dave Chappelle

Oracle Corporation

World Headquarters

500 Oracle Parkway

Redwood Shores, CA 94065

U.S.A.

Worldwide Inquiries:

Phone: +1.650.506.7000

Fax: +1.650.506.7200

oracle.com

Copyright 2013, Oracle and/or its affiliates. All rights reserved. This document is provided for information purposes only and the

contents hereof are subject to change without notice. This document is not warranted to be error-free, nor subject to any other

warranties or conditions, whether expressed orally or implied in law, including implied warranties and conditions of merchantability or

fitness for a particular purpose. We specifically disclaim any liability with respect to this document and no contractual obligations are

formed either directly or indirectly by this document. This document may not be reproduced or transmitted in any form or by any

means, electronic or mechanical, for any purpose, without our prior written permission.

Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.

AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices.

Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license

and are trademarks or registered t rademarks of SPARC International, Inc. UNIX is a registered trademark licensed through X/Open

Company, Ltd. 1010

Date post:	01-Jun-2018
Category:	Documents
Upload:	raul-goycoolea-seoane
View:	224 times
Download:	0 times

Oracle Business Analytics Strategy Whitepaper

Documents