SAP Business Information Warehouse-Based Enterprise Data Warehouse - More Than a Vision

Transcription

1 SAP Business Information Warehouse-Based Enterprise Warehouse - More Than a Vision Jürgen Haupt SAP NetWeaver RIG, SAP AG Learning Objectives As a result of this workshop, you will be able to: Understand basic architecture aspects of a corporate implementation approach See the basic differences between a Mart driven implementation and a implementation based on a enterprise data warehousing strategy Examine an existing Landscape from a corporate point of view SAP AG 2003, 254, Jürgen Haupt/ 2

2 Agenda Evolution of Enterprise Warehousing Basics Controlled Redundancy Architecture Aspects Layer Model Landscape Further Aspects of a Corporate Strategy Integration Application Development Exercise Discussion Summary SAP AG 2003, 254, Jürgen Haupt/ 3 Evolution of SAP Isolated Implementations Strategic Corporate Implementations n Global Headquarter Reporting Scenario Others 2 3 Local Local Global Architected Landscape Scenario n Local Issues: Synergy Integration Consistency Enterprise Spoke Spoke Enterprise Warehouse Scenario SAP AG 2003, 254, Jürgen Haupt/ 4

3 Basic Corporate Landscape Strategies Inside-Out Enterprise Warehouse Enterprise Others Spoke Spoke Others Local Local Outside-IN Landscape Global Spoke Local Guarantee Consistency Reduce Costs Unilever HPCE SAP AG 2003, 254, Jürgen Haupt/ 5 Agenda Evolution of Enterprise Warehousing Basics Controlled Redundancy Architecture Aspects Layer Model Landscape Further Aspects of a Corporate Strategy Integration Application Development Exercise Discussion Summary SAP AG 2003, 254, Jürgen Haupt/ 6

4 Redundancy and Mart (Solution) Focus Impacts of non-existing corporate guidelines: Redundant Redundant Extraction Redundant Transformation Redundant Business Rules Redundant Masterdata Application Project Team Real World Information Requirements (grouped to Scopes) Schema-Modeling InfoCubes/ ODS-Objects Business Rules Transformation Extraction Sources Successful Warehousing means Controlled Redundancy!! SAP AG 2003, 254, Jürgen Haupt/ 7 Redundancy and Multiple Landscape Global Local A Real Life Landscape Example SubDiv Sales Europe HQ Asia Impacts of non-existing corporate guidelines: MDMS Redundant Flows Redundant Extraction Redundant Development Redundant Models... N-America S-America Sub-Division A R/3 Global Sub-Division B R/3 only Germany Sales Europe R/3 Div R/3 Div R/3... Div R/3 12 systems worldwide Source Systems Successful Warehousing means Controlled Redundancy!! SAP AG 2003, 254, Jürgen Haupt/ 8

5 Controlling Redundancy Extraction Staging Processes Transfer rules Update rules Model (s) Applications... SAP AG 2003, 254, Jürgen Haupt/ 9 Agenda Evolution of Enterprise Warehousing Basics Controlled Redundancy Architecture Aspects Layer Model Landscape Further Aspects of a Corporate Strategy Integration Application Development Exercise Discussion Summary SAP AG 2003, 254, Jürgen Haupt/ 10

6 Aspects of an Enterprise Warehouse Architecture Store Architecture - Layer Architecture Persistently stored data schemas Architecture Model Architecture Objects and their relations Relations between the models Warehouse Landscape Architecture The instances and their roles SAP AG 2003, 254, Jürgen Haupt/ 11 SAP Layer Architecture - Overview SAP Business Information Warehouse Acquisition Staging Cleansing Area Transform Primary Management Delivery Warehouse Architected Marts any source Extraction / Open Staging Master Reference Transaction ODS Extended Star Schemas Finance Logistic Open Distribution any target Flow Control Meta SAP AG 2003, 254, Jürgen Haupt/ 12

