How to implement Business Objects: BI Architecture Design and Reporting Deployment

SBO Add-ons for ASAP 7

Jay Thoden van Velzen, SBO FS Global Operations July 9, 2010

Definition of Business Intelligence and BI Architecture

Business Intelligence Business Warehouse (BW/BI)

SAP Business Warehouse (BW) was at one point called BI

Somewhat confusing name, suggesting a database means you have BI

BW can certainly be part of a Business Intelligence landscape, but is rarely even the only data source, let alone the entire Business Intelligence platform

Business Intelligence is a IT/business concept or discipline, not a specific set of applications/tools, or database, to enable better business decisions and insight into corporate information

Business Intelligence Architecture

BI Architecture is the system sizing, system architecture and security implementation that make up a BI environment Business Intelligence Architecture comprises of:

SAP Business Objects Enterprise (specifically and historically) Business Intelligence Architecture across the SAP Business Objects product suite

SAP 2009 / Page 2

End User Business Value central to good BI

Multiple factors need to line up correctly to provide high business value.
Systems that present obstacles to end users receiving the information they need, reduce business value

Content delivery System Performance

Systems that do not provide answers in appropriate time frames, do not perform, or do not allow the user community to use the system when they need to, will discourage analysis and result in diminished business value

Systems that do not answer a particular business need or do not track the appropriate metrics and KPIs, do not provide business value

Answers business need End User Business Value Appropriate metrics and KPIs Data governance

Hardware sizing and capacity

Systems that provide information that cannot be trusted do more harm than good

All elements stand in service of the end user result

SAP 2009 / Page 3

Definition of the Reporting Strategy provides crucial input to technical implementation

BI Architecture can be designed and implemented without a holistic reporting strategy, however, the various elements are unlikely to be appropriately aligned, leading to either poor performance or poor reporting, or both, thereby dramatically limiting business value, and reducing return on investment. BI that doesnt provide the desired business value is a pointless exercise.

Business Goals and Objectives, End user information needs

Definition of Reporting Catalog, User rights and profiles, and Report Distribution Mechanisms

KPI and Metric Definition

Reporting Strategy Established

Report format choice, estimated user activity, and Sizing & Capacity Planning

System/IT Constraints

Performance optimization & tuning, data model improvements, indexing and aggregates, additional ETL

SAP 2009 / Page 4

SAP Business Objects BI Approach

Reporting has a business reason. Otherwise, it is a wasted effort. Whether it is a shortterm business initiative, or an ongoing series of operational reports, reporting is trying to answer business questions. Business problems tend to be multi-faceted with multiple component parts. Break the problem up in distinct parts that can be addressed individually.

Business Problem Identify component parts Analyze component parts Associate KPIs/metrics with components Enable tracking of KPIs/metrics Identify audience and delivery mechanism Technical landscape to support effort
SAP 2009 / Page 5

Analysis of the component parts makes the business problem manageable. Each part relates to each other, but also is dealt with individually.

The understanding of each component part should generate a number of measurable KPIs and metrics that accurately measure performance and outcomes. Ensure that you have the data to support the identified metrics. Sometimes it is directly captured, sometimes it is a derived metric. This is also how we identify missing data, or data we need to start collecting in order to support the business problem or initiative. Different audiences require different ways of consuming information. We need to identify the best way of delivering the information to the appropriate audience.

Now that we know what we need to deliver, we can design and implement the technical landscape to support the effort. The BI solution determines the landscape design.

Combine as many such use cases as possible to determine the technical landscape
Business Problem Business Problem Business Problem Business Problem

Identify component parts Analyze component parts

Identify component parts Analyze component parts

Identify component parts Analyze component parts

Identify component parts Analyze component parts

Associate KPIs/metrics with components

Enable tracking of KPIs/metrics Identify audience and delivery mechanism

Associate KPIs/metrics with components

Enable tracking of KPIs/metrics Identify audience and delivery mechanism

Associate KPIs/metrics with components

Enable tracking of KPIs/metrics Identify audience and delivery mechanism

Associate KPIs/metrics with components

Enable tracking of KPIs/metrics Identify audience and delivery mechanism

Technical landscape to support effort

SAP 2009 / Page 6

With a generic system landscape, how can we be sure we can support our use cases?
Business Problem Business Problem Business Problem Business Problem

Identify component parts Analyze component parts

Identify component parts Analyze component parts

