Design Options for SAP BW Implementations

SAP COMMUNITY NETWORK SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com | UAC - uac.sap.com

2010 SAP AG 1

Design Options for SAP BW

Implementations

Applies to:

System Architecture for SAP BW implementations for multiple scenarios. SAP Net Weaver 2004s BI 7.0. For more information, visit the Business Intelligence homepage.

Summary

This Whitepaper summarizes various design options for a template EDWH implementation in SAP BW for various client based scenarios. Main Purpose of this document is to give Architects\Solution Designers various options upfront in order to evaluate specific client needs.

Author: Ajay Gupta

Company: Infosys technologies Ltd

Created on: 03rd

May 2010

Author Bio

Ajay Gupta has over 7 years of consulting experience in SAP projects. Ajay is presently working with Infosys Technologies Ltd. He is working on SAP BI 7.0 and is mainly responsible for execution of SAP BW/BI projects.

Design Options for SAP BW Implementations


2010 SAP AG 2

Table of Contents

Introduction ................................................................................................................................................... 3

Business Scenario ........................................................................................................................................ 3

Scenario 1 ................................................................................................................................................. 3

.Scenario 2 ................................................................................................................................................ 3

Scenario 3 ................................................................................................................................................. 3

Scenario 4 ................................................................................................................................................. 3

Scenario 5 ................................................................................................................................................. 3

Base Template Design .................................................................................................................................. 4

Architecture Scenario 1 ................................................................................................................................. 6

Solution Statement: ................................................................................................................................... 6


Solution Statement: ................................................................................................................................... 8


Architecture Scenario 4 ............................................................................................................................... 10

Solution Statement: ................................................................................................................................. 10 Example: .................................................................................................................................................................... 10

Architecture Scenario 5 ............................................................................................................................... 12

Solution statement: .................................................................................................................................. 12 Advantages: ............................................................................................................................................................... 12

Drawbacks ................................................................................................................................................................. 12

Guiding Principles to achieve optimized system usage:............................................................................................. 13

Related Content .......................................................................................................................................... 14

Disclaimer and Liability Notice ..................................................................................................................... 15



2010 SAP AG 3

Introduction

During the course of implementation and maintenance projects I have felt a pressing need from various clients for different design options\templates and relative costing for the same, which can be used to meet there global or local requirements and can be used for putting rough estimates for budgeting purpose.

In todays competitive market, technology\Consulting companies are working towards standardization not only in implementation processes but also devising standard technical design templates which can be used and reused across board to gain efficiencies. Though this will in no way reduce the requirement of a solution architect but it will help in gaining synergies across cost and standardizations.

In this article I will be discussing the design options\templates based on the scenarios and in my next articles will be covering details of these scenarios and cost aspect of the same.

Business Scenario

Below are the common scenarios which are often quoted by Clients for meeting their Vision and henceforth road to achieve the same.

Scenario 1

Client Query: I am a global company and would like to have a design template which can be used across global cutting across various countries and timelines but still able to achieve common reporting?

.Scenario 2

Client Query: How can I achieve regional reporting for my organization for a functional area which has its presence in a single country and time zone?

Scenario 3

Client Query: How can I Partition my data based on the Calendar year \ Fiscal Year as I have various cases in sales with huge yearly volumes?

Scenario 4

Client Query: How can I standardize my archiving strategy so that it becomes standard for all my current

and future implementations?

Scenario 5

Client Query: How can I optimize my data loading from my OLTP systems (for a single time zone)?



2010 SAP AG 4

Base Template Design

We will be covering all above scenarios one by one in below sections.

(Fig 1.0)

The above figure (fig 1.0) represents the EDWH template which we will use as a base and then will tweak the design based on the scenarios described above.

As the saying goes

We simply do not understand our place in the universe and have not the courage to admit it

Same is true with todays organizations from Management Information perspective where they have Global reporting ambitions in mind along with regional aspirations but are unaware of how they are currently placed.

Consulting and Architectural inputs plays important role in giving ability to baseline requirements on Global and Regional KPIs keeping Base Template in mind. This can be executed TOP Down or Bottom UP based on the Executive Drive or Company Vision.

All that we are is the result of what we have thought.

From architecture point of view the AIM is to meet consolidation and Regional aspirations but with least complex architecture from implementation and support perspective. The Key to achieve this is to partition the overall architecture and break down into discrete elements. Partitioning of architecture can be achieved by having several layers where each layer has its own optimized sub-sections for the administration of data in discrete and manageable chunks. This ensures less cross layer interactions and less interdependencies, which finally reduce the overall complexity.



2010 SAP AG 5

In the above Figure different layers has been depicted, namely:

Source System layer

Staging \ Landing Zone

Transformation layer

Data-Mart Layer

Integrated Reporting layer

Note: Names of the layer may differ based on the requirements but baseline concept remains the same.

We will not discuss details of concept behind each layer of EDWH architecture as these have in covered in most of the SDN whitepapers. Lets discuss in detail each scenario and the proposed solution around the same.



2010 SAP AG 6

Architecture Scenario 1

Client Query: I am a global company and would like to have a design template which can be used across

global cutting across various countries and timelines but still able to achieve common reporting.

Solution Statement:

(Fig 1.1)

