SAP BW Architecture
In large projects as well as small implementations, it is always be required of the Developer to follow certain standards.
The client will share his/her own set of standards to the developer before the start of the project.
However there are certain set of generic standards to be kept in mind as a good developer.
Whenever your design needs deviating from the said standards, you need to
take approval from the Global BI leads/Architect on the client side.
Before going through the guidelines, you need to know the objectives of the BW System Architecture-
- Avoiding redundant data, data flows, and development
- Consistent data – single version of truth
- The development should be scalable in future if required
- Extraction of source data only once.
- Parallel data load and reporting wherever possible
- Reusing of available structures wherever possible
- Using master data in reports
- Avoid any record creation in SAP BW system for easy tracking with source data
- Automated data management and error notification
All the data modeling and design activities occurring during the blueprint and realization phase must keep these objectives in mind.
Below can be some generic guidelines to follow-
- The data flow must follow the same layered architecture as existing in the system e.g. Acquisition layer (Write Optimized DSO) to Integration Layer (Standard DSO) to Reporting Layer (Cubes)
- Data store configuration standards – Generate SIDs only if required, uncheck option ‘Activate data automatically’, always check the option ‘Set Quality Status to OK automatically’ unless if required otherwise.
- General Infocube configuration standards – Never automatically compress data, delete or rebuild indexes or automatically roll up new data to aggregates. All these activities should be explicitly performed in a process chain
- Acquisition layer DSO – use only if required as PSA will serve the purpose
- Base of all queries should be multiprovider
More on this to be included in next part…