BW Layered Scalable Architecture (LSA) 07

SAP Skills 2009 Conference BW Layered Scalable Architecture (LSA) Die Referenzarchitektur zur Standardisierung von unternehmensweiten Business-WarehouseImplementierungen
Juergen Haupt, Architect, SAP NetWeaver RIG BI EMEA 02.07.2009
Agenda
1. BI Maturity and Data Logistics Motivation 2. BW Layered Scalable Architecture (LSA) The Reference Architecture for BW on Corporate/ Global scale
2.1. 2.2. 2.3. 2.4. LSA Building Blocks LSA Data Layers LSA Data Domains LSA & Master Data
3. LSA Implementation Unified Data Warehousing 4. BW LSA Assistent Building Blocks

1. 2. Storage - RDBMS & Columnar DMS Landscape: BW Centralization & Federation
5. Summary
SAP 2009 / SAP Skills 2009 Conference / B1 / Page 2
BI & Data Warehouse Market
The Market
Competitive View DW/BI
Source: Gartner 2008 SAP 2009 / SAP Skills 2009 Conference / B1 / Page 3
BI Value & Data Logistics
BI Maturity & Data Logistic Excellence
DW/BI Chasms
Bill Inmons Corporate Information Factory & Enterprise Data Warehouse (EDW)
Enterprise Data Warehouse (EDW): A single instantiation of a data warehouse layer for the entire corporation or big parts of the organization is often called the Enterprise Data Warehouse EDW-Keywords offer a single version of truth extract once & deploy many support the unknown re-build new-build controlled redundancy provide a corporate memory
Conceptual Details Integrated historical complete comprehensive application neutral granular corporate owned non-volatile
Copyright 1999 by William H. Inmon
The Chasm on the Way to the EDW Shore EDW + X : The Challenging X of Todays EDWs
Broader scope Cross corporate BI/ reporting Often local BI/ standard-reporting
EDW Principles
Mission/ business critical 99.6% availability from years perspective 8 am local time report availability Highly restrictive TCO & TCD expectations
Under complex conditions Often 24x7, global operations High volumes (data, meta data, user)
Highly volatile environment Continuous roll out Continuous BI projects
Todays EDWs can only deliver on promise if development, maintenance, operations and administration is highly standardized and automated and latest technology is leveraged:
EDW + X = BW + BW Layered Scalable Architecture (LSA)

BW Model-Driven Data WarehousingBW Means DWH Standardization & Automation

BW Model-driven DWH:
1. DWH data modeling Reference data model
InfoObjects + relations Subject-areas Building blocks
BW is from all perspectives fully model-driven

Architected Data Marts:
InfoCubes/ BWA
2.
DWH structure modeling

InfoProviders
DWH Stores:
DTPs, DSOs
3.
DWH operations modeling

Extract, load, transform Transfer, Error-handling Admin, Monitor
SAP-Source data model extractor extractor map models: provided by BW map models: user-defined
ETL/ Staging
PSA, InfoPackages Data Services
Non-SAP-Source data model
SAP Source A
Non-SAP Source B
Crossing the EDW Chasm: The BW Layered Scalable Architecture

SAP Customer Expectations on BW EDW:
Statoil Samsung Arla Foods Land Hessen s Edeka Henkel Kraft Foods trie us SA Philips Nike Japan Mc Kesson nd I P & De Tobacco Shell g Adidas v& ltin RI Downstream Syngenta su G on C BASF Nestl P SA Best Practices & EDW Principles Beiersdorf Novartis
LSA
BW Layered Scalable Architecture (LSA) The Reference Architecture for BW on a Corporate Scale
Agenda

5. Summary
Enterprise Data Warehouse (EDW) And The BW Layered Scalable Architecture (LSA)
The BW Layered Scalable Architecture (LSA) describes the design of service-level oriented, scalable, best practice BW architectures founded on accepted EDW principles*. The BW LSA serves as a reference architecture to design transparent, complete, comprehensive customer DWH architectures (Customer LSA). The Customer LSA describes corporate standards to build BI applications in a performant, maintainable, flexible manner.
* As introduced in Bill Inmons Corporate Information Factory (CIF)
Layered Scalable Architecture Standardized, Transparent, Efficient
Dataflow
Dataflow
Large scale BW Data Warehouses (EDWs) should follow architecture principles like we can observe constructing large buildings: standardized, scalable, no squiggles, efficient usage of materials, earth quake save.
non-architectured architectured
NonArchitectured LSA Architectured
DEPLOYING STANDARDIZATION NOT NICE, BUT TRANSPARENT WEBI ON SAP
out ll ab n is a atio LSA rdiz The anda St
BW LSA And Customer LSA
BW LSA: The Reference Architecture Step 1: Step 4:
Design
Customer LSA
Update
Customer LSA Customer LSA : Standards - Handbook
Step 2:
Apply
Customer LSA
Step 3:
Perfect
Customer LSA BI-Project-Design BI-Project-Design BI Project Design
Large Scale BW Scenarios and Customer Focus
1. 2. 3.
Consolidation BW Replacing several BWs into/ by a single BW Migration BW Redesigning/ Reengineering a BW Primary BW BW as primary source for all BI applications/ reporting and all organizations Integration BW BW as integrated source for cross-organizational BI/ Reporting in addition to an existing BW/ DWH landscape The scenarios overlap each other. What varies is the primary focus of the customer what again derives from the different starting position. .
4.
Large Scale BW Scenarios Different Starting Points

Consolidation BW
BW1 BW2
Migration BW
C-BW
BW3 BWn
BW-Old
M-BW
Primary BW
BW1
Integration BW
new
BW2
SAP ERP(s)
P-BW
BWn DWHn
I-BW
BW LSA: The Reference Architecture
LSA Building Blocks Reference
LSA Implementation Reference
LSA Operations Reference
BW LSA
Describes core structures & definitions
Describes design standards to build BI applications founded on building blocks

Data Staging/ Management for transactional & master data Persistent Objects Flows - scheduled/ recovery Transformation Programming (Abap) Organization (Process Ch.) Meta Data Management Naming Conventions Organization (InfoAreas)
Describes Support Scenarios
Landmark Building Blocks Layers Domains Data Model & Data Integration Assistant Building Blocks Data Quality Landscape ETL Storage Ownership/ Organize Development concept
Life Cycles Information Meta Object LSA Administration Data Base Housekeeping Monitoring Transport Security
Agenda

5. Summary
LSA Building Blocks The Architecture Cornerstones