The above architecture template (Fig 1.1) gives a broader perspective for global implementations keeping in mind the local reporting needs as well. The proposed architecture not only meets the local operational reporting needs but also suffice global strategic reporting as data available in each layer in at different granular level.



2010 SAP AG 7

The benefits include:

Staging\landing zone to replicate\Mirror the source data which is maintained in a write Optimized

DSO.

Corporate Memory to maintain history information in a write optimized DSO to help recovery in

case of any eventuality

Transformation layer to achieve specific business logic ad data cleansing.

Data mart Layer to support functional or\and regional requirements as the data is segregated

based on these principles as per the client requirements.

Integrated reporting layer to support Executive Information at global level or\and to support cross

functional reporting.

This model also suggest vertical and horizontal partitioning which ensure less interdependencies and duplications and helps in optimized architecture for better administration and support. Also the normal approach of project specific architecture within organization is discouraged.



2010 SAP AG 8


Client Query: How can I achieve regional reporting for my organization for a functional area which has its

presence in a single country and time zone?

Solution Statement:

(Fig 1.2)

The above architecture template (Fig 1.2) gives a broader perspective for Regional reporting implementations. The proposed architecture suggests data marts to be partitioned based on regions. Regional reporting should based out of individual data marts and the corporate reporting based out of combination of data marts.

Three years + of data is assumed to be available for reporting at summarized level and the How archiving cycle works is discussed in scenario 4.



2010 SAP AG 9


Client Query: How can I Partition my data based on the calendar year \ Fiscal Year as I have various cases

in sales with huge yearly volumes?

(Fig 1.3)

The above architecture template (Fig 1.3) gives a broader perspective for partitioning data for huge data volume reporting implementations. The proposed architecture suggests data marts to be partitioned based on year(fiscal year or calendar year). Year on Year comparisons and like for like reporting scenarios can be achieved based on this architecture template. To take care of huge volumes the 3+ year data is kept at a summarized level based on the reporting requirements and then should be archived accordingly. How archiving cycle works is discussed in scenario 4.



2010 SAP AG 10


Client Query: How can I standardize my archiving strategy so that it becomes standard for all my current

and future implementations?

Solution Statement:

(Fig 1.4)

Archiving strategy plays a critical role in BW implementations as it decides not only the cost side of project implementations but also on the overall all system effectiveness and performance.

The above simple archiving strategy on yearly partitioned cubes suggests to keep the data for 3 years (Frequently accessed) in the reporting cubes and then archive the 3 + year data into the historical cubes based on the granularity on which data is required for reporting for those years.

Example:

Lets assume the project goes live in 2010, which will fill the CY cube. Below table depicts the way the data stored for subsequent years. Instead of moving data b\w CY, CY-1 & CY-2 years cubes descriptions will be renamed accordingly.

Also the process chains and transformations will be modeled according in design stage to accommodate this archiving model.



2010 SAP AG 11



2010 SAP AG 12


Client Query: How can I optimize my data loading from my OLTP systems (for a single time zone)?

Solution statement:

Normal BW system usage scenario:

Chart (1.1)

With data loads scheduled during day for certain business processes along with better H\W and system resource configuration, BW system usage can be optimized for its usage.

Chart (1.2)

Advantages:

Helps remove spikes @ night load process usage

Flatten the overall load process

Failure recovery process is faster

Drawbacks

Consumes more resources during online business day which can be mitigated by better H\W and

system resource configuration

0

10

20

30

40

50

60

70

80

6:00 AM 10:00 AM

2:00 PM 6:00 PM 10:00 PM

2:00 AM 6:00 AM

Business User Usage

Laod Process Usage

0

10

20

30

40

50

60

70

6:00 AM 10:00 AM

2:00 PM 6:00 PM 10:00 PM

2:00 AM 6:00 AM

Business User Usage

Load process Usage



2010 SAP AG 13

Guiding Principles to achieve optimized system usage:

Scenarios || Objects Landing DSO \ DM DSO\ Corporate Memory

DM DSO Activation & Above DSOs\Cubes

Global Hourly Loads* Daily Loads

Near Real Time Hourly Loads* Hourly Loads

Single Country Specific Daily Loads Daily Loads

* The frequency of data load to Landing DSO can be decided on the volume of data and the reporting requirements.

Data Load architecture should be in place which will decide on the loads based on the specific scenario and clients needs.

The purpose of this document was to give readily available architectural scenarios at high which can be used during initial interaction and which can become guiding principle for detailed designs for consultants, solution designers and architects.

As the saying goes:

Every accomplishment starts with the decision to try.

I hope the above concepts will help you take a decision to try and try the best way.



2010 SAP AG 14

Related Content

http://help.sap.com/

xbi



2010 SAP AG 15

Disclaimer and Liability Notice

This document may discuss sample coding or other information that does not include SAP official interfaces and therefore is not

supported by SAP. Changes made based on this information are not supported and can be overwritten during an upgrade.

SAP will not be held liable for any damages caused by using or misusing the information, code or methods suggested in this document,

and anyone using these methods does so at his/her own risk.

SAP offers no guarantees and assumes no responsibility or liability of any type with respect to the content of this technical article or code sample, including any liability resulting from incompatibility between the content within this document and the materials and

services offered by SAP. You agree that you will not hold, or seek to hold, SAP responsible or liable with respect to the content of this

document.

Design Options for SAP BW Implementations

Documents

Transcript of Design Options for SAP BW Implementations