WHITE PAPER - eBulletins · This whitepaper seeks to help clarify what types of customizations are typical of the OBIA solution. Whether using a Peoplesoft, E-Business Suite, JD Edwards,

Oracle BI Applications (OBIA) customers who have had a successful implementation of the analytics solution know that to see material value in their investment, customization (i.e.: tailoring) through extending the OBIA solution is a must. Customization is needed in order to align the Oracle BI Application module’s out-of-the-box (OOTB) commercial-off-the-shelf (COTS) solution with each Oracle customer’s business. It is also necessary in order to stay consistent with existing customizations of ERP or CRM systems on which the Oracle BI Application solution will be based. This whitepaper will provide an overview of the various facets, options, and necessities of an OBIA customization. We will also cover some basic definitions and distinctions that are important to understand when working through such a complex project.

Christian Screen

Oracle BI Applications: Understanding Levels of Customizations

WHITE PAPER

ABSTRACT:AUTHOR:

Oracle BI Applications: Understanding Levels of Customizations

What is an Oracle BI Applications Customization? ........................................................................

Customization Levels ............................................................................................................................

Tweak vs. Customization ......................................................................................................................

Testing is Paramount to Successful Modifications ..........................................................................

Customization Across the Different OBIA Layers ...........................................................................

Presentation Layer ..........................................................................................................................

Metadata Repository .....................................................................................................................

Data Warehouse ..............................................................................................................................

ETL / E-LT (Extract, Load, Transform) ..........................................................................................

OBIA/OBIEE Presentation Layer Customizations ............................................................................

What is a Report? .................................................................................................................................

OBIA Customizations for DW & ETL(E-LT) ........................................................................................

OBIA/OBIEE System Customizations vs. Configurations ...............................................................

Conclusion ..............................................................................................................................................

Biography ...............................................................................................................................................

About Datavail's Implementation and Support Analytics...............................................................

About Datavail .......................................................................................................................................

1

1

1

2

2

2

3

4

4

5

6

7

7

7

8

8

8

content

What is an Oracle BI Applications Customization?

Aligning OBIA to the system of record’s customizations occurs after the OBIA system has been installed and some basic configurations have been made. The most visible result of tailoring OBIA in this way can be seen in the content of dashboards and reports displayed to the end-users of the solution which allows for the rendering of their ERP/CRM data as analytical information and insights. The official term to be used in order to denote modifying the standard OOTB OBIA should be “Extension” instead of “Customization.” This avoids any confusion in the writing of statements of work and communications on the topics discussed in this document. However, we’ll continue to use the term customization in this document for lay terminology.

Customizations can be made at several different levels within the OBIA application. It is important during the implementation of the solution to understand the upstream and downstream impact that business reporting requirements for the solution will have on the integration and/or custom development of the out-of-the-box solution. This whitepaper seeks to help clarify what types of customizations are typical of the OBIA solution. Whether using a Peoplesoft, E-Business Suite, JD Edwards, or Siebel solution or a custom data blend integration with Lawson, Salesforce, or other third-party data, this document aims to enlighten you about your next implementation of OBIA.

Customization Levels

Because the Oracle BI Applications system is an end-to-end analytics solution comprised of a structured Data Warehouse, a data transformation integration (ETL also referred to as E-LT) system with data mappings, a metadata repository (RPD) with business rules, and analytics (Dashboards and Reports) content, the solution can be “customized” at each of these four levels. These levels will be described in this whitepaper along with example use cases of a customization that occurred within those levels. Keep in mind that there is typically a level of intensity and time required to achieve a requested integration or customization of the OBIA system. This is usually defined as the level of effort (LOE) it takes the implementer to make the modification. Since the presentation layer of the OBIA/OBIEE portal, which included dashboards and reports, is the first and often only aspect of the program encountered by users, this layer is usually the first to be considered for any customization. Depending on the type of customization, a change to this layer may impact the layer upstream from it, the metadata layer for example, and continue back up stream potentially effecting change at the data warehouse or even the source system in the most extreme cases.

Tweak vs. CustomizationDuring an OBIA implementation effort there is often a question regarding what constitutes a customization or a minor adjustment (“tweak”) to the out-of-the-box content. The use of the term “tweak” in OBIA can be misleading because a tweak is often on the other end of the effort spectrum when compared to a customization. Please read this section for clarity.

During the initial configuration effort, the first customizations happen when the initial full loads of data from the source system to the OBIA data warehouse are attempted. There are several pure configuration steps involved here that allow the OBIA system to understand the uniqueness of a customer's system of record configurations which it uses to run its daily business operations. Once data is surfaced and showing relatively consistently in the out-of-the-box dashboard content (that is dashboards showing data), the implementers may then make modifications to settings, options, and prompt values in a non-invasive manner to identify initial gaps in the OBIA system. These gaps help identify how tight or loose OBIA out-of-the-box fits in alignment to the customer’s business.