7 Mart Implementation Incremental, scope-specific Real World Information Requirements (grouped to Scopes) Modeling InfoCubes Business Rules Transformation Extraction Sources SAP AG 2003, 254, Jürgen Haupt/ 13 Mart Layer: Extended Star Schema Local Part of Material Dimension InfoCube Material_Dimension_ID SalesOrg_Dimension_ID Time_Dimension_ID Customer_Dimension_ID Sales Amount Quantity FACT Table Material_Dimension_ID Material Number Material Dimension Table Material Dimension Material Master Table Material Material Number Number Material Type Material Text Table Material Material Number Number Language Language Code Material Name Code Material Hierarchy Table Region 1 Bezirk Material 1 Bezirk 2 Bezirk Group 3 Bezirk 4 Bezirk 5 Gebiet 1 Gebiet 2 Gebiet 3 Gebiet 3a Vertriebsorganisation Region 2 Gebiet 4 Gebiet 5 Gebiet 6 Region 3 Gebiet 7 Gebiet 8 Extended Star Schema Shared, global Part of Material Dimension SAP AG 2003, 254, Jürgen Haupt/ 14

8 Horizontal Consistency InfoObject Master is the Glue Horizontal Consistency InfoObject Master is the Glue CUSTOMER master CUSTOMER InfoCube MATERIAL CUSTOMER ODS-Object CUSTOMER InfoCube MATERIAL Horizontal Consistency: Conformed Structures InfoObjects master data MATERIAL master SAP AG 2003, 254, Jürgen Haupt/ 15 Mart Support of Different Historical Views Constellation 09/1998 Customer Mother-Company AAA BBB X Y Slowly Changing Dimensions and Reporting Results : I) Report using today s (10/98) constellation Mother-Comp Rev 09/98 Rev 10/98 X Y 0 0 Customer Date Revenue AAA 09/ BBB 09/ AAA 10/ BBB 10/ Fact Table supported historical Views in a single InfoCube II) Report using 09/98 constellation Mother-Comp Rev 09/98 Rev 10/98 X Y III) Report showing historical truth Mother-Comp Rev 09/98 Rev 10/98 X Y Customer Mother-Company AAA X BBB X (changed) Constellation 10/1998 IV) Report showing comparable results Mother-Comp Rev 09/98 Rev 10/98 X Y 0 0 SAP AG 2003, 254, Jürgen Haupt/ 16

9 History of Master (Slowly Changing Dimensions) Architected Marts Master History and Architected Marts The InfoObject master data tables are designed to form the Conformed Dimensions of the Architected data marts The Architected data marts allow handling all relevant historical views of master data. For most scopes, storing the actual relationships in the master data table is sufficient Validity periods of relationships offered by the source application may be stored using the time dependent feature. Avoid storing historical versions of master data relationships using the time-dependent feature as this corrupts query performance It is normally not the task of this layer to handle complete historical master data versions! SAP AG 2003, 254, Jürgen Haupt/ 17 Information Completeness and Mart Layer (I)- Transaction Processing Customer Dimension InfoCube Material Dimension A Customer Material Time Amount Company Currency A Architected Mart Layer A other InfoCube Time Dimension other InfoCube monthly weekly daily daily Sourcesystem Customer Time DocNo Pos Material Amount Local Currency A am New booking A pm Correction booking A pm New booking SAP AG 2003, 254, Jürgen Haupt/ 18

10 Information Completeness and Mart Layer (II)- Master Processing InfoObject Master Table Customer CustomerGroup A Y after 2nd Load Customer CustomerGroup A X 1st Load: A Y 2nd Load: Master from Source or Master Server Architected Marts (ADM) means: Aggregation Overwriting Manipulation As the ADM layer is reporting driven we lose information, if the information does not support the data mart scope SAP AG 2003, 254, Jürgen Haupt/ 19 A Matter of Consistency and Reliability The Warehouse (Layer) SAP Business Information Warehouse Acquisition Staging Cleansing Area Transform Primary Management Delivery Warehouse Architected Marts any source Extraction / Open Staging Master Reference Transaction ODS Extended Star Schemas Finance Logistic Open Distribution any target Flow Control Meta SAP AG 2003, 254, Jürgen Haupt/ 20