Identify component parts Analyze component parts

Identify component parts Analyze component parts

Associate KPIs/metrics with components

Enable tracking of KPIs/metrics Identify audience and delivery mechanism

Associate KPIs/metrics with components

Enable tracking of KPIs/metrics Identify audience and delivery mechanism

Associate KPIs/metrics with components

Enable tracking of KPIs/metrics Identify audience and delivery mechanism

Associate KPIs/metrics with components

Enable tracking of KPIs/metrics Identify audience and delivery mechanism

?
SAP 2009 / Page 7

?
Generic Technical Landscape

BI Approach: Consider the flow of what determines what

Our only focal point. Nothing is more important than the end user. If we fail to address end user needs, the implementation fails. Our end user needs determine the definition of reports and dashboards. This determines also our technical landscape and data requirements. The delivery of our reports and dashboards determines the sizing and configuration of the SBO BOE architecture. A mismatch here will cripple the environment and impact user experience. Data structures, optimizations, aggregations, indexes should be based on data access needs of the reports, dashboards and universes, and sized to support end user needs.

End User

End User

Reports and Dashboards

Reports and Dashboards

SAP Business Objects Enterprise

SAP Business Objects Enterprise

BW (or other) data source

BW (or other) data source

Following a bottom-up approach leads to database back-ends that dont serve BI data access needs well, a BOE environment not configured to support our BI solutions, and reports and dashboards that are unlikely to serve end user needs.

SAP 2009 / Page 8

BI Approach: From detailed Use Case to Definition of BI Solution

Use Case

BI Solution

Type of user activity Function or role of the user in the organization Identified information need Understanding of entire business process Need for data manipulation Number of users that need this information Additional analysis to be performed Frequency this information is required In-office, branch-office, remote, mobile audience Technical sophistication of end user Need for guided navigation and story telling Current time to complete and any technical constraints in current process Security constraints Information delivery approach

Select appropriate report- and/or dashboard formats (note, will often be a combination) for different user types, different levels of sophistication and analysis needs Define report and dashboard specifications Define scheduling and distribution frequencies Define navigation paths, links between reports including sharing parameters, or detail ondemand Explore possible improvements in the business process and time to complete tasks Consider how additional analysis needs can be best accommodated Optimize back-end data structures to support reporting needs Implement content-, functional- and data access security Configure and size BOE environment to support BI solution

Nested BI Solutions/Strategies A Shared Services Model

Enterprise-wide Application framework

Shared Services Model Application/ Text project Text unique/ exceptional project

Enterprise-wide strategy, and definition of BI

Full system landscape

Application/ project

Application/ project

Small project

Small project

special project

SAP 2009 / Page 10

Business Intelligence Bridging Business & IT

Business (What is needed?)

Systems/IT (What is feasible?)

Business pains, goals and objectives Business requirements End user ease-of-use Ease of application/project on-boarding/GTM Adequate interactivity and response times Information needs Trustworthiness of data and reports Provides real business value

IT effort and available budgets Technical constraints Cost of IT implementation Efficient use of system resources System capacity Data availability Data Quality and Integrity Systems optimization and configuration

SAP 2009 / Page 11

SAP Business Objects Business Intelligence Interaction Model

Business Users

Power Users

Business Transformation

BI Team

Business Intelligence is the bridge between Business and IT Requirements are often misinterpreted, or pose new questions Lack of understanding of what is possible often leads to requirements that need to be refined or may be hard to fulfill when better options are likely to be available To understand the underlying business drivers behind business requirements, interviews and verifications are crucial to deliver true business value to the end user business community These interactions lead to more sophisticated, better performing and more valuable business intelligence solutions

IT

Project Initiation: Reporting Deployment

Discovery and Solution Design

Conversations held very early in the project to determine true business need for Business Intelligence On the basis of discussions and interactions, and a good understanding of use cases, audience, etc. we choose the appropriate report formats and BI tools and come up with a BI solution design so we know what we are going to develop Once we have established the business requirements and solution design, we can start developing technical requirements

SAP 2009 / Page 13

Dive deep into the actual Use Cases

One Use Case is one type of user, one type of usage, one department, one industry

Allow the business to describe the use case in detail Talk to the business as well as IT Business: business