Page 1 Oracle BI Applications: Understanding Levels of Customization | © 2016 Datavail, Inc. All rights reserved.

The out-of-the-box reports and dashboards are already well defined. If a report or dashboard is perceived to require “light” development effort in order for it to align with a business reporting requirement for it to be useful, or for unit testing, data validation, or prototyping, some may try to define this as tweak. A simple way for defining a tweak is to determine if the required effort to modify a report’s (or object’s) end-state takes less than the effort to create that same object or report from scratch. Often, this effort is not superficial and can take time to clearly define the potential work effort timeframe. Often what appears to be a minor tweak may in fact lead to an investigation into one of the upstream layers which may need to be customized also. If not a tweak, then it is a customization (or tailoring) effort which is more involved.

Even with the simple calculation above, tweaks may become customizations based on the quantification of items requested in the requirement. For example, hiding two columns on a table view shown on one dashboard page maybe a tweak, but repeat that same operation for five times, it most likely becomes a customization effort. Or, for something initially thought to be a tweak, there may be a more scalable solution to satisfy the requirement, such as modifying the upstream metadata layer. It may take longer to develop but will end with a better global system result, making it a true customization.

These upstream layer tweaks are often only identified at the time of the gap analysis and/or when the requests for reporting requirements are provided by the business or project’s executive sponsors. This is why it is essential for the implementer to conduct detailed requirements sessions. It allows the project team to understand the requests for reporting as well as to understand the business and how the data from the ERP/CRM system is being used, or is desired to be used through OBIA, in order to turn data into insights. As the requirements are captured, the implementer may then prototype reports and investigate any gaps - that is, what information is available to meet the requirements and what information is missing. When missing or incomplete items are found, they should be defined as a gap and will need to be met with an upstream customization to fit the gap which is often a higher level of work effort than a tweak.

Testing is Paramount to Successful ModificationNo matter how simple or difficult a modification to OBIA seems, as with any software technology, testing the modification, and its accuracy, through some testing standardization for the project or solution has to take place. Don’t forget to include unit tests and any resulting user acceptance testing as part of your total level of effort for making a modification. This re-validation ensures that the modification, whether a tweak or a customization, is made to specification.

Customization Across the Different OBIA Layers

Presentation Layer

The presentation layer is the Oracle BI portal where users login to access dashboard and report content. It is the most visible of the customization layers as it is seen and understood by the project’s executive sponsors, end-users, and other stakeholders rather than just developers.

This user interface (UI) is based on many components, but for simplicity, it is a dashboard portal. Out of the box, the OBIA content delivered is quite complex for the amount of reports, dashboards, metrics, and pre-built content it comes with, but it is usually very light regarding how the organization would need to use it in order to run its business. This is because the OBIA system is mainly generic. If the underlying ERP (ex: PeopleSoft) or CRM systems were never customized to a particular organization’s way of doing business, the out-of-the-box OBIA integration would work nearly perfectly.

Oracle BI Applications: Understanding Levels of Customization Page 2

TWEAK = (time to create new object / time to modify object for requirements) > 1

(If the result of the above equation evaluates to true, and the level of effort to create the new object is less than a quarter of a work day, then it can be classified as a tweak and not a customization. Tweaks are rare but can happen when a customer's ERP/CRM system has very minor customizations and/or

their ERP/CRM system of record is relatively pedestrian.)


However, after prerequisite configurations, there are often many end-user requests to align the OBIA tool to the ERP/CRM system in order to render it useable. This is a standard best practice part of the implementation. Since the ERP/CRM system has been customized, so must the OBIA system in order to align to the reporting elements required by the business. Key customization areas for the presentation layer include:

• Security

o Object Security

o Data Security

• Dashboards

• Dashboard Pages

• Dashboard Prompts

• Hierarchies

• Email Bursting of Reports

• Subject Areas

o Metrics

o Dimensions

o Attributes

Plausible examples of a presentation layer customization are:

• Removing two dimension folders from a subject area

• Modifying an out-of-box report to be combined in an existing dashboard adding a new graph with a view selector

• Creating a new hierarchy or lineage (dimensional hierarchy) for the org chart

• Adding a prompt column to an out-of-the box dashboard prompt

Plausible examples of a presentation layer tweak are:

• Adding one new column prompt drop down to an existing OOTB dashboard prompt

• Renaming a presentation layer subject area column