The LSA Building Blocks are the cornerstones of your future architecture thus having a decisive influence on the overall success of your future BW EDW describe the general BW EDW layout independent from concrete BI applications and BI projects. Landmark Building Blocks deal with architecture areas that need fundamental decisions before doing implementations they play the same role like the supporting structures (pillars & ceilings) of buildings. Assistant Building Blocks deal with architecture areas that are normally less prior with respect to the point in time you should decide and roll out corporate standards.
LSA Building Blocks Reference
Describes core structures & definitions
Landmark Building Blocks Layers Domains Data Model & Data Integration Assistant Building Blocks Data Quality Landscape ETL Storage Ownership/ Organize Development concept
LSA Landmark Building Blocks Layers & Domains

There are two areas to standardize the architecture of persistent data stores:
1.
Structure the data stores in a flow from PSA to InfoCubes with respect to their role and the offered services define data layers Structure (split/ collect) the data within the layers to guarantee Layer and advanced Services define data domains Non-Architectured LSA Architectured
Domain
2.
Layer
data flow
LSA Landmark Building Blocks BW Data Model Strategy

What has a SAP BW data model strategy to consider? SAP BW has to cover reporting requirements from various organizational units 1. Support of corporate and local business scenarios (SAP BW InfoProvider)
Group
Division A
Division B
Division C
Division D
: SAP BW Scenarios (InfoCubes/ DS-Objects)
2.
Support of corporate and local master data (SAP BW InfoObjects)

Enterprise Scenario
SubOrg Scenarios SubOrg Scenarios
SAP BW data model:

LSA Assistant Building Blocks I
ETL (Extraction, Transformation, Load) Do you expect extensively data from non-SAP sources? If the answer is yes, it is meaningful for you investigating an ETL-tool like SAP Data Integrator. If SAP systems are the initial and primary sources for your future BW EDW, you just dont care. May be later on. Data Quality Do you have considerable data quality issues? If the answer is yes, it makes sense for you thinking about a Data Quality tool. Again, if integrated SAP systems are the initial and primary sources for your future BW EDW, you normally dont care. May be later on. Landscape - often reduced to Do I need a single or a multiple BW instance landscape. This topic has become more and more an assistant one, because of the arrival of new technologies and the transparent support by BW (BW Accelerator, Near Line Storage s. Storage). The landscape architecture comes into focus
if we have to support mission critical BI or to observe legal restrictions or with other customer specific requirements if it comes to agile BI and local autonomy (federated landscapes, SAP Newton appliances and BW EDW)
LSA Assistant Building Blocks II
Storage Traditionally all data of a BW DWH are hosted by an RDBMS. This is for large scale BW EDWs not adequate (also having a smaller BW you should rethink this strategy):
Rarely used data should be hosted by a Near Line Storage (NLS) tool. NLS tools compress your data offering space reduction up 95% (e.g. SAND) without destroying your Service Level Agreements (SLAs). The BW Accelerator (BWA) must be part of the overall architecture.
Ownership/ Organization Designing, implementing and operating a BW EDW need strong governance. A BI Competency Center (BICC) should be established if not existing yet.
Agenda

5. Summary
LSA Landmark Building Blocks Data Layer/ Layering of Data

NonArchitectured LSA Architectured
Dataflow
Dataflow
Layer
Layered means horizontal structuring/ modeling

The Data-logistic is organized in a unified, service-oriented way. Parameters are:
Coverage, comprehensiveness (Process, User demands) Granularity History (completeness) Value of Data Layers: Reusability (BI application scalability) + Highly Transparent & Flexible Recovery (robustness, availability) Quality +Development, Maintenance Integration +Administration, Operations Access-rights (End-user) +Database-Integration Life-cycle SAP 2009 / SAP Skills 2009 Conference / B1 / Page 24 .....
LSA Reference Layers

reporting, analysis ready BI Applications/ Architected Data Marts Layers abstraction near real time, operational like
Virtualization Layer Operational Data Store Operational Data Store Reporting Layer (Architected Data Marts)
apply business logic digestible, integrated, unified data, ready to consume EDW layers Application neutral Corporate owned Granular create harmonised view, guarantee quality 1:1 from extraction, temporary
Business Transformation Layer Data Propagation Layer Quality & Harmonisation Layer Corporate Memory Data Acquisition Layer
source system service level, long term, comprehensive, complete, master the unknown
LSA
Acquisition Layer and Subsequent Layers

The LSA suggests different 3 potential layers (targets) on top of the Acquisition Layer.
1. 2. 3.
Corporate Memory Propagation Layer (note: Harmonization Layer is optional, depending on situation) Operational Data Store
Other view on LSA, which keeps Implementation already in mind
Reporting Layer (Architected Data Marts) Shared Master Data (InfoObjects)
Operational Data Store Operational Data Store
Why so many layers?
Business Transformation Layer Data Propagation Layer CM Harmonization Layer Data Acquisition Layer
LSA
Acquisition Layer and Subsequent Layers

In a BW we have to fulfill different competing SLAs (Service Level Agreements) Experience shows that a single staging approach with single persistent stores for all purposes cannot achieve this! This applies the more challenging the conditions are for BW.
Note: This means on the other hand side that if we found less complex conditions the LSA Building Blocks set up can be more simple. This applies as well for an overall customer LSA set up as for specific data sources within a full blown customer LSA !
What are complex conditions and challenging requirements? 24x7, time zones high volume, not split able loads small recovery window (e.g. 6h) out sourcing (skills?) off shoring (skills?) high operational robustness high report availability (e.g. >96%) high application flexibility ....
Reporting Layer (Architected Data Marts) Shared Master Data (InfoObjects) Business Transformation Layer Data Propagation Layer CM Harmonization Layer Data Acquisition Layer
Operational Data Store Operational Data Store
LSA
LSA Reference Layers Acquisition Layer To Corporate Memory Layer

Acquisition Source Layer Systems Reporting Layer Business Transformation Layer Corporate Memory Objects complete history of loaded data utmost comprehensive manner 1:1 from Acquisition as rule of thumb in addition harmonized data may be stored in a dedicated Corporate Memory Object after complex harmonization/ transformation for backup reasons provide sourcesystem service level Enable managing all tasks, which are unforeseeable (reorganizations, basic changes..) and/ or do not happen on a Harmonize/ Propagation regular base (recovery, new init from source) Quality Layer If we have the same DataSource offered by EDW BI-Applications multiple source-systems we should go for a single CM DSO. (Data lifecycle management must exist!) Data flow Data flow NLS is the right place for CM data Corporate Memory
LSA Reference Layers Corporate Memory Flier