Are we tracking the correct metrics? What is the level of sophistication of the users? What tools are currently in use? How is the information used and how does the user interact with it? What is it that were trying to achieve or support, and can we improve the process? Current product versions Database modeling issues, lacking aggregation Budgetary constraints Governance issues

IT: constraints, practical limits

Look at pre-existing reports Consider improvements to current business process Take the business unit, as well as industry into account How is the data structured? Do we need to make back-end changes to support the requirements?

Mapping The Right Tool to The Right Scenario

Supporting an Enterprise BI Strategy SAP BW context

Professionally Informed

Search & Exploration

OLAP Analysis

Ad-Hoc QRA

Dashboarding & Visualization

Enterprise Reporting

Executives & Managers

Dashboards & Visualization A new BI Paradigm SEARCH against your BI Explorer (use familiar (BusinessObjects Explorer) key-word) EXPLORATION against the results Reporting & Analysis General Web Interactive QaaWS with OLAP unv Xcelsius and / or Live Office Most business users

Operational or pixel Perfect reporting

Information Consumers

Intelligence reporting
OLAP Cube Navigation
(Voyager in non SAP BW Analysts context)

BEx Analyzer

Casual business user

Crystal IT users for report Report authoring / most business User for report consumption

Business Analysts

Technically Capable

Free

Interactive Experience

Guided

SAP 2009 / Page 15

Turn the Triangle to a Pyramid Add one (or more) dimension(s)

SAP 2009 / Page 16

Inputs on the Tool Selection and BI Solution

Use Case

For each Use Case consider....

Have a deep discussion on the Use Case and business requirements. In most cases the discussion doesnt go deep enough, so ensure you understand the planned business purpose, the processes it supports, and the expected outcome

Audience

Understand the type of audience the Use Case applies to. Dont blindly map to a Information Consumer, or Business Analyst, but understand what they really do Understand the particular business unit or department function, and how that influences the choice Understand how the Use Case is applied now. Is there an consistent existing process, and how does it work. Does it have holes or gaps? If any reports already exist, look at those, and how they are being used. It may clarify things otherwise poorly explained

Current Usage

Data/IT

Assess data requirements and how business requirements are supported by back-end Assess IT constraints that may need to influence your choice

SAP 2009 / Page 17

Project Initiation: BI Architecture

Discovery and Solution Design

Initial Hardware Sizing

Given that what youre going to do with the system determines sizing and system architecture, it is crucial to have these conversations very early in the project On the basis of discussions and interactions, and a good understanding of use cases, audience, etc. we come up with a BI solution design to inform our architecture design in Blueprint Once we have established the business requirements and solution design, we can start thinking of a deployment plan

Initial sizing for ballpark estimate and to ensure hardware is ordered sufficiently in advance. Of course, refinement is to be expected in Blueprint

SAP 2009 / Page 18

Business Blueprint: Reporting Solution Design

Report Design and Data

Knowing what our solution and how we will segment end user populations will look like allows us to analyze what data requirements we have Data mapping exercise and data source analysis will help identify data to feed reporting, but also missing data that we may need to start capturing Report specifications determine universe specification, which may result in data model changes Define scheduling and distribution requirements to best deliver the designed reports Design a workflow and story linking reports and dashboards together

SAP 2009 / Page 19

Self-service reporting vs. pre-built solution

Self-service BI often seen as the Gold Standard

Self-service BI seems at first glance the most ideal scenario

Users will themselves retrieve the information they need, when they need it Relieves IT of development work, so seems path to easy and fast implementation

Self-service/ad-hoc querying has its place, but when it is the only reporting option, it often leaves users swimming, rather than easily guided towards the information they truly need to support their business decisions

Unstructured self-service likely to lead to problems

Many users will develop very similar reports, run on unpredictable times and schedules, leading to higher hardware requirements, and higher demands on data bases, therefore costly, while not increasing business value Increases (often) time-to-information by having to develop or individually refresh easily anticipated reports that could be pre-built and run on a schedule Makes it difficult to create clear navigation paths through report linking for guided analysis, and leads to large collections of unverified reports where it is unclear business rules are implemented correctly Allow self-service to get levels of detail that is difficult to anticipate, and deeper analysis

SAP 2009 / Page 20

Likely Result of Unstructured Ad-hoc Navigation

SAP 2009 / Page 21

BI Solution with Guided Navigation

QTD Dashboard Detail QTD Revenue Report

Workflow and Guided Navigation