11 Introducing a Warehouse Layer It is not the task of the scope oriented Mart Layer to anticipate any kind of future arising needs this would overload the schemas and corrupt performance It cannot be expected that the data mart project teams have the 360 corporate view to guarantee: extract once deploy many controlled redundancy single point of truth flexible structures Make the result of the data transformation and cleansing process persistent in a way that is: Warehouse Layer Subject oriented Integrated Granular Non-volatile (historical) Not (application) flavored Warehouse Layer ODS- Objects, Flexible Staging SAP AG 2003, 254, Jürgen Haupt/ 21 Transaction Processing in the DWH Layer InfoCube Customer Dimension Material Dimension A Customer Material Time Amount Company Currency A Architected Mart Layer A other InfoCube Time Dimension other InfoCube monthly weekly daily Warehouse Layer Customer Time DocNo Pos Material Amount Local Currency Amount Company Currency A am A pm A pm daily Sourcesystem Customer Time DocNo Pos Material Amount Local Currency A am New booking A pm Correction booking A pm New booking SAP AG 2003, 254, Jürgen Haupt/ 22

12 Master Processing in the DWH Layer InfoObject Master Table Customer CustomerGroup A Y after 2nd Load DWH ODS-Object Customer Activ From CustomerGroup A X after 2nd Load A Y Customer CustomerGroup A X 1st Load: A Y 2nd Load: SAP AG 2003, 254, Jürgen Haupt/ 23 Processing in the DWH Layer DWH layer data processing means: All data has to pass this layer on it s path from the source to the Architected Marts The data is not aggregated. The data is not manipulated to please specific project scopes Old versions are not overwritten or changed but useful information may be added is integrated as far as possible The data is normally not the primary target for reporting and analysis is extracted only once and deployed many Define Warehouse Layer General Guidelines Corporate Guidelines must be set up and an administrator must be established to achieve benefits from a Warehouse layer. SAP AG 2003, 254, Jürgen Haupt/ 24

13 Benefits of a DWH Layer Flexibility Create new analysis data marts without extracting data once again A potential fall back line to cover single time unexpected end-user needs (kind of basic ad hoc reporting/ analysis) Reliability, Audit Trail A Single Point of Truth All data from the source systems have to path this layer on their way to the end-user Complete History/ Versions Consistency, Controlled Redundancy is extracted only once and deployed many times Redundant staging processes are avoided Realization of the corporate integration strategy is not a matter of a departmental project team Integration semantical common coding The Warehouse Layer is the corporate memory, the corporate information repository SAP AG 2003, 254, Jürgen Haupt/ 25 Vertical Consistency Real World Controlled Controlled Redundancy Redundancy Extract Extract once once Deploy Deploy many many Single Single Point Point of of Truth Truth Application Project Team EDW Admin Team Information Requirements (grouped to Scopes) Modelling InfoCubes Business Rules EDW Transformation Extraction Sources SAP AG 2003, 254, Jürgen Haupt/ 26

14 The central role of the DWH If Warehouse layer functionality is established at corporate level you can think of the Warehouse as your corporate memory, your corporation s information repository. This is the reason that this layer is often called the Enterprise Warehouse. SAP AG 2003, 254, Jürgen Haupt/ 27 Persistent Staging Area (PSA) Makes a DWH Layer the PSA obsolete? The answer is : just partly Staging Area: PSA Cleansing Transform 1. Backup for non-mature applications 2. Uncouple extraction from processing any source Extraction / Open Staging Warehouse ODS Best Practice: Reduce Space Requirements Introducing a PSA Lifecycle Concept The role of the PSA as backup is limited if a Warehouse layer is used. For backup purposes of mature applications, the PSA is no longer needed. Thus, PSA-element entries could be deleted normally after 2 to 4 weeks. Not deleting the entries may lead after short time to significant disk space usage SAP AG 2003, 254, Jürgen Haupt/ 28