Criteria potential sources potential targets reusability transformations Characteristics Data Acquisition Layer, (Harmonization Layer) Data Propagation Layer (Business Transformation Layer, Reporting Layer) Yes 1:1 All extracted records for delta loads (copy of delta queue) comprehensive (all fields of a DataSource) additional fields to simplify administration & access complete source system like SLA Single Point of Truth of extracted data for delta/ changed data for full ultimate area for application recovery, new-build and DWH reorganization manage the unknown DataSource specific Write-optimized (wo) DSO for delta loads, normal DSO + wo DSO for full not directly in flow to applications (branched out) Request by request; no overwrite/ update of loaded records Should mainly reside on NLS (Near Line Storage)
DWH Services Implement Op.
granularity content history main services
store & deploy
update Data life cycle
SAP 2008 2009 / SAP Skills 2009 Conference / B1 / Page 29 SAPSAP //Page Skills 2009 Conference / B1 Page 29 2009 SAP 29
BW LSA Layer Description Example
Detailing LSA Reference Layers Acquisition to Propagator Layer
LS A Propagators Ex Business This flow describes daily, Reporting recurring weekly,.. Layerm a Acquisition Source Corporate Transformation feed finally the BI pl staging of data to Layer Systems Memory e Layer application layers Propagator DSOs offer data, which are easy to digest for BI applications on top: Easy to digest means standards like: Unified (additive) delta i.e. data can be direct processed into InfoCubes/ BWA index Data are integrated if the BI applications ask for integrated data Data are local if the BI applications ask for local, not corporate integrated data Data have no flavor with respect to specific business rule transformations but offer additional data with respect to the loaded Harmonize/ Propagation data, which are commonly or frequently needed by the BI applications Quality Layer Manageable portions of data to fulfill EDW BI-Applications Report Availability, Recovery, Administration SLAs(-> Domains) ...... Data flow Data flow
Detailing LSA Reference Layers Propagation Layer & Digestible Data
LS A
The core service of a Propagation Layer is to offer digestible data to applications i.e.: harmonized data in the broadest sense 1. integrating data: common semantics, common values 2. smoothing data: common semantics, technically unified values (e.g. compounding) unified data consistent behaviour of propagator DSOs regardless the DataSource trimmed to fit DataSources and Data persistencys to Reduce data complexity for applications
Ex am pl e
1. Extending data from a DataSources by looking up information, which applications frequently ask for. Note: introduced parent-child relationship must be stable otherwise realignment issues! 2. Merging different but highly related data from different DataSources in a single propagator, If application always or frequently request them together (e.g. HR InfoTypes, avoiding extractor enhancements) Provide sound data portions for better support of application services (availability etc) 3. Collecting data from the same (or similar) DataSource but from different source systems to less or a single source system independent propagator (s) ( LSA domains) 4. Splitting data from a DataSources into multiple persistencys with identical structure ( LSA domains)
Detailing LSA Reference Layers Propagation Layer & Trimming Data

DataSource A + DataSource A Propagator Propagator
Add data DataSource A DataSource A 1.Extend DataSource A DataSource A Source 1 Source 1
LS A
DataSource A DataSource A Propagator Propagator

3. Collect DataSource A DataSource A Source 2 Source 2
Ex am pl e
DataSource A & B DataSource A & B Propagator Propagator

2.Merge DataSource A DataSource A DataSource B DataSource B
DataSource A DataSource A Propagator 1 Propagator 1

4.Split
DataSource A DataSource A Note on Collecting and Splitting DataSources: This is very close related to LSA Domains! Both may not be applied without regarding volume of data!
LSA Reference Layers Data Propagation Layer Flier

Criteria potential sources potential targets reusability transformations Characteristics
Ex am Data Acquisition Layer, Harmonization Layer, Corporate Memory pl e

Business Transformation Layer, Reporting Layer Yes Additional, stable fields to increase (re-)useability & accessibility (e.g. currency translation). No application-specific rules! single records, granularity defined by DataSource business-key DataSource specific as comprehensive as possible, if propagator is expecting volatile requierments Merge of different DataSources to reduce complexity Minimum history defined by requirements of target-applications/ dependent from Corporate Memory existence Single Point of Truth for BI applications (Business Transf. & Reporting Layers) Provide digestible (additive delta, content, performance) data for BI applications application recovery, rebuilt normal DSO in overwrite semantical/ logical partitioned for large scale DWH/ time-zone support driven by BI application requirements (report availability) Regular delete of DSO change-log content
LS A
DWH Services Impl. Op.
granularity content
history main services
store & deploy
update housekeeping
Detailing LSA Reference Layers Sub-Layers of Reporting Layer

Reporting Layer
Flexible Reporting/ Granular Reporting Layer

Characteristics: highly granular highly comprehensive short life cycle flat, multidimensional
Analytics-/ Dimensional Layer

Characteristics: less granular less comprehensive long life cycle multidimensional optimized performance
Access Abstraction-/ Virtual Layer

Characteristics: abstract from physics virtual flexible view generation protect front-end investments
Planning Layer
Characteristics: dedicated for planning direct input structures
From Reference LSA to Customer LSA Example: Customer Defined Layers

Reference LSA
Reporting Layer (Architected Data Reporting Layer (Architected Data Marts) Marts) Business Transformation Layer Operational Data Store Operational Data Store
Customer LSA
LSA
Acquisition Layer Corporate Memory Layer Propagation Layer Business Transformation Layer Apply business-logic Flexible Layer Reporting Granular Dimensional Layer Reporting Performance Long term Virtual Layer
Data Propagation Layer Quality & Harmonisation Layer
Corp orate Mem ory
Data Acquisition Layer Data Acquisition Layer
1:1 Unlink
Unflavored Integrated Granular Ready to consume
YVAPP1nn
*
(YADSSnnn) YPDSSnnn YBAPPnnn
YFAPPnnn YDAPPnnn
Complete Comprehensive Most granular
YVAPP2nn
Abstraction Flexible
YCDSSnnn
Dataflow
lookup
Agenda

5. Summary
LSA Landmark Building Blocks Data Domains

NonArchitectured LSA Architectured Domain
Dataflow Dataflow
Layer
Domains means structuring/ modeling of data within the layers

Transparent, disjunct structuring of transactional data using stable criterion. Target is the support of: Independency/ autonomy of organizations Value of Data Domains: + Transparency & Flexibility 24x7, time-zones +Development, Maintenance Scalability / performance/ low latency +Administration, Operations (parallel vers sequential) + Scalability & Robustness Challenging recovery-window +Application Embedding into RDBMS +Load/ Query Performance Implementation & Operational robustness +Database-Integration
EDW Incremental Implementation

An EDW implementation is always an incremental one, never a big-bang.
1.
Incremental in terms of functional coverage BI application roll-out

BI Application Coverage & EDW
Generating Demand
2.
Incremental in terms of organizational coverage organizational roll-out

Organizational Coverage & EDW
Demand Planning
Needs Scalability that is addressed by (EDW)layers .....
Procure 2 Pay
COPA
.....
EDW
Needs Scalability that is addressed by domains (& data model) .....
Org Unit C
Org Unit A
Org Unit B
Org Unit N .....

EDW
BW EDW Data Domains Consolidation BW