Total % Achievement Dashboard Detail QTD Revenue Report by Product Line Detail Total % Achievement Report

Top Seller % Achievement Dashboard Detail Top Seller % Achievement Report

Performance by Region and Product Line

Self-service Web intelligence Reports

SAP 2009 / Page 22

Help out end users by preparing most likely dashboard and reports in advance, with guided navigation into detail results Will reduce situation where many users create very similar ad-hoc reports Will save end users time by reducing the number of steps to get the information they need Uses same infrastructure, same OLAP Universe, no extra effort other than dashboard/report development Still provide ad-hoc access to universe for further analysis. The Query Panel can also be used to edit any of the pre-built Web Intelligence reports for easy expansion of querying

Business Blueprint: Sizing and Architecture Design

Sizing and Architecture Design

Knowing what our solution will look like allows us to analyze the number of users and type of activity to size for Properly estimate the number of users on at any point in time Assess batch scheduling requirements and capacity Design the various environments, and set up the necessary system administration processes Install and configure the Development environment in advance of any BI implementation work in Realization

SAP 2009 / Page 23

Estimate Peak/Least Usage

Users Distributed Around the Globe

Chart the number of (concurrent) users expected to make use of the system around the globe. This will inform us when we should expect peak usage during the day, which constitutes the maximum number of users on a 24-hour clock, and the number to size for (i.e. 790, instead of 1,415 in this example) Will also inform us what the relative quiet time is

SAP 2009 / Page 24

Finding peak usage and available batch window and capacity

Users Distributed Around the Globe

Our maximum number of users constitutes the top end of interactive user required capacity The red line indicates the lower end of concurrent users (in this example, mainly APJ users) The delta between the two is the existing available capacity for overnight batch processing, i.e. equivalent to ~400 concurrent users (or ~100 simultaneous batch jobs), over a 7-8 hr time window Should help inform choosing database load windows as well

SAP 2009 / Page 25

Design your architecture and service distribution

The Classic example: Primarily the SAP Business Objects Enterprise system (most complex BI server architecture in the suite)
BOE XI 3.1 BOE XI 3.1

BOE XI 3.1

BOE XI 3.1

BOE XI 3.1

BOE XI 3.1

SAP 2009 / Page 26

Design a larger BI system landscape including EPM applications

Client Tier
SOAP

HTTP

Web Clients

Windows Clients

HTTP/ SOAP

HTTP

NL B

HTTP

NL B

CORBA

InterCompany Financial Info Mgmt

XMLA/ HTTP/ SOAP Tomcat/ BOE Application Tier CORBA CORBA HTTP/ SOAP FC/ IC/ Web Servers CORBA DCOM

Financial Consolidation Extended Analytics Business Intelligence

The 2010+ example: BI system landscapes including various products from the SBO product suite across service lines: in this case, including EPM and IM applications

Web Application Tier

SOAP/ HTTP CORBA CORBA BOE Intelligence SOAP

NL B
Tomcat/FIM/ DS App Server

DCOM

ctBroker

MSCS
EA Tools/ SSAS 2005 EE (CUBES) BOE Procesing ADO .NET SOAP/ HTTP DS App Server FC App Servers FC Scheduler

MSCS

JDBC Netbios

Netbios

Data Tier
Netbios XMLA/ TCP ODBC SQL/TCP

Native SQL Connector MS SQL Server OLEDB

Netbios

SFTP to Non-prod Environments

MSCS
File Server

SSAS Cube

BOE

FIM

BFC

BI systems are getting more complex, and larger BI landscapes integrating multiple SBO tools and applications will get more and more common. Because of the complexity involved, you may need to provide various different types of diagrams to show the architecture and configuration design, as well as data flows, and how various products integrate together.

SAN Storage

SAP 2009 / Page 27

Business Blueprint: Security and Authorizations

Security and Authorizations

Perform appropriate User Segmentation. Different users will require different types of reporting, as well as, access rights, functional rights, etc. Define what each functional user profile is authorized to do Understand all authorization requirements for all user segments Especially consider end user scheduling and self-service capabilities, and supplement with a governance model to establish ground rules that match business needs, but dont put extraordinary stress on the BI system

SAP 2009 / Page 28

Business Blueprint: Security Design

Security Model Design