15 Near Real Time Warehousing ( Vers. 4) Operational Store SAP Business Information Warehouse Acquisition Staging Cleansing Area Transform Primary Management Delivery Warehouse Architected Marts any source Extraction / Open Staging Master Reference Transaction ODS Extended Star Schemas Finance Logistic Open Distribution any target Flow Control Meta SAP AG 2003, 254, Jürgen Haupt/ 29 A Matter of Information Perspective Classic Warehousing and Operational Reporting Information Perspective: Strategic Tactical - Operational An information perspective can be classified by 4 Granularity 4 Historical background 4 Latency or Load Frequency 4 Reliability (Auditing) 4 Target group 4 Information Retrieval Behavior SAP AG 2003, 254, Jürgen Haupt/ 30

16 Classic Warehousing and Operational Reporting The classic data warehousing approach: Dedicated load and staging processes High quality Optimized retrieval structures Reduce workload on OLTP systems Extraction / Open Staging Warehouse Master Reference Transaction Architected Marts Mart Finance Mart Logistic Tactical / Strategic Question: And how do I handle my operational reporting in? SAP AG 2003, 254, Jürgen Haupt/ 31 Operational Reporting in I In most of the cases operational reporting needs can be supported in using the classic data warehouse process Extraction / Open Staging Warehouse Master Reference Transaction Architected Marts/ ODS-Objects Objects Mart Finance Mart Logistic ODS-Object Sales Orders Tactical / Strategic / Operational..most of the cases.. : classical data warehousing has its limits if we want to provide event-level or close to event-level operational reporting (near real time reporting) and/ or if we are confronted with huge data volumes for operational reporting SAP AG 2003, 254, Jürgen Haupt/ 32

17 Operational Reporting and Classic DWH Issues I Be careful using the same InfoCube for operational and tactical reporting: if the transactional volume is high if you want to report on atomic data InfoCube Granularity X history 1:1 DWH ODS- Object 1:1 PSA Granularity X Granularity X operational operational not used tactical/ tactical/ strategic strategic last load 1/2 year old data 1 year old data 2 years old data granularity day week month quarter year Source most atomic Granularity X SAP AG 2003, 254, Jürgen Haupt/ 33 Operational Reporting and Classic DWH Issues II Solution A: Operational reporting could be done on the DWH-ODS-Object if just list reporting is desired. Tactical reporting is done on the InfoCube, which keeps aggregated data Drill thru from InfoCube to atomic DWH-ODS-Object is possible InfoCube Aggregation DWH ODS- Object Granularity < X Granularity X Issues: Responsibility? DWH-ODS-Object must be reporting enabled Remember the guidelines for the DWH Layer 1:1 PSA Granularity X Source most atomic Granularity X SAP AG 2003, 254, Jürgen Haupt/ 34

18 Operational Reporting and Classic DWH Issues III Solution B: Dedicated InfoCubes/ ODS-Objects with atomic data support operational reporting directly loaded from PSA life cycle of data normally not more than 6 month they build an ODS An InfoCube with aggregated data supports tactical reporting Drill thru from InfoCube to detailed data Loading DWH layer several times per day and tactical InfoCube once per day ODS Granularity X Life time < 6M InfoCube or ODS-Obj. several loads/ day rules applied PSA InfoCube Aggregation 1 load/ day DWH ODS- Object integrated 1:1 Marts Granularity < X Life time >=2 Y DWH Granularity X Granularity X 1 - several loads per day Source most atomic Granularity X Mixing operational and tactical reporting using the same InfoCubes may corrupt load and retrieval performance! SAP AG 2003, 254, Jürgen Haupt/ 35 Transaction Processing and Operational Reporting Operational Store after 11 am load Customer Time DocNo Pos Material Amount Local Currency A after 5 pm load Customer Time DocNo Pos Material Amount Local Currency A A times a day Sourcesystem Customer Time DocNo Pos Material Amount Local Currency A am New booking A pm Correction booking A pm New booking SAP AG 2003, 254, Jürgen Haupt/ 36