A BW EDW replaces a bunch of existing BWs and/ or legacy DWHs (BI Consolidation) spread across the organization To enable comparable services like we had in a distributed, multiple DWH instance world (yes, there are some nice things) we introduce Data Domains in a BW EDW that divide the transactional data but use identical meta data & master data definitions..
X
North America
BW BW
BW BW BW BW
XX
Europe
ERP ERP ERP ERP
BW BW
Japan
ERP ERP
ERP ERP
Domain Americas
Domain Europe
Domain Asia Pacific

Asia Pacific
BW EDW
South America
ERP ERP
X X
BW BW
BW BW
ERP ERP
Using Domains in a BW EDW stands for manageability & flexibility Domains allow SLAs in a BW EDW like in a distributed BW world
BW EDW Data Domains Support of Enterprise ERP Rollout (Primary BW)

A single BW EDW shall offer standard reporting & analytics for all organizational units in a global ERP rollout. To enable comparable services like we had in a distributed, multiple BW instance world we introduce Data Domains in a BW EDW that divide the transactional data but use identical meta data & master data definitions.
Europe North America Japan
AMS
US
EMEA
Germany
APA
Asia Pacific
BW EDW
South America
Global ERP
BW EDW Data Domains Divide Data by Sources-Quality (Integration BW)
Main Domain
Remote Domain
BW EDW
main main ERP ERP

stable, controlled
remote remote ERP 1 ERP 1
remote remote ERP 2 ERP 2
less stable, no control
In Short: Domains makes always sense keeping large BW EDWs manageable & flexible
LS A
Domain West
Domain Central
Domain West
Domain Central
Domain West
Domain East
North America
Domain Central
Domain East
North America
Domain East
Ex am pl e
Europe
BW EDW
South America
BW EDW
South America
Domain EU
BW EDW
Company is operating In North America
Domain South AMS

Company is expanding to South America
Domain South AMS

Company is expanding to Europe
Transparent, Scalable Structuring Your BW: LSA Domains & Layers

LSA Domains distribute the transactional data for the entire BW EDW or certain areas (flows) in a disjunctive manner. The meta data definitions of domains are common.
Access Abstraction Layer (MultiProvider) Reporting Layer (Architected Data Marts)
Distribution Access Abstraction Layer (MultiProvider) actively designed: Domains Reporting Layer (Architected Data Marts)
Reporting Layer (Architected Data Marts)
LSA
LSA
Business Transformation Layer
Business Transformation Layer
Data Propagation Layer
Quality & Harmonisation Layer
Corporat e Memory
Data Propagation Layer
Corporat e Memory
Data Acquisition Layer
Data Acquisition Layer
Single Source System (Layer)
Distribution inherited
Multiple Source Systems (Layer)
The LSA addresses an evolutionary EDW approach introducing Data Domains to support local BI services without neglecting the broader EDW picture.
Criteria Defining LSA Domains
Golden rule defining domains: as many domains as necessary as less domains as possible Defining Domains rules of thumb Often a geography driven domain concept works well
Often one basic domain per continent makes sense ( rough time zone handling) e.g. APA, EMEA, Americas time zone aspects may lead to e.g. 3 Asian domains East-Asia, Mid-Asia, West-Asia E.g. for continental BW EDW a starting point could be East, Middle, West...
Expected Volume (realistic volume estimates are a key input defining domains )
Large APA volume contribution & large (for your business important) countries may get an own domain e.g. China and US
Independency (special service level agreement) for certain countries

Important countries/ markets get an own domain
Robustness: take Quality/ stability of different sources into consideration

(potential) instable data offerings from sources may lead to an own domain
Each customer may have additional criteria, normally it is a mixture of multiple items
LSA Building Blocks Define a Grid Example for Naming Conventions