Perform appropriate User Segmentation. Different users will require different access rights, functional rights, etc. Define what each functional user profile is authorized to do Consider SSO requirements Understand all authorization requirements Design a folder structure to hold and categorize BI content like reports, dashboards, etc. Design the security model, using principles of inheritance to ensure maintainability of the security model long-term

SAP 2009 / Page 29

Security Rights inheritance in BOE 3.1

Best Practices

Use inheritance to allow for long term ease of maintenance Only use Denied if you know nobody in the organization should be allowed to exercise the privilege Lock, then grant-as-needed is preferred: Start with most restricted profiles, and set to Not Specified Grant to users as needed

SAP 2009 / Page 30

Inheritance for ease of maintenance

Example: Power Users as a subgroup of Casual Users

Casual Users have few rights and privileges Most rights Not Specified so default to Denied Baseline profile we can now extend

Rather than build unrelated new group, Power Users inherit the Casual Users profile, then grant additional rights and privileges Large modification only required in few places

SAP 2009 / Page 31

Security Model Design

Map User Groups/Profiles to Folder Structure

Combine Profile definitions with Content groups for combined content/profile groups inheriting from both Map content/profile groups to content folders in the system and assign rights Average design time for an Enterprise Security Model, including Shared Services: ~4 weeks

SAP 2009 / Page 32

Security Design Best Practices

Avoid Maintenance Nightmares Long-Term

Always develop the Enterprise Security Model in the BOE system:

The Enterprise Security Model belongs to the BI system, not the data source The main concern of the Enterprise Security Model is available functionality in the system, as well as access to reports, dashboards, universes and other uploaded documents Data security is built-in using SAP roles from the SAP NW BW system The use of presets can aid in definition of your functionality profiles, but are not guaranteed to meet your needs or requirements Go right-by-right and consider whether to grant the capability or not

Define functionality profiles yourself, appropriate to the needs of the organization

Once functionality profile groups have been set up, create content groups matching folder access to content

Create combined groups (i.e. Sales Power Users, Finance Report Developers, etc.) by inheriting from both a functionality profile group and one or more content groups Once implemented, map SAP roles (and other identity management systems like LDAP directories) to BOE child groups Design for the bulk of users, deal with exceptions (which should be rare) separately

Stick to your design! Indiscipline can break your security model

SAP 2009 / Page 33

Security Model Maintenance Example

Casual User

Finance

Manufacturing

Allow PDF Download

Finance Casual User

Manufacturing Casual User

Sales Casual User

Power User

Finance Power User Manufacturing Power User Sales Power User

Assume initially we didnt allow PDF download, but have now received a request to allow PDF downloads for all users in the organization for documents users have access to If user rights were set on unique groups, even in this example we would need to change it in 4 locations (Finance & Manufacturing Casual Users and Power Users), but most likely more If user rights were set on profile groups without inheritance we would need to change it in 2 locations (Casual Users and Power User groups) In our design following best practices, we only need to modify Casual User to allow PDF download, and inheritance ensures now all users are assigned the PDF download functionality automatically

SAP 2009 / Page 34

Realization: Execute on Design

Implement Solution

Implement any changes to the data model you may need to make to support reporting requirements Develop any universes as per design Promote content to QA for testing Promote content to UAT for user acceptance testing Get approval for the developed work (or make the necessary changes) Promote reporting solution to Production for final checks

SAP 2009 / Page 35

Realization: Execute on Design

Implement Systems

Install and configure QA and UAT according to design Install and configure Production environment according to design Install and configure DR/Fail-over environment according to design Implement full user security model in UAT according to design, and after testing promote to Production Test system, and especially performance and load testing highly recommended

SAP 2009 / Page 36

17-19 SBO Business Add-Ons Planned (GRC already covered through conversion)
BI
BICC/BI Strategy* BI Architecture Design Competitive Upgrade Dashboard Analytics Deployment Explorer Metrics/KPI Identification Service Reporting Deployment SAP Business Objects Upgrade System/Solution Healthcheck Testing/Platform Performance Testing** BW Deployment?

EPM
BPC Implementation Financial Consolidation Impl. PCM Implementation Strategy Management Impl.

IM
Data Integration Data Quality Legacy Data Migration for SAP Apps Rapid Marts Deployment Data Warehouse/ Data Mart Deployment?

Template Projects Development (Solution Manager)

* With BTS ** With SAP Global Testing Services

Q&A

SAP 2009 / Page 38

Thank you!

SAP 2009 / Page 39