19 Transaction Processing in the DWH Layer InfoCube Customer Dimension Material Dimension A Customer Material Time Amount Company Currency A Architected Mart Layer A other InfoCube Time Dimension other InfoCube monthly weekly daily Warehouse Layer Customer Time DocNo Pos Material Amount Local Currency Amount Company Currency A am A pm A pm daily Sourcesystem Customer Time DocNo Pos Material Amount Local Currency A am New booking A pm Correction booking A pm New booking SAP AG 2003, 254, Jürgen Haupt/ 37 and Operational/ Real Time Reporting Key-Questions: Latency? Integration? Workload on OLTP Systems? Ul Near real time data warehousing remote InfoCube virtual InfoCube classic data warehousing Adaptors Integration Acquisition JDBC ODBO XMLA SAP Query OLTP SAP AG 2003, 254, Jürgen Haupt/ 38

20 Operational / Real Time Reporting Scenario Latency Integration Workload on OLTP Systems Classic 1- several loads Y 1 time per day extraction workload Remote 0 Y query workload InfoCube Virtual 0 Y query workload InfoCube near real time 0 Y 1 time data warehousing extraction workload BI direct access 0 N query workload SAP AG 2003, 254, Jürgen Haupt/ 39 Warehousing and Historical Information volatile granular Operational Store Architected Marts volatile summarized non-volatile granular Warehouse The Warehouse is the only place to store historical information complete unfiltered in various fashions Various fashions of history temporal data SAP AG 2003, 254, Jürgen Haupt/ 40

21 SAP Layer Architecture - Overview SAP Business Information Warehouse Acquisition Staging Cleansing Area Transform Primary Management Delivery Warehouse Architected Marts any source Extraction / Open Staging Master Reference Transaction ODS Extended Star Schemas Finance Logistic Open Distribution any target Flow Control Meta SAP AG 2003, 254, Jürgen Haupt/ 41 Agenda Evolution of Enterprise Warehousing Basics Controlled Redundancy Architecture Aspects Layer Model Landscape Further Aspects of a Corporate Strategy Integration Application Development Exercise Discussion Summary SAP AG 2003, 254, Jürgen Haupt/ 42

22 Operational Models and the Warehouse Model Inconsistent data warehouse data models stovepipe solutions Consistent data warehouse data model long term success A data warehouse consistency challenge Not aligned operational data models Consistent enterprise data model SAP AG 2003, 254, Jürgen Haupt/ 43 SAP Applications and the Warehouse Model Consistent data warehouse data model for SAP Applications and others long term success A data warehouse consistency challenge Not aligned operational data models SAP enterprise data model SAP AG 2003, 254, Jürgen Haupt/ 44

23 Enterprise Model and Expandable Model (Business Content) I 0MATTYPE 0AMOUNT 0CUSTOMER Model 0SALESORG 0MATERIAL 0MATGR 0DOCNO 0SALESPERS operative entities and attributes InfoObjects Enterprise Model: e.g. mysap Component Object Models Customer Entities, Attributes -> InfoObjects Material Type Material Material Group Sales ORG Sales Person Sales Transaction SAP AG 2003, 254, Jürgen Haupt/ 45 Mart Model 0CUSTOMER 00CUSTGR... 0MATERIAL 0MATGR 0MATTYPE... 0SALESPERS 0SALESORG... Shared/ Conformed Dimensions Shared/ Conformed Dimensions Extended Star Schemas Extended Star Schemas 0CUSTOMER 0MATERIAL 0AMOUNT InfoCubes InfoCubes with with Local Local Dimensions Dimensions Mart Mart Layer Layer Model Model defined defined by by Business Business Content Content BCT InfoSources Subject Areas 0MATERIAL 0MATGR 0MATTYPE Master 0DOCNO 0SALESDAT 0CUSTOMER 0SALESPERS 0MATERIAL 0AMOUNT Transaction BCT Extractors/ Source Material Type Material Group Sales ORG Customer Material Sales Transaction Sales Person Enterprise Enterprise Model: Model: e.g. e.g. mysap mysap Component Component Object Object Models Models SAP AG 2003, 254, Jürgen Haupt/ 46