Acquisition/ Corporate Propagation Flexible Dimensional Business PSA Layer Memory Layer Layer Layer Transformation Layer Layer Control tables * YFAPP1AX Asia Virtual Layer
YPDSS1AX
Europe
YPDSS1DX
YDAPP1AX
YBAPP1AX
*
YBAPP1DX
YFAPP1DX YDAPP1DX YVAPP1XX
Americas
(YADSS100)
*
YPDSS1GX YBAPP1GX
YFAPP1GX YDAPP1GX
Germany
YPDSS1AX:
Y : Owner US P : LAYER DSS : Area (DSS: DataSource/ APP: Application YCDSS100 1 : Sequence-no A : DOMAIN X : Further Partitioning
*
YPDSS1WX YBAPP1WX
YFAPP1WX YDAPP1WX YFAPP1UX YDAPP1UX YBAPP1UX
YVAPP1XX
*
YPDSS1UX
Lookup-tables
Domains and Source Systems Defining Adequate Domains

No domains Propagation adequate domains
?
Acquisition DataSource from single corporate source-system No domains Propagation Too many domains adequate domains
?
......
......
?
Acquisition ...... ...... Same DataSource from multiple source-systems
BW Customer LSA - Examples
Agenda

5. Summary
LSA & Master Data Situation

Master data have two main tasks to fulfill:

Being target of lookups during transactional data load Being the shared dimensions of InfoCubes for reporting (MultiProvider
Today InfoObject hosted master data (P,Q,S,X,Y tables) serve for both purposes.
Shared Dimension
(Navigational Attributes)
InfoObject Master data
Lookups Transactional loads
Master Data From Data Mart to BW Level/ LSA Managed MD I

Data Mart level managed master data:
Process Chain Data Mart A
Sub-Chain: Transactional loads
Step1: BW level managed master data:

Process Chain Data Mart B

Sub-Chain: Transactional loads Sub-Chain: Master data Load e.g. 0CUST_SALES + Change Run

Process Chain Master Data

Master data Load e.g. 0CUST_SALES + Change Run
2:00
1:15 1:00
Sub-Chain: Master data Load e.g. 0CUST_SALES + Change Run
With non-architected BWs the master data loads are often managed on BI application/ Data Mart level what leads to redundant, uncontrolled master data processing. This is unacceptable for large scale BWs
Master data should be collected/ prioritized and loaded across the Data Marts thus become BW/ LSA managed
Master Data LSA Reference Layers & Master Data

Step3: BW level managed master data & LSA
Large scale BWs should layer the master data allowing 1. Separation of staging and reporting tasks InfoObject tables for reporting Propagator DSO for staging Storing master data history (introducing active from activeto time-slice in Propagator DSO) Shared Dimension
(Navigational Attributes)
InfoObject tables
Reporting Layer (Architected Data Marts) Lookups Data Propagation/ CM Layer
LSA
2.
Master Data DSO
Data Acquisition Layer Example shows master data with delta load, master data with full loads need additional assistant DSO to determine delta
Master Data From Data Mart to BW Level/ LSA Managed MD III

Step3: BW LSA managed master data
InfoObject Update*
Process Chains EDW Transactional Data

Propagator/ Corporate Mem
Process Chains Master Data

InfoObject Change Run
Process Chains EDW Master Data

Propagator for 0CUST_SALES

Data Mart Layer B Trans Layer

Data Mart Layer B Trans Layer
InfoObject Update*
* both possible
Master data become BW/ LSA managed (Strategic Approach) EDW transactional & master data loads are as far as possible decoupled from Data Mart loads
Agenda

5. Summary
LSA/ EDW Implementation Reference Lessons Learned

Standardize data management as much as possible regardless the origin of data
Observe 80:20 rule first provide guidelines for core BI application requirements Implementations standards are developed incrementally Exceptions to implementation guidelines must be approved The more exceptions the less robustness and the higher TCO The bigger the expected EDW (meta data) will become the more generic the implementation must be Anticipate growth implementation standards must be able to manage growth Avoid serialization of data processing parallelize data flows Strategic follow customer domain concept (general logical/ semantical partitioned implementation) Strategic + Tactical expand domain concept by tactical parallelization to meet individual application requirements Tactical no general domains chosen use parallelization to meet individual application requirements Branch out services observe core services an put other services aside the main data flow Advertise & Train the idea of Customer LSA and implementation guidelines
LSA and BW DataWarehouse Workbench Layer & Domains Example
LSA EDW Layers & Data Unification
A main task of the LSA EDW-Layers is the unification of data. Unification means:
1.
All records get the same kind of additional information making data more transparent (stamping) Propagators should behave consistently
2.
A consistent Propagator behaviour should be the target for large scale BWs for overall robustness and consistency reasons: consistency of data marts, ease of operations. Unification should apply to transactional & master data
LSA EDW Layers & Data Unification Stamping Data

1.
All records contain the same kind of additional information making data more transparent (stamping)
1. 2. 3. 4. 5.
Origin (0SOURSYSTEM) YBWORG (criterion that drives domain partitioning) YLPART (domain) YLDAT (load date) Others (e.g. Request-ID) Source Organizational Criterion company code sales organization cost center employee .....
YLPART 1:n Domain -------<< e.g. EU
YBWORG Domain 1:n driving --------------<< BW criterion E.g. market
Split and Collect Control Data Unification & Domain Characteristics

BW EDW All data
YLPART Domain B
EMEA assign
Domain A
APA
Domain C
AMS
In BW EDW all loaded records will be qualified/ stamped assigning a stable domain- driving characteristic like market/ country to organizational criteria like in this example 0COMPCODE coming from source system.
This allows easy redistribution of a domain data if service levels cannot be kept
Country/ Market
E.g. FR
YBWORG
assign
Organizational-unit 0COMPCODE= FR01
YIOBJECT
0COMPCODE= FR02
E.g. UK
YLPART 1:n YBWORG 1:n YIOBJECT

,,,,,,,,
LSA EDW Layers & Data Unification Different Load-Types

2. Propagators should behave consistently
Unified BI application experience additive delta Data Propagation Layer
queue
via
via
via
moving
generic
full
complete full
incomplete full
via
full
LSA EDW Layers & Data Unification

Incomplete Full - Proposal
LS A
Ex am pl e
Situation: Extractor offers full loads. A DSO cannot calculate a delta with respect to last load as the new full load does not contain records, which were deleted in the source or contain zero bookings
1. 2. A-table Ch-Log 3. ActiQueue 4.
Transfer data to Propagator (1) DSO with added load timestamp and activate Propagator Via generic extractor read all records where load timestamp is older than last load timestamp and load to Propagator DSO (2) set all key-figures of selected records to zero Activate Propagator DSO (3) Propagator offers now complete additive delta Transfer to application Layer (InfoCubes) (4)
PSA
LSA Layer Implementation Propagation Layer & Trimming Data


3.Collect DataSource A DataSource A Source 2 Source 2


4.Split
DataSource A DataSource A
Data Propagator & Digestable Data - Example Merge HR-InfoType DataSources II

Infotyp 0001
from 01.01.09 01.01.10 to 31.12.09 31.12.99 OrgUnit 50000001 50000002 from 01.01.09 01.10.09
Infotyp 0002
to 30.09.09 31.12.99 Name Mller Meier from 12.02.10
Infotyp 0004
to 31.12.99
Ex am p Handicap le
50%
LS A
Merge (Abap: PROVIDE) Propagator Content:
01.01.09 01.10.09 01.01.10 12.02.10
30.09.09 31.12.09 11.02.10 31.12.99
50000001 50000001 50000002 50000002
Mller Meier Meier Meier
50%
Note: This is only an example: 0EMPLOYEE_ATTR DataSource merges InfoTypes: 0,1,7,8 all additional InfoTypes like 4 must be merged in the Propagator Layer




4.Split
LSA Layer Implementation Shield Layers with InfoSources I

Inbound InfoSource Shield of Subsequent Layer- unified view of layer as target Outbound InfoSource Shield of Layer in focus unified view of layer as source No Transformation Layer in focus DSO No Transformation Inbound InfoSource Shield of Layer in focusunified view of layer as target Central Transformation from Previous Layer to Layer in Focus Outbound InfoSource Shield of Previous Layerunified view of layer as source
Central Transformation from Layer in Focus to Subsequent Layer
LSA Layer Implementation Shield Layers with InfoSources II

Central Transformation from Layer in Focus to Subsequent Layer : No change No Transformations
Layer in focus: Two new DSOs (logical Partitions) of Domains introduced No Transformations Central Transformation from Previous Layer to Layer in Focus: No change
Collecting Data Multiple Sources and Domains

Layer Flow-logic Multiple Sources (A,B,C,D,E) to Propagator Domains (S,T,U)
PSA_DS1_A
InfoSource: YADS1100
InfoSource: YPDS1100
InfoSource: YPDS1200
PSA_DS1_B
YPDS11SX
PSA_DS1_C
YPDS11TX
PSA_DS1_D
YPDS11UX
PSA_DS1_E
Acquisition
Unification/
Harmonization
Propagation Data flow
DTPs




4.Split
Filling Domains Flow Split Implementation: Data Unification

The Pass Thru DSO based split The early PSA-based split
APA
EMEA
Americas
APA
EMEA
Americas
Propagators InfoSource Pass Thru WO-DSO
Propagators InfoSource
Unification InfoSource
PSA
Unification of data data management administration
PSA
Preferred
LSA Implementation Reference Automated Development & Maintenance

Acquisition/ Corporate Propagation Business PSA Layer Memory Layer Transformation Layer Layer
BW
7.2 0
Flexible Dimensional Layer Layer
Virtual Layer
Asia
YPDSS1AX YBAPP1AX
YFAPP1AX YDAPP1AX
YVAPP1XX
(YADSS100)
Americas
YPDSS1GX YDAPP1GX YBAPP1GX YVAPP1XX
YCDSS100
New BW development features e.g.: Copy/ Merge Data Flow ____ Semantical Partitioning ____
Data Flow Copies
BW
7.2 0
Data Flow Copy Wizard
Semantical Partitioning and Domains

Domains
BW
7.2 0
Subsequent Layers
APA
EMEA
AMERICAS
Acquisition Layer
InfoSource InfoSource
Source
Source
LSA Administration & Operations Automated Alerting & BW DB Statistics

Acquisition/ Corporate Propagation Business PSA Layer Memory Layer Transformation Layer Layer
BW
7.2 0
Flexible Dimensional Layer Layer
Virtual Layer
Asia
YPDSS1AX YBAPP1AX
YFAPP1AX YDAPP1AX
YVAPP1XX
(YADSS100)
Americas
YPDSS1GX YDAPP1GX YBAPP1GX YVAPP1XX
YCDSS100
New BW admin & operation e.g. BW DB Statistics ____ Automated Alerting for Process Chains _____
LSA Administration & Operations
BW DB Statistics
BW
7.2 0
LSA Administration & Operations
Automated Monitoring and Alerting
BW
7.2 0
SAP BW @Global CP Customer Layered, Scalable Architecture & Business Value
The result: Better an intermediate state

BW (Virtual) MultiProvider: cross market reporting Domains/ Logical BW Partitions: Market reporting EDW/ Corporate Memory: disjoint Granular- Most atomic Historical complete Comprehensive covers 95% of business in total ~ 150 TB allocated
1 : 1, not all today

Global EDW/ Corporate Memory in total ~40 TB
Global reporting/ dash boarding on integrated data with drill thru to most granular level
Agenda

5. Summary
SAP BW EDW & RDBMS

BW 60 TB Proof of Concept on DB2
RDBMS & Space Compression
SAP BW LSA / RDBMS / Hosts Transparency of LSA Enables Embedding

SAP BW LSA Architecture DB2 Partitioning Layout
0 1234567891111111111222222222233333333
Basis Tables Master Data 0123456789012345678901234567
MidSiz e Object s (Fact) 8 Partitio ns
BW-LSA-Cell
BW-DataClass(es) Tablespace(s)
LPAR 0 - 2 sysXdb02p App Server LPAR 1 - 2 sysXdb12p App Server
Dimensi on Tables
LPAR 2 - 2 sysXdb22p App Server
DB2 Partition(s)
virtual machines
4 FC
(FC 1 LPAR 0 - disk) sysXdb01p Storage Agent
8 FC
(FC - 1 LPAR 1 disk) sysXdb11p Storage Agent
8 FC
8 FC
8 FC
pSeries Architecture
4 FC
(tape)
8 FC
(tape)
8 FC
(tape)
8 FC
(tape)
8 FC
(tape)
4 FC
(FC 0 LPAR 0 - disk) sysXdb00p DB2 Partition 0
8 FC
(FC - 0 LPAR 1 disk) sysXdb10p DB2 Partition 6 13
8 FC
8 FC
8 FC
(FC disk) (FC 0 (FC 0 LPAR 2 disk) LPAR 3- 0 LPAR 4 - disk) sysXdb20p sysXdb30p sysXdb40p DB2 Partition 14 21 DB2 Partition 12 29 DB2 Partition 30 37
4 FC
(tape)
8 FC
(tape)
8 FC
(tape)
8 FC
(tape)
8 FC
(tape)
Renewing BW based on In-Memory Technologies Continuous Improvement and Accelerated Innovation

Continuous Improvement Improving todays DWH experience Accelerated Innovation Next generation DWH technology
Enterprise Data Warehouse Corporate memory layer (detailed data) and analysis marts synchronized on common metadata (x00 TB) Agile modeling Visual modeling environment to support modelers with different levels of sophistication. Reduce the Total cost of development (TCD) High data volumes Support handling of very large data volumes by pushing operations to underlying databases (IBM DB6) Agile Warehouse Operational data and dimensional analysis models (marts) available directly from memory (10th of TB)
Data Services Easy integration w/ 3rd party data Data quality for load processes
Mart Stand-alone accelerator for data marts (low data volumes)
Faster DataStore Activation with 7.20
BW
7.2 0
Optimization Focus
Standard DataStore Objects for building EDW-layers, i.e. optimize for fast updates is unchecked, no SIDs are created BEx flag
BW 7.0 DataStore Object

Activation is based on single lookups of active table.
BW 7.2 DataStore Object - Improvements

Activation is based on package fetch of active table Runtime option new, unique data records only prevents lookups during activation e.g. in case of initial loads Partitioning support by time characteristics
Performance gain for package fetch (lab results)

Avg. 20 40% improvement Max. improvement measured 2.5x faster Varies by data profile (#inserts/updates/deletes) and DB platform
SAP BW Layered, Scalable ArchitectureUse Adequate Storage and Access Disc-centric RDBMS
SAP NetWeaver BW
In-memory columnar Data Management
Analytical Reporting Layer Data Warehouse Layer Data Acquisition Layer
Memory-centric (Ram-based) data management:

By most measures, computing power doubles every couple of years. (Moores Law) Exception is disk access speed it has grown only 12.5-fold in a half a century Conventional DBMS are designed to get data on and off disk quickly Memory-centric products assume all the data is in RAM in the first place RAM access speeds are up to 1,000,000 times faster than random reads on disk.
SAP BW EDW & Transparent Data Management Use Adequate Storage BW & BWA/
In Memory, columnar
Data Management
BW & Near Line Storage (NLS)
SAP BW EDW & LSA Consistent Architecture, Consistent Data, Consistent BI
BW LSA
SAP BW Transparent Data Warehouse Management
BW Accelerator
Smart data aggregation & retrieval
Analytic Engine
RDBMS
Data Management
Cross Media Manager
Smart data warehousing
Staging Extraction
Near-Line Storage
Smart data volume management
Renewing BW based on In-Memory Technologies Continuous Improvement and Accelerated Innovation

Continuous Improvement Improving todays DWH experience Accelerated Innovation Next generation DWH technology
Enterprise Data Warehouse Corporate memory layer (detailed data) and analysis marts synchronized on common metadata (x00 TB) Agile modeling Visual modeling environment to support modelers with different levels of sophistication. Reduce the Total cost of development (TCD) High data volumes Support handling of very large data volumes by pushing operations to underlying databases (IBM DB6) Agile Warehouse Operational data and dimensional analysis models (marts) available directly from memory (10th of TB)
Data Services Easy integration w/ 3rd party data Data quality for load processes
Mart Stand-alone accelerator for data marts (low data volumes)
SAP BW Layered, Scalable ArchitectureUse Adequate Storage and Access (cont.) SAP NetWeaver BW Disc-centric Transparent RDBMS
Analytical Reporting Layer Data Warehouse Layer Data Acquisition Layer
In-Memory Columnar Data Management

BW Accelerator
Leverage Memory-centric (Ram-based) data management in SAP BW

Ram-based SAP BW Accelerator offers: Performance speedup factor between 10 and 100 Compression by factor 10 Easy migration, fully transparent Near Line Storage Interface (e.g. SAND Dynamic Near-Line Access) Fully integration to SAP BW (Query access & DataTransferProcess)
Vertical Decomposition Compression ~ 90%
Near-Line Storage
Agenda

5. Summary
EDW Incremental Implementation

An EDW implementation is always an incremental one, never a big-bang.
1.
Incremental in terms of functional and organizational coverage:

BI Application Coverage & EDW Organizational Coverage & EDW
Generating Demand
2.
It may be incremental in terms of landscape consolidation

Source Source Unit 1 DWH Stream C Local SAP BI Source SAP BI Unit 2 SAP BI Local Source SAP BI Local Source SAP BI Source Group SAP BI
Demand Planning
Org Unit C
Procure 2 Pay
Org Unit A
Org Unit B
Org Unit N
COPA
.....
EDW
.....
.....
EDW
.....
Global BI APA AMS EMEA: 1 2
Global BI APA AMS EMEA :
Step 1 BI/ DWH Consolidation - Centralization
Tools, Architecture, Development, Organization, Processes
Tools: SAP BW, BIA
Architecture & Landscape: BW LSA/ BW EDW
Development: central BI applications template
Organization: BI CC Processes
As a result of BI & DWH Consolidation we find a new corporate Information culture: Awareness about the value of standards for consistency, flexibility & TCO
Step 1: BI/ DWH Centralization Value of LSA & Central Template

Centralize BI/ DWH:
Central BI Applications Template
Covering standard BI needs Central template comprises: Complete dwh management Complete front-end design Complete operational setting
Corporate-wide standardized reporting & analytics as core BI offering based on Customer LSA.
Value:
consistent data & applications scalable applications on EDW flexibility caused by granular EDW driving organizational & process alignment reduced TCO & TCD
BW EDW Customer LSA
Step 1: BI/ DWH Centralization Limits of Centralized BI

BI template coverage of end-user needs
Central BI Applications Template

Covering standard BI needs Central template comprises: Complete dwh management Complete front-end design Complete operational setting
What is the coverage of the template-based core BI offering with respect to end-user needs? Depending on central governance, functional-area and customer industry we could expect 60-100% There is a BI gap that cannot be closed by centralization! How to close this gap?
BW EDW Customer LSA
Centralization with Federation gives the holistic BI picture! What kind of Federation is reasonable depends on the gap-size.
Step 2: BI Centralization & Federation A) Data Federation Small Gap

Coverage of end-user needs
E.g. CP-Customer Sales-force & local market data

Query/ Semantical Layer
Solution: Standard template + Data Federation
Central BI Local BW EDW
Step 2: BI Centralization & Federation B) Newton Federation Medium Gap

Coverage of end-user needs
E.g. pharma industry: considerable amount of individual country reporting Query/ Semantical Layer
Central BI Country 1 Newton Country2 Country3 Server Newton Server Newton Server Country1 Source
BW EDW
Step 2: BI Centralization & Federation c) BW Federation Large Gap Hub & Spoke
Coverage of end-user needs E.g. mining industry divisional reporting (Aluminum, petrol..) Prerequisite: educated IT staff at divisional side Query/ Semantical Layer
Central BI BW BW Divisional BI BW Divisional BI Divisional BI Divisional Sources
BW EDW
Agenda

