SAP NetWeaver BW: bw layered Scalable Architecture (LSA) Building Blocks

Welcome to my second blog about the BW layered Scalable Architecture (LSA) the reference architecture for large scale BW dwhs/edws. in this blog we will have a look at the LSA building blocks, the cornerstones of your future BW architecture.

What we discussed so far

 

In my blog 'sap NetWeaver BW: What is the BW layered Scalable Architecture (LSA) all about? 'We highlighted
That the design of large scale BW data warehouses (edws) shocould follow architecture principles like we can observe them constructing large buildings: standardized, scalable, no squiggles, efficient usage of materials, earth quake save.

 

 

 

Large scale BW data warehouses (edws) shocould be designed like the building shown in this picture-highly standardized. The BW layered Scalable Architecture (LSA) describes these design principles.

With buildings we have a standardized supporting structure (pillars & ceilings). The lsa cils these architecture cornerstones'Building blocks'. 

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.
  

 

The LSA has the intention to provide rapid value without losing the complete picture. delivering rapid value means that already after a short brainstorming and investigation phase a first but sustainable draft of the new customer LSA is available and new
Bi projects and/or migration projects can start implementing on it (S. My blog 'sap NetWeaver BW: What is the BW
Layered Scalable Architecture (LSA) all about? ').

A rapid roll-out of your customer LSA is achieved dividing the building blocks into two categories (S. Picture)

• Landmark Building Blocks and
• Assistant building blocks

Landmark Building BlocksDeal with architecture areas that need fundamental decisions before doing implementations-they play the same role like the supporting structures (pillars & ceilings) of buildings.

The reference LSA helps you making initial landmark building blocks definitions without closing the door for future expansions and refinements of your architecture framework.

Assistant building blocksDeal with architecture areas that are normally less prior with respect to the point in time you shoshould decide and roll out into ate standards.

When and whether we have to decide on Assistant building blocks depends very much on customer conditions.

In general making decisions on Assistant building blocks means also deciding on investment what takes time. taking this time into consideration, it is nevertheless important to start brainstorming on these architecture topics at an early point in time despite
The fact that we in general do not need guidelines on these topics to get started.

 

Let's have a look at the LSA landmark building blocks.

 

Lsa landmark building blocks

 

Your future bw edw needs a stable, flexible framework. This framework is defined by the LSA landmark building blocks: the data layers, the data domains and the date Model

 

• The data layers

Standardize the management and definition of persistent data containers (Data Store objects (DSOs) and infocubes) from extraction to delivery and how data are transferred from one layer to the next one. the layers apply throughout the entire bw edw for all
Data flows.

 

• The data domains

Section the data in your data warehouse by a stable, customer-defined criterion. A geographical criterion often fits. A simple one for a global bw edw cocould be 'continent '. then the domains defined by continent result in a sectioning of Data such that
Instance Asian sales orders and European ones are not hosted in the same data container (DSO, infocube) but in particle ones.

 

 

For transparency reasons I recommend to section all (transactional) data in the same way applying domains throughout the entire BW EDW.

 

 

• The BW Data Model

Is defined by the BW infoobjects. A proper data model strategy is important to keep your architecture flexible and consistent.

You can think of infoobjects as a BW-wide shell that forms the basis

• § Defining consistent infoproviders (Data Store objects (DSOs), infocubes) implements SS your layer, domain grid
• § Storing master data
• § Enabling cross infoprovider reporting via BW multiprovider being the 'shared dimension' of the data marts

The data model becomes all the more important the less integrated the master data are at customer side. for large scale BW edws we typically have to provide cross reporting for each ate needs and for local sites reporting on tactical or even operational
Level. That means that our data model strategy must take into account to host local not-harmonized master data and integrated primary ate master data.

 

This is nothing new. the BW-experienced reader knows and a lot of MERs use the BW features to deal with this challenge (infoobject compounding or concatenation) but you have to remember it and to decide before you start implementing.

 

Lsa assistant building blocks

 

Now let's have a short look at the assistant building blocks:

 

• ETL (extraction, transformation, load)

Do you have CT 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 don't 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 don't care. may be
Later on.

 

• Landscape 

Often forced CED 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. below 'store ').

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)