24 Warehouse Layer Model EDW InfoObject/ ODS-Object + Insert Timestamp/ Activity Time Slice + Source Warehouse Warehouse Layer Layer Model Model defined defined by by Business Business Content Content ODS-Object If Overwrite: Unique Identifier +Source BCT InfoSources Subject Areas 0MATERIAL 0MATGR 0MATTYPE Master 0DOCNO 0SALESDAT 0CUSTOMER 0SALESPERS 0MATERIAL 0AMOUNT Transaction BCT Extractors/ Source Material Type Material Group Sales ORG Customer Material Sales Transaction Sales Person Enterprise Enterprise Model: Model: e.g. e.g. mysap mysap Component Component Object Object Models Models SAP AG 2003, 254, Jürgen Haupt/ 47 Agenda Evolution of Enterprise Warehousing Basics Controlled Redundancy Architecture Aspects Layer Model Landscape Further Aspects of a Corporate Strategy Integration Application Development Exercise Discussion Summary SAP AG 2003, 254, Jürgen Haupt/ 48

25 Basic Topologies The Ideal Corporate Landscape? Strategic Corporate Implementation Options: Inside-Out Enterprise Warehouse Enterprise Others Spoke Spoke Others Local Local Outside-IN Landscape Global Spoke Local SAP AG 2003, 254, Jürgen Haupt/ 49 Corporate Landscape Influencers Organization Centralized, headquarter oriented companies versus Companies where local units have a large degree of independency Including all intermediate stages Political issues ownership of data Business Companies with a unique business line Companies with divisions totally diverse in business Master data integration status and strategy Awareness of important role of Consistent Information Investment Sponsorship C-Level or other IT strategy - Operative System Landscape Competitive pressure There is no one size fits all landscape! SAP AG 2003, 254, Jürgen Haupt/ 50

26 as Central Enterprise Warehouse (EDW) Enterprise Spoke Spoke Enterprise Warehouse Scenario Enterprise Warehouse: Warehouse layer as single point of truth for the entire corporation SAP AG 2003, 254, Jürgen Haupt/ 51 EDW Patterns Organization is centralized Headquarter or division headquarter or even regional division headquarter oriented companies Often a single line of business Master data integration exist or at least a strategy to achieve it Awareness of the important role of Consistent Information is high i.e. bad experience led to the conclusion that a data warehouse is more than a sexy front-end Sponsorship is high High competitive market SAP AG 2003, 254, Jürgen Haupt/ 52

27 Inside-Out: Central Instance Covers All Enterprise Spoke Spoke Enterprise Warehouse Scenario Inside-Out: Central EDW Instance Covers All External Marts PSA Architected Marts Staging Area EDW integrated non-volatile no flavor granular tactical/ operational like reporting less granular strategic reporting aggregated ODS operational/ near real time reporting granular SAP AG 2003, 254, Jürgen Haupt/ 53 Inside-Out: Central EDW Instance and Spoke Instances Inside-Out: Central EDW Instance as Information HUB Architected Marts Spoke Instances Enterprise Spoke Spoke Enterprise Warehouse Scenario External Marts PSA Staging Area EDW integrated consistent granular PSA ODS operational/ near real time reporting ODS granular operational reporting ODS Architected granular Marts operational reporting granular tactical/ operational like reporting less granular tactical/ operational like reporting aggregation Corporate Mart strategic reporting aggregated SAP AG 2003, 254, Jürgen Haupt/ 54

28 Basic Topologies The Ideal Corporate Landscape? Strategic Corporate Implementation Options: Inside-Out Enterprise Warehouse Enterprise Others Spoke Spoke Others Local Local Outside-IN Landscape Global Spoke Local Simply Simply building building a central central single single data data warehouse warehouse does does not not address addressthe the size size and and complexity complexity of of the the problem problem posed posed by by the the need need for for integrated, integrated, historical historical easily easily accessible accessible data data across across a complex complex global global enterprise. enterprise. W.H. W.H. Inmon Inmon Managing Managing Multiple Multiple Warehouse Warehouse Development Development SAP AG 2003, 254, Jürgen Haupt/ 55 Corporate Warehouse Landscape based on Local and Global Warehouses Global global s Headquarter Divisional local s Division A Division B Regional Region Europe Division A Region Asia Division A Region Americas Division A.. Region Asia Division B Local Sites ERP/ Legacy ERP/ Legacy ERP/ Legacy ERP/ Legacy.. SAP AG 2003, 254, Jürgen Haupt/ 56