1. Storage - RDBMS & Columnar DMS 2. Landscape: BW Centralization & Federation 5. Summary
Life Cycle of The Customer LSA
BW LSA: The Reference Architecture Step 1: Step 4:
Design
Customer LSA
Update
Step 2:
Apply
Customer LSA
Step 3:
Perfect
Customer LSA Handbook Shell
Customer LSA Handbook Shell
Customer LSA Handbook Land Hessen
SAP 2009 SAP Skills 2009 Conference / B1 / Page 99 SAP 2009 //Daimler - BW Layered, Scalable Architecture (LSA) Intro, Juergen Haupt /200903/ Page 99
Life Cycle of The Customer LSA
SAP LSA: The Reference Architecture Step 1: Step 4:
Design
Customer LSA
Update
Step 2:
Apply
Customer LSA
Step 3:
Perfect
New Planned Features with BW 7.20 for BW EDW

Description Hybrid Provider TransientProvider Enhancements Real Time Data Acquisition Semantic Partitioning Monitoring: New Technical Content CTC templates for setting up BW systems Area EDW EDW EDW EDW EDW EDW Function InfoProviders InfoProviders InfoProviders InfoProviders Operations Operations
Before Export Check Generic Delta functionalities for further kinds of DataSources Multi Source System InfoPackage transport Web Service (Pull!) DataStore Object: Partitioning by time DataStore Object: Improved Activation, Initial Load DataStore Object: Remodeling Hierarchies: Integration into data flow via DTP, Transformation EDW EDW EDW EDW EDW EDW EDW EDW
Search Enhancements in DWB Soft shutdown for BW systems Process chain job overview (RSM37) Enhanced process chain monitoring (RSPCM) Reset interface for process chains Restarting loading processes in background Delete content of table RSDDSTAT_WHM Data request archiving for DTP requests InfoPackages that switch automatically from Init to Delta Delta INIT without data transfer for DTPs Copy data Flow Migration Tools 3.x -> 7
EDW EDW EDW EDW EDW EDW EDW EDW EDW EDW EDW EDW
Usability Operations Operations Operations Operations Operations Operations Operations Operations Implementation Implementation Implementation
Hierarchies: remote Hierarchies EDW Loading hierarchies through tRFC EDW Open Hub Destination - XML as format EDW Open Hub Destination - Export of field values in external format Field selection in start/end EDW Transformation routine Transformation - Currency conversion for DataStore Objects Mapping Content Technology NLS_Archiving: Support of MultiProviders NLS_Archiving: Transparent embedding of NLS into Dataflow (depending on selection System uses appropriate source) Archiving of uncompressed InfoCube data (relevant for all DBs!!!) EDW EDW EDW EDW
EDW
EDW
Defining a BW / BI Excellence Framework* Reminder
Strategy
Business Objectives, Transparency
Alignment
Organization
Skills, BI Competency Centre
Performance Management, Methodology
Process
Realization
Applications and Functionality