But these kinds of landscape requirements do not prevent a rapid implementation start based on initial customer guidelines on landmark building blocks.

I intend to offer a dedicated blog talking on 'lsa and Bi/dwh landscape '.

 

• Storage

Yes, this sounds a little bit abstract. what I mean with 'store' is the following: 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 shoshould rethink this strategy ):

Near line storage (NLS) & Data Life Cycle Management-In all dwhs there is a high amount of data, which are hosted 'just in case 'e.g. for recovery purposes. in bw edw we recommend CT even more rarely used data (complete history, 'support
Unknown 'concept ). rarely used data shocould be hosted by a near line storage (NLS) tool. NLS tools compress your data offering space limit ction up 95% (e.g. sand) without destroying your service level agreements (SLAs ). the nice thing is: bw transparently supports
NLS, allowing you to move rarely used data to cheaper storage. The LSA standardizes the usage of NLS thus the life cycle management of your data processing SS your bw edw.

You shoshould keep in your mind:

-NLS keeps large BW edws manageable and reduces TCO.

-NLS must be part of the architecture. This is the more true the larger the expected data volume.

But NLS does not need to be in place at the very beginning. Introducing NLS means of course that you first have to invest.

I will discuss NLS and LSA in a subsequent blog.

BW accelerator (BWA) & in memory technology-You probably know from your own experience that RDBMS are week when it comes to random access as we have it with ad hoc reporting-No index or aggregate means bad response time. Also with standard
Reporting we need a bunch of aggregates to keep our service levels what means high costs.

TheBW accelerator (BWA)Resolves these issues and must be part of the overall architecture.

 

• Ownership/Organization

Designing, implementing and operating a bw edw need strong governance. A Bi competency Center (BICC) shocould be established if not existing yet. You can find a lot of postings in the net about biccs.

 

• Development Concept/Bi deployment

Most sap MERs follow two targets establishinga bw edw: enabling integrated cross organizational reporting & Analytics and standardizing local (organizational) reporting & Analytics. Both Directions ctions are normally addressed creating a central developed
Offering of Bi applications based on the customer LSA (Central template ).

Such a central maintained Bi template solution has obvious advantages but there are also limitations. as it delivers a standard it can and will never cover all specific local or personal Bi needs. so the question must be discussed 'how to make bi agile'
Without corrupting the LSA bw/EDW achievements? There are unknown, except areas joining the game if we want to define a customer strategy for this topic:

-Organization-Bi competency Center (Bi CC)

-Processes-defining the scope of the central bi Template

-Landscape & BW Technology

Federated ubuntures (e.g. bw EDW & Newton appliances)

Federated queries

Meta data management and deployment

-.....

 

Making Bi agile is crucial for the overall success of your bi strategy.

But independent of this fact establishing a solid foundation for your shortate Bi strategy-a lsa founded bw edw-is a necessary condition for this overall success.

Lsa lessons learned-wrap up

The sun is going down and it's time for a short wrap up. the sum of topics related to bw edw architecture seems overwhelming and indeed it is and each customer is unique and puts new architecture relevant topics on the table.

The most important advice I can give you is: focus on the important things first like the landmark building blocks. follow always the 80: 20 Rule Meaning don't lose yourself or allow others to direct you into details and exceptions at an early stage.

And: standardize, standardize, standardize

More details in my teched 2009 presentation:The layered Scalable Architecture for SAP NetWeaver bw on a shortate scale'
-Lecture bi302

May be a more general presentation from sapskills 2008 is also of value for you:

SAP NetWeaver bi: Data Infrastructure und bi-maturity-data marts, data warehouses (dwh), enterprise data warehouses (EDW), appliances

(Don't become confused only the first two slides are in German :-))

Ref address: http://scn.sap.com/people/juergen.haupt/blog/2009/05/12/sap-netweaver-bw-bw-layered-scalable-architecture-lsa-building-blocks