29 The Role of a Global without a Central EDW Focus on Headquarter Reporting Headquarter/ Headquarter/ Global Global Focus on Integration and Headquarter Reporting Global as the Corporate Integrator Global Global EDW EDW local local local local others ERP/ Legacy ERP/ Legacy Legacy/ Files ERP/ Legacy ERP/ Legacy Legacy/ Files SAP AG 2003, 254, Jürgen Haupt/ 57 Architected Multiple Landscape Global Global Headquarter Divisional Global Division A Regional Europe Marts Warehouse Staging ODS Americas Marts Warehouse Staging ODS Asia Marts Warehouse Staging ODS virtual Enterprise Staging Warehouse Local R/3-ERP Europe I mysap CRM R/3-ERP Americas I R/3-ERP Americas II R/3-ERP Asia SAP AG 2003, 254, Jürgen Haupt/ 58

30 Agenda Evolution of Enterprise Warehousing Basics Controlled Redundancy Architecture Aspects Layer Model Landscape Further Aspects of a Corporate Strategy Application Development Integration Exercise Discussion Summary SAP AG 2003, 254, Jürgen Haupt/ 59 Architected Multiple Landscape: Template Roll-Out Global Global Headquarter Divisional Global Global Division A template roll-out Regional Europe Marts Warehouse Staging ODS Americas Marts Warehouse Staging ODS Asia Marts Warehouse Staging ODS virtual Enterprise Staging Warehouse Local R/3-ERP Europe I mysap CRM R/3-ERP Americas I R/3-ERP Americas II R/3-ERP Asia R/3 template roll-out SAP AG 2003, 254, Jürgen Haupt/ 60

31 Local Structures source for corporate reporting standardized corporate defined local reporting distilled corporate Local Structures local local defined local reporting SAP AG 2003, 254, Jürgen Haupt/ 61 Content Delivery at the Customer Site Customer Content System (Headquarter) InfoObject 0MATERIAL Subsidiary InfoCube /ABC/IC1 InfoObject /ABC/IO01 import Export (D Version) InfoCube /ABC/IC1 InfoObject /ABC/IO01 InfoCube /ABC/IC1 InfoObject 0MATERIAL InfoObject /ABC/IO01 SAP AG 2003, 254, Jürgen Haupt/ 62

32 Agenda Evolution of Enterprise Warehousing Basics Controlled Redundancy Architecture Aspects Layer Model Landscape Further Aspects of a Corporate Strategy Application Development Integration Exercise Discussion Summary SAP AG 2003, 254, Jürgen Haupt/ 63 Master and Integration A major deliverable of data warehousing is integrated data regardless whether we talk about Architected Marts, ODS or the Warehouse layer itself. 0MATERIAL Master Table 0MATERIAL 0MATTYPE 4711 A 4712 B 4713 A 123 B 124 B Synchronous Integration apply mapping: MATNR: > 4713 MATTYPE: C -> A MATNR MATTYPE MATNR MATTYPE MATNR MATTYPE 4711 A 123 B 4711 C 4712 B 124 B R/3 system 1 - data already integrated R/3 system 2 - data already integrated R/3 system 3 - data not integrated but mapping exist The ideal world that anticipates the source systems either offer already integrated master data or that the master data can be mapped to common coded values during staging. SAP AG 2003, 254, Jürgen Haupt/ 64

