LSA/LSA++ is the SAP’s term for (Layered Scalable Architecture) emphasizes SAP’s EDW Best Practice Design. The Goal is to create a structured system that is both Scalable and Flexible. LSA helps ensure that changes can be easily added to the BW structure as the system grows with the Organization. Most BW developers follow this common architecture but always results to higher cost to implement in the Legacy BW (Netweaver). This is mostly because of BW's limitation in functionality & performance. BW4 + HANA Modeling helps us achieve LSA++ in the most cost efficient manner.
There are 2 ways to achieve LSA in BW, through Data Redundancy (Persistent Layers) or Virtualization. Data Redundant LSA through persistent layers requires additional storage requirement. Persistent Layers also results to more complex models, which makes them harder to support when there are issues encountered. Virtualized LSA on the other hand helps achieve LSA Architecture w/o data redundancy but requires more Flexibility from the Application & more Power from the Hardware.
Vistualized LSA though some how available in Legacy BW (Netweaver) systems, could never be fully achieved because of limitation in the BW functionality / objects (ex. Infosets can’t have multiple outer joins) and HW performance issues.Virtualization requires more resources or will result to poor performance. But due to HW Limitation, there’s still a limit on how much resources can be added. Hence BW Legacy systems are mostly Highly Data Redundant LSA Architecture, thus incurring more cost through more storage and maintenance support.
Diagram 1: Below shows your typical Legacy BW Architecture. Complex computations are mostly handled through the ETL processes (Transformation: Source -> Target) through data redundancy. Data is physically stored in PSA, DSO & Cube and as it goes through the ETL Process, Maintenance & Support becomes a major issue.
Traditional Legacy BW (Architecture) – Highly Data Redundant LSA
BW4 offers flexibility on development through the use of new functionalities and objects (Composite Providers, ADSO, etc). Virtualized LSA can be achieved from using BW objects alone.But it may be limited to simple to medium requirements. Some BW objects still works within the application/ABAP layer and doesn't take full advantage of HANA DB's power (ex. Query Formulas, ABAP Routines), thus putting complex requirements into BW objects alone may still result to poor performance. Data Redundancy can still be an option to help solve the performance issue but may incur more cost (due to storage & support)
Complex computation can be created through the HANA Views and take direct advantage of HANA's Processing Power. Creating HANA Views through HANA Modeling enables developers to create complex formulas w/o worrying about performance issues thus keeping the virtualized architecture. Note that creating HANA Views different approach in Data Modeling & a Learning Curve is expected. It also enables another layer of LSA within the HANA DB workspace, which also helps flexibility & scalability.
Diagram 2: Below shows BW4 + HANA Hybrid Architecture. This architecture removes the complexity needed in the ETLs and pushes down the computations to the HANA DB. Cubes for Aggregations are no longer available which eliminates Data redundancies. Only ADSO contains physical data. Less ETL & Data redundancies also simplifies Maintenance & Support.
BW4HANA Ideal Architecture - Highly Virtualized LSA
Note: Creating HANA Views requires a different way of Modeling. Though BW & HANA DB are tightly integrated they still work independently. Developers must be aware on the best practices on how to implement the hybrid approach with BW & HANA. Data Leaks are common issues of HANA Modeling (This is a different topic all together - separate paper).
Maintaining a Highly Virtualized Architecture in BW is the key in achieving Cost Efficiency. The new functionalities / objects in BW4 already provides the much needed flexibility & Power to achieve Highly Virtualized LSA Architecture but still may be limited to Simple / Medium requirements. For highly complex requirements, HANA modeling maybe required to maintain the highly virtualize architecture. If HANA Modeling is not used, Persistent Layers can be created that could be more costly (given that HANA hardware's are more expensive). HANA Views enable developers to push down the complex formula and fully utilize the power of HANA DB w/o the need for data redundancy, Thus maintaining a Highly Virtualized LSA. BW4 + HANA Modeling provides the Flexibility + Power needed to achieve cost efficiency, regardless of the complexity of the requirements.
There are 2 ways to achieve LSA in BW, through Data Redundancy (Persistent Layers) or Virtualization. Data Redundant LSA through persistent layers requires additional storage requirement. Persistent Layers also results to more complex models, which makes them harder to support when there are issues encountered. Virtualized LSA on the other hand helps achieve LSA Architecture w/o data redundancy but requires more Flexibility from the Application & more Power from the Hardware.
Vistualized LSA though some how available in Legacy BW (Netweaver) systems, could never be fully achieved because of limitation in the BW functionality / objects (ex. Infosets can’t have multiple outer joins) and HW performance issues.Virtualization requires more resources or will result to poor performance. But due to HW Limitation, there’s still a limit on how much resources can be added. Hence BW Legacy systems are mostly Highly Data Redundant LSA Architecture, thus incurring more cost through more storage and maintenance support.
Diagram 1: Below shows your typical Legacy BW Architecture. Complex computations are mostly handled through the ETL processes (Transformation: Source -> Target) through data redundancy. Data is physically stored in PSA, DSO & Cube and as it goes through the ETL Process, Maintenance & Support becomes a major issue.
Traditional Legacy BW (Architecture) – Highly Data Redundant LSA
BW4 offers flexibility on development through the use of new functionalities and objects (Composite Providers, ADSO, etc). Virtualized LSA can be achieved from using BW objects alone.But it may be limited to simple to medium requirements. Some BW objects still works within the application/ABAP layer and doesn't take full advantage of HANA DB's power (ex. Query Formulas, ABAP Routines), thus putting complex requirements into BW objects alone may still result to poor performance. Data Redundancy can still be an option to help solve the performance issue but may incur more cost (due to storage & support)
Complex computation can be created through the HANA Views and take direct advantage of HANA's Processing Power. Creating HANA Views through HANA Modeling enables developers to create complex formulas w/o worrying about performance issues thus keeping the virtualized architecture. Note that creating HANA Views different approach in Data Modeling & a Learning Curve is expected. It also enables another layer of LSA within the HANA DB workspace, which also helps flexibility & scalability.
Diagram 2: Below shows BW4 + HANA Hybrid Architecture. This architecture removes the complexity needed in the ETLs and pushes down the computations to the HANA DB. Cubes for Aggregations are no longer available which eliminates Data redundancies. Only ADSO contains physical data. Less ETL & Data redundancies also simplifies Maintenance & Support.
BW4HANA Ideal Architecture - Highly Virtualized LSA
Note: Creating HANA Views requires a different way of Modeling. Though BW & HANA DB are tightly integrated they still work independently. Developers must be aware on the best practices on how to implement the hybrid approach with BW & HANA. Data Leaks are common issues of HANA Modeling (This is a different topic all together - separate paper).
Maintaining a Highly Virtualized Architecture in BW is the key in achieving Cost Efficiency. The new functionalities / objects in BW4 already provides the much needed flexibility & Power to achieve Highly Virtualized LSA Architecture but still may be limited to Simple / Medium requirements. For highly complex requirements, HANA modeling maybe required to maintain the highly virtualize architecture. If HANA Modeling is not used, Persistent Layers can be created that could be more costly (given that HANA hardware's are more expensive). HANA Views enable developers to push down the complex formula and fully utilize the power of HANA DB w/o the need for data redundancy, Thus maintaining a Highly Virtualized LSA. BW4 + HANA Modeling provides the Flexibility + Power needed to achieve cost efficiency, regardless of the complexity of the requirements.
- SAP Managed Tags:
2 Comments