BI Flavors ; Reporting; Strategic, Operational and Analytical Applications
Efficiency Suitability Consistency Flexibility
Infrastructure
Enterprise Layer Concept, Data Marts, ODS, ETL, BI-Topology, Data Quality, Data Model SAP ERP SAP CRM Other Legacy
BI Framework*
BI Business Value Drivers

* BI Framework introduced by Gartner
Layered Scalable Architecture (LSA) as Best Practice Modeling of High-End BWs

The LSA is a Best Practice modeling for large SAP BW Data Warehouses. The LSA structures and standardizes a BW DWH in a transparent, service-level oriented, scalable manner. Transparency is achieved introducing a grid on a BW DWH defined by Data Layers and Data Domains Services are modeled by Data Layers Scalability and Manageability is guaranteed by Data Domains The broader the organizational and value-chain coverage of a BW DWH is, the more necessary is a design-standardization like propagated by the LSA. The most comprehensive approach of a BW data logistic is an Enterprise Data Warehouse (EDW)
LSA Architectured
A transparent data-logistic like a Layered, Scalable Architecture is a key success factor of BW High-End-/ EDW-implementations!
Basic concepts can very well applied to smaller implementations!
Dataflow
Further Info
juergen.haupt@sap.com
Blogs: SAP NetWeaver BW: BW Layered Scalable Architecture (LSA) / Blog Series https://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/14313
Workshop SAP Education Germany: PDEBW1 - BW-Blueprinting an Enterprise Data Warehouse: Architecture and Implementation Best Practices
Q&A
Thank you!
Copyright 2009 SAP AG All Rights Reserved

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice. Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors. Microsoft, Windows, Excel, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation. IBM, DB2, DB2 Universal Database, System i, System i5, System p, System p5, System x, System z, System z10, System z9, z10, z9, iSeries, pSeries, xSeries, zSeries, eServer, z/VM, z/OS, i5/OS, S/390, OS/390, OS/400, AS/400, S/390 Parallel Enterprise Server, PowerVM, Power Architecture, POWER6+, POWER6, POWER5+, POWER5, POWER, OpenPower, PowerPC, BatchPipes, BladeCenter, System Storage, GPFS, HACMP, RETAIN, DB2 Connect, RACF, Redbooks, OS/2, Parallel Sysplex, MVS/ESA, AIX, Intelligent Miner, WebSphere, Netfinity, Tivoli and Informix are trademarks or registered trademarks of IBM Corporation. Linux is the registered trademark of Linus Torvalds in the U.S. and other countries. Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarks of Adobe Systems Incorporated in the United States and/or other countries. Oracle is a registered trademark of Oracle Corporation. UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group. Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix Systems, Inc. HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C, World Wide Web Consortium, Massachusetts Institute of Technology. Java is a registered trademark of Sun Microsystems, Inc. JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape. SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAP Business ByDesign, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and other countries. Business Objects and the Business Objects logo, BusinessObjects, Crystal Reports, Crystal Decisions, Web Intelligence, Xcelsius, and other Business Objects products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of Business Objects S.A. in the United States and in other countries. Business Objects is an SAP company. All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary. These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warrant.

BW Layered Scalable Architecture (LSA) 07

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

BW Layered Scalable Architecture (LSA) 07

Uploaded by

Copyright:

Available Formats

SAP Skills 2009 Conference BW Layered Scalable Architecture (LSA) Die Referenzarchitektur zur Standardisierung von unternehmensweiten Business-WarehouseImplementierungen

Juergen Haupt, Architect, SAP NetWeaver RIG BI EMEA 02.07.2009

3. LSA Implementation Unified Data Warehousing 4. BW LSA Assistent Building Blocks

SAP 2009 / SAP Skills 2009 Conference / B1 / Page 2

BI & Data Warehouse Market

Competitive View DW/BI

BI Value & Data Logistics

BI Maturity & Data Logistic Excellence

SAP 2009 / SAP Skills 2009 Conference / B1 / Page 4

Highly volatile environment Continuous roll out Continuous BI projects

EDW + X = BW + BW Layered Scalable Architecture (LSA)

BW Model-Driven Data WarehousingBW Means DWH Standardization & Automation

BW is from all perspectives fully model-driven

DWH structure modeling

DWH operations modeling

Crossing the EDW Chasm: The BW Layered Scalable Architecture

SAP 2009 / SAP Skills 2009 Conference / B1 / Page 8

3. LSA Implementation Unified Data Warehousing 4. BW LSA Assistent Building Blocks

SAP 2009 / SAP Skills 2009 Conference / B1 / Page 9

Layered Scalable Architecture Standardized, Transparent, Efficient

SAP 2009 / SAP Skills 2009 Conference / B1 / Page 11

DEPLOYING STANDARDIZATION NOT NICE, BUT TRANSPARENT WEBI ON SAP

out ll ab n is a atio LSA rdiz The anda St

SAP 2009 / SAP Skills 2009 Conference / B1 / Page 12

BW LSA And Customer LSA

BW LSA: The Reference Architecture Step 1: Step 4:

SAP 2009 / SAP Skills 2009 Conference / B1 / Page 13

Large Scale BW Scenarios and Customer Focus

SAP 2009 / SAP Skills 2009 Conference / B1 / Page 14

Large Scale BW Scenarios Different Starting Points

SAP 2009 / SAP Skills 2009 Conference / B1 / Page 15

BW LSA: The Reference Architecture

LSA Building Blocks Reference

LSA Implementation Reference

LSA Operations Reference

Describes core structures & definitions

Describes design standards to build BI applications founded on building blocks

Describes Support Scenarios

3. LSA Implementation Unified Data Warehousing 4. BW LSA Assistent Building Blocks

SAP 2009 / SAP Skills 2009 Conference / B1 / Page 17

LSA Building Blocks The Architecture Cornerstones

LSA Building Blocks Reference

Describes core structures & definitions

LSA Landmark Building Blocks Layers & Domains

SAP 2009 / SAP Skills 2009 Conference / B1 / Page 19

LSA Landmark Building Blocks BW Data Model Strategy

: SAP BW Scenarios (InfoCubes/ DS-Objects)

Support of corporate and local master data (SAP BW InfoObjects)

SAP BW data model:

LSA Assistant Building Blocks I

LSA Assistant Building Blocks II

SAP 2009 / SAP Skills 2009 Conference / B1 / Page 22

3. LSA Implementation Unified Data Warehousing 4. BW LSA Assistent Building Blocks

SAP 2009 / SAP Skills 2009 Conference / B1 / Page 23

LSA Landmark Building Blocks Data Layer/ Layering of Data

Layered means horizontal structuring/ modeling

LSA Reference Layers

LSA Reference Layers

Acquisition Layer and Subsequent Layers

Reporting Layer (Architected Data Marts) Shared Master Data (InfoObjects)

Operational Data Store Operational Data Store

Why so many layers?

SAP 2009 / SAP Skills 2009 Conference / B1 / Page 26