33 Master Integration Issues Entity values from source systems are not integrated and cannot be mapped at load time to common coded values The most common reason is the lack of a corporate master data strategy Only a delayed integration is possible i.e. at load time integrated values are not available until after a certain time span Due to mergers and acquisitions new, not harmonized (common coded) sources may appear Best Practice: Discuss the Status and Strategy of Corporate Common Coding Efforts The strategy and the status of corporate master data common coding should be discussed at an early stage because of the huge influence to the information model and thus all scope implementations. Checking InfoObject Integration Status SAP AG 2003, 254, Jürgen Haupt/ 65 InfoObject Common Coded at Source Sites? Integration in possible at load time? 0MATERIAL PARTLY NO 0CUSTOMER NO NO 0MATTYPE NO YES 0COSTCENTER YES NO ACTION... InfoObject Concatenation Key-value Concatenation -Key Concatenated- Separator Attribute Key U U1 AUDI U U2 BMW Build Key U1 Separator Build Key U2 Source-Value AUDI BMW Source-System 1 Source-System 2 SAP AG 2003, 254, Jürgen Haupt/ 66

34 InfoObject Automatic Compounding Automatic Compounding > Source System-ID (0SOURSYSTEM) is Separator -Key Separator: Source-Key Attribute 0SOURSYSTEM U AUDI U BMW Build Key automatically U1 0SOURSYSTEM U2 Source-Value AUDI BMW Source-System 1 Source-System 2 SAP AG 2003, 254, Jürgen Haupt/ 67 and MDM : E.G. Content Integration 0Material... 0GUID S MATERIAL S IS: Material IS: MDM Product ATTR+TEXT S S Sources R/3 Material MDM R/3 R/3 R/3 Load = ID Mapping? Matching Description of a master data object: Identifying Attributes Other application specific data SAP AG 2003, 254, Jürgen Haupt/ 68

35 Agenda Evolution of Enterprise Warehousing Basics Controlled Redundancy Architecture Aspects Layer Model Landscape Further Aspects of a Corporate Strategy Application Development Integration Exercise Discussion Summary SAP AG 2003, 254, Jürgen Haupt/ 69 A Real Life Landscape Example Global MDMS HQ Local SubDiv Sales Europe Asia N-America S-America Sub-Division A R/3 Global Sub-Division B R/3 only Germany Sales Europe R/3 Div R/3 Div R/3... Div R/3 12 systems worldwide Source Systems SAP AG 2003, 254, Jürgen Haupt/ 70

36 Agenda Evolution of Enterprise Warehousing Basics Controlled Redundancy Architecture Aspects Layer Model Landscape Further Aspects of a Corporate Strategy Application Development Integration Exercise Discussion Summary SAP AG 2003, 254, Jürgen Haupt/ 71 Summary Controlled Redundancy is crucial for mid- and longterm success of all () data warehousing activities offers features in all areas to control redundancy But, you need corporate proceedings and corporate guidelines that guarantee consistent usage of these features SAP AG 2003, 254, Jürgen Haupt/ 72

37 Further Information Public Web: bi SAP Customer Services Network: Consulting Contact Roy Wood, VP SAP Consulting Related Workshops/Lectures at SAP TechEd , Aging with mysap Business Intelligence, Lecture Oct. 2, 2003, 10 am, Room L2 SAP AG 2003, 254, Jürgen Haupt/ 73 Questions? Q&A SAP AG 2003, 254, Jürgen Haupt/ 74

38 Feedback Please complete your session evaluation and drop it in the box on your way out. Thank You! The SAP TechEd 03 Basel Team SAP AG 2003, 254, Jürgen Haupt/ 75 Copyright 2003 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, NT, EXCEL, Word, PowerPoint and SQL Server are registered trademarks of Microsoft Corporation. IBM, DB2, DB2 Universal base, OS/2, Parallel Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390, OS/400, iseries, pseries, xseries, zseries, z/os, AFP, Intelligent Miner, WebSphere, Netfinity, Tivoli, Informix and Informix Dynamic Server TM are trademarks of IBM Corporation in USA 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, the Citrix logo, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, MultiWin and other Citrix product names referenced herein are trademarks of Citrix Systems, Inc. HTML, DHTML, XML, XHTML 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. MarketSet and Enterprise Buyer are jointly owned trademarks of SAP AG and Commerce One. SAP, R/3, mysap, mysap.com, xapps, xapp 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 in several other countries all over the world. All other product and service names mentioned are the trademarks of their respective companies. SAP AG 2003, 254, Jürgen Haupt/ 76