• Removing two views or reports from a dashboard page

• Setting a dashboard prompt’s default value to a static value (or existing variable)

MetaData Repository

Most of the metadata repository (RPD) customizations are made because of requirements or requests for changes to the presentation layer (i.e.: the Oracle BI portal). Again, this is because the portal is normally all the end-users will be able to access within the OBIA system.

The metadata repository is where the OBIA system connects to the underlying analytics Data Warehouse (DW) system and translates the physical data source into business logic, then ultimately into subject areas which are used to build analysis reports and other presentation layer objects. The DW is populated by the ETL/E-LT system, usually in a nightly batch load. It would be nearly atypical for a business user to request a direct change to the metadata layer since this layer is transparent to them. As mentioned, a change to this layer would usually be a direct result of a request to the presentation layer and would require the OBIA developers’ technical interpretation of the requirement, gap analysis research, and source system to determine the if, when, and how to satisfy the request. Be prepared to update the Standard OOTB OBIA Model during your project.

Almost all of the work conducted at this layer is a customization. Key customization areas for the metadata repository (RPD) layer include:

• Data Source Connections

• Data/Row Level Security

• Variable

o Refreshing Variables at increments

• Global Settings

• Session Information

• Calculations

• Federation of Data

• Data Joins

• Dimension Joins

• Hierarchies

• Subject Areas


Plausible examples of a metadata layer customization are: • Adding a new hierarchy lineage for an org chart dimension drill-down

• Updating general ledger segment codes with descriptions such as combining the account name description with account number

• Creating a new subject area, perhaps based on an OOTB subject area, removing or adding several columns and/or folders/tables

Plausible examples of a metadata layer tweak are:

• Changing one column name for a subject area

• Hiding one subject area from view

• Modifying a simple out-of-the-box business model column's calculation formula

Data Warehouse

A fundamental reason for using the OBIA system is that a robust well-defined star-schema data warehouse is delivered as part of the solution. There are serious cost benefits to acquiring such a scalable system versus building one in-house. The data warehouse is extensible which means it can be configured rather than rebuilt in order to add on customizations such as support for extra data fields (ex: FlexFields, GL segments, etc). When other data source logic needs to be joined to existing tables, there are best practices for ensuring that customizations made to the DW will still be supported with any OBIA system upgrades or patches that may happen over time.

Typical customization areas for the Data Warehouse layer include modifying any of the following:

• Table

• Procedure

• Index

• Statistics

• Columns

• Partitioning

• Performance

Plausible examples of a Data Warehouse layer customization are:

• Adding a new column to a data warehouse table to bring in an extra flex field

• Tuning performance of data loads regarding indexing, partitioning, or statistics

Plausible examples of a Data Warehouse layer tweak are:

• N/A (Each modification of this layer is a customization)

ETL/E-LT (Extract, Load, Transform)

Another core reason for using the OBIA solution is that a well-built set of logical data integration mappings, that move data from the source system to the target Data Warehouse using staging table coordination and other best-practices, is delivered out of the box as part of the solution.

This layer of the OBIA system is developer centric and not visible to the business users of the OBIA portal. This layer is upstream to the metadata layer (RPD) and the Data Warehouse. When gaps are identified in the presentation layer that also reveal gaps in the metadata layer, and when that gap is also present in the DW layer, a change to the ETL is almost almost inevitable.


• Data Mappings/Interfaces

o Source to Target Modifications

• Cleansing and Conforming data

• Database Source/Target Connections

• DW Additions and Alignments

o Tables

o Columns

o Indexing

o Tablespace specifications

Plausable examples of a ETL/E-LT layer customization are:

• Adding a new column or table to the data warehouse in order to bring over additional content from the ERP/CRM system of record

• Importing additional data source (ex: third-party data) content to the data warehouse

Plausible examples of a ETL/E-LT layer tweak are:

• N/A (Each modification of this layer is a customization)

OBIA/OBIEE Presentation Layer Customizations

The Oracle BI Applications system provides moderate to complex out of the box dashboards and reports based on well-defined subject areas in order to showcase what universal information may be requested from an Oracle customer’s end-users or management team. As described above, there are several key areas of customization where an Oracle customer may tailor their OBIA module to their organization’s way of doing business. The diagram below illustrates how complexity for a level of effort, per a required customization, increases naturally depending on where a particular customizable area of OBIA the requirement will reside.

The Oracle BI Applications system provides moderate to complex out of the box dashboards and reports based on well-defined subject areas in order to showcase what universal information may be requested from an Oracle customer’s end-users or management team. As described above, there are several key areas of customization where an Oracle customer may tailor their OBIA module to their organization’s way of doing business. The diagram below illustrates how complexity for a level of effort, per a required customization, increases naturally depending on where a particular customizable area of OBIA the requirement will reside.

Typical customization areas for the ETL/E-LT layer include:

A generic scale for presentation layer-based efforts regarding customizations that may derive from a business user reporting requirement or request can assist in aligning expectations. The complexity of the custom development of OBIEE analysis reports and OBIEE interactive dashboards can be defined according to this scale:

a. Very Easy -

• Report with single query with no formulae / expressions, and no parameters

b. Easy -

• Report with simple query with 1-2 tables joined, Up to three (3) formulae / expressions

c. Moderate -

• Report with queries up to 3-5 tables joined, up to five (5) input parameters, Up to six (6) formulae / expressions

• Adding/Modifying dashboard prompt with any non-default attributes, variables, or SQL

d. Complex -

• Report with queries up to 5-7 tables joined, having group sorting, calculations, conditions, summaries, and parameters, up to ten (10) formulae / expressions, includes graphics chart

e. Very Complex -

• Report with data from queries more than seven (7) tables joined, having complex group sorting, calculations, conditions, summaries, parameters, up to five (5) input parameters, More than ten (10) formulae

What is a Report?

In OBIEE, as with most reporting and dashboard systems, a report (aka analysis request) is defined as one single query operation to the underlying data source. A report is typically one single view, that is, a representation, of the data returned by that one single query operation. OBIEE allows the report developer to provide different views against the same single query operation to display the data graphically with visualizations. The report developer can also display the data in a tabular fashion and it still constitutes a single report since it is based on the same single query operation. Whether building a custom report or modifying an out-of-the-box OBIA report, the concept is the same. Some newer Oracle customers confuse this basic concept. Any type of interaction with a single report where one navigates from the summary level of data to the detail level of data will typically require multiple reports. This is particularly true when additional data columns or attribute columns for a report are required as this typically necessitates an additional query operation, thus making the case for an additional report to be developed. For example, if the requirement is to provide a main procurement report showing Fiscal Year, Department, Contract Number, Vendor, Actuals and Budget dollars on one report this would potentially be a single query operation, thus one report. If the additional requirement calls for adding Purchase Order Number, Requisition Number, and Remaining Budget this information may best be shown on a different screen by having the user click on the Contract Number on the main report which opens this “drill-through” detail report. In this example, the final result is two separate reports not only because they are most likely two different queries based on the OBIA subject area standard out-of-the-box model, but also because the columns are different and it creates a better flow going from summary level to detail level to investigate the information. Some customers may desire to have all of those columns and attributes listed in a single report. This is not a best practice and may add additional effort because such a single report may not be able to be joined together directly out-of-the-box due to the subject areas from the standard OBIA model design which separates some of the logic based on basic analysis. Therefore, to modify the standard OBIA model, this would require a customization either in the RPD or in the ETL. This is not a best practice because in analytics one should seek to manage by exception and have the ability to glance at high-level data then drill to the details without having a cluttered dashboard showing very wide tabular outputs. There can be compromise and education on how to navigate the flow of the data with the goal of providing access to the information. If the information can be found in one click, the users should understand the risk, weigh the pros and cons of having the information needed right away with one click verses waiting for the customization development to complete, and be aware of the development costs that might be necessary in order to get the single report. Do not confuse the term “custom” report for the term “customization” in OBIA as the latter relates to extending the OBIA system which typically involves modifying or deviating from the standard OBIA out-of-the-box model and requires a higher level of design and development effort.


OBIA Customizations for DW & ETL(E-LT)

The standard modification of the Data Warehouse or the E-LT portion of the OBIA system follows a categorization of modifications to help understand the severity of a customization. The image in the matrix below assists in identifying the core use case area for a modification and the level of the categorization helps to determine, to some degree, the intensity of the effort.

The table above represents customization of the DW and E-LT layers considering a number of scenarios. Category 1 relates to a customization where additional columns from the source ERP/CRM system(s) need to be added to the existing DW tables. Category 2 relates to a customization where the DW requires new fact or dimension tables and will generally require creating new E-LT mappings. Category 3 is typically an advanced integration customization for loading data from sources that do not have OOTB adapters for loading data through the standard data integration process into the DW. An example of a category 3 customization would be loading multiple budget and forecast spreadsheets into theDW to allow for surfacing forecast data with actuals data, or integrating data from SalesForce.com or Taleo.

OBIA/OBIEE System Customizations vs. ConfigurationsBecause OBIA is a packaged solution system, it is comprised of several different tools such as WebLogic, Oracle Data Integrator, and Oracle Business Intelligence Enterprise Edition (OBIEE). Configurations, which are more about adjusting the technical attributes of the system itself, happen throughout the lifecycle of the OBIA system and it is important for the implementation team to be knowledgeable about each of these component areas. The misconception between configuration and customization is one of scale; OBIA must be first configured before it can be customized. Examples for OBIA system components configurations range from configuring application servers for high-availability or general performance tuning to integrating LDAP, SSO, SSL, or Mobile BI. Although most configurations are technical in nature, they are paramount for driving solid performance and the tightest integration with the Oracle customer’s existing infrastructure and other systems, including desired requirements such as launching to or embedding OBIEE reports within the Peoplesoft or EBS portal.

ConclusionAn OBIA implementation project requires the synergy of technical and business resources working towards the common goal of providing an enterprise platform for analytics and “one-source-of-the-truth” data warehousing. Attempting to understand how the robust OBIA system will align with the current system of record(s) is not an arduous task, but should be augmented with experts who have successfully implemented the OBIA solution in the past. Each organization is different to some degree, regardless of what sector or vertical industry it is in. The initial technical implementation of OBIA is fairly consistent across all organizations but it lays the critical foundation which DBAs and Network Administrators will ultimately support. Having the ability to understand what data is required from the system of record(s) to be placed on a dashboard portal for analytical “at your fingertips” management reporting will require some levels of customization and a few tweaks in order to see the real value from the OBIA system. Seeing that value, quickly, and with a clear plan for customizing or tailoring the solution to fit any gaps between the OOTB solution and what the organization needs in order to run its business more efficiently, is a process that must be aligned uniquely with each Oracle customer.



Biography

Christian ScreenVice President and Practice Director – Oracle Analytics

Christian is an innovator in analytics and data warehousing design, best practices, and delivery. With more than fifteen years of decision support and data warehousing with key experiences at Office Depot HQ, Sierra-Cedar, and Capgemini, he oversees the Oracle Analytics Practice which includes the technical development and delivery of Oracle BI collaboration software, data warehouse solutions, Oracle BI/EPM projects, and packaged analytics solutions at Datavail.

Christian’s professional accomplishments include co-founding BI consulting company Art of BI, co-authoring the first book on Oracle Business Intelligence 11g, Oracle Business Intelligence

Enterprise Edition 11g: A Hands-On Tutorial, and successfully delivering numerous complex implementations of Oracle BI, Oracle BI Analytics Applications (OBIA), Hyperion Planning, and Hyperion Essbase to clients across the world. He is an Oracle ACE, an international speaker, writer, and contributor on analytics centric topics at conference such as Oracle Open World, Collaborate, KScope, and Oracle User Groups where he shares his perspectives and thoughts on industry trends, strategies, and best practices.

About Datavail Datavail is the largest provider of data and database administration (DBA) services in North America with more than 600 DBAs, analysts, developers and consultants. We offer 24×7 managed services and project consulting in database administration, BI/Analytics, data warehousing, and enterprise performance management. Datavail’s expert consulting team specializes in integrations, implementations, and upgrades for applications across the Oracle stack, including Hyperion, OBIEE, OBIA, GoldenGate, Weblogic and more. Founded in 2007, Datavail is based in Broomfield, Colo.

Contact Us

General Inquiries: 877-722-8247Fax Number: 303-469-2399Email: [email protected]

Corporate Headquarters:Datavail Corporation11800 Ridge ParkwaySuite 125Broomfield, CO 80021

Powai Office:Datavail Infotech Pvt. LtdA-902, Supreme Business Park,Hiranandani Gardens, PowaiMumbai – 400076Maharashtra

Bangalore Office:Datavail Infotech Pvt. LtdConcept Business Park#319/9, 1st floor, Block AHosur Main Road Bommanahalli, Bangalore 560100

About Datavail’s Implementation and Support AnalyticsWith a strong focus on understanding the business of our customers, and rapid iterative development of the Oracle BI Applications system, we believe in delivering value quickly to the end-users. Unlike large faceless consulting teams, our approach on everything from infrastructure (hardware recommendations, installation, configuration), requirements gathering, documentation, training and knowledge transfer, testing and delivery allows Oracle customers to benefit from a more efficient, less expensive model, that delivers more value and typically exceeds expectations. Contact us to find out more about how rethinking business intelligence and analytics with Datavail will be one of the best decisions you’ll make for meeting your Oracle Analytics implementation and support goals.

www.datavail.com | 877.634.9222

Documents

WHITE PAPER - eBulletins · This whitepaper seeks to help clarify what types of customizations are typical of the OBIA solution. Whether using a Peoplesoft, E-Business Suite, JD Edwards,