SAP BW in the age of Hana

SAP BW was basically developed to store data from various SAP and non-SAP systems in such a way as to enable high-performance access for data analyses across departmental boundaries.

History

In its time, the star schema recommended itself to handle such amounts of data. Thus, databases were initially set as analytical (OLAP) or transactional (OLTP) to allow efficient data access. However, it is no more fun to make an analytical access in an OLTP system than it is to make a transactional access in an OLAP system. Column-oriented database management systems (DBMS) are better suited for analytical accesses than row-oriented DBMS. To improve analytical access to SAP BW, a column-oriented DBMS was therefore delivered with SAP BW Accelerator.

U-turn

With a Hana database, data accesses become performant for both analytical and transactional accesses due to in-memory data storage. Setting the DB for OLAP or OLTP is no longer necessary.

Since statistically much more data is accessed read than write, data in Hana is stored in column orientation by default. An additional row orientation is recommended for tables that are accessed in write mode.

Since the Hana DB is SAP's preferred DB for the ERP applications, all operational data can now also be used immediately for analyses. So what is the need for SAP BW?

You could do without SAP BW the moment you have all - company-wide all - data including history in this one Hana DB. Technically, such a scenario is feasible. But unfortunately, IT is not just about technology.

Requirements for a central system

History: Since real-time data is primarily suitable for operational reporting, it is necessary to determine which data should be historized in the Hana DB for strategic statements.

Nearline storage can be used so that the storage requirement does not increase unnecessarily, resulting in additional storage and thus license costs. Unfortunately, performance for strategic reports is impaired in the process.

Data intersection and enrichment: All departments that do not yet have their data in this Hana DB must be docked in order to make their data available for company-wide, cross-discipline access. For this purpose, cross-discipline data modeling and also data enrichment must subsequently take place.

Data quality and timeliness: The data provided must form a single point of truth throughout the company. To this end, it must be precisely agreed which data is to be calculated at which point in time, and how it is to be made available in a restricted form. Up-to-date in this context does not necessarily mean in real time.

Authorizations: Imagine you have overall responsibility of HR data in the company and in this role you are also responsible for the SAP HR system.

You are now supposed to store all employee data together with SAP ERP on one system. Will you sleep soundly at night? Even today, when deciding on an SAP BW HR system, people prefer to have their own system rather than going to the existing central BW system where different departments keep their data.

Even if the authorization system can be set up accordingly. This is a very sensitive issue of data sovereignty and thus data protection. The following still applies here: the more isolated the system, the better.

Application service management: A central system - of whatever type - must also be managed. Which department is prepared to provide this central instance for the other departments and the Executive Board?

This involves topics such as installation, upgrade, ongoing operation, licenses, projects, change management, emergency corrections, Sarbanes-Oxley compliance, self services and much more. In short, the entire application service management must be operated for the system.

Costs: The operational running of such a central system is therefore associated with effort and thus with costs, not least because of the manpower required. These costs must be distributed, ideally by the originator.

For strategic reporting in a Hana DB, the first two points regarding history and data intersection must be clarified.

Reporting with SAP BW

By using a Hana DB under an SAP BW system, not only have the activations of data pots and response times of reports become faster, but it is also possible to integrate real-time data from a conventional operational SAP system (ERP, CRM, etc.) with SAP BW reporting.

For this purpose, the data that the management or the business department needs is replicated to the Hana of SAP BW using the SAP Landscape Transformer (SLT).

From the respective Hana schema, the replicated tables can now be displayed in the form of information views (analytical or calculation views) directly or still provided with additional logic in SAP BW using virtual info providers or incorporated into multi-providers and thus intersected with existing reports.

The content and analysis permissions used in the SAP BW environment can be used in the same way for the analysis of such real-time data.

This is an advantage not to be underestimated compared to direct data analysis on the Hana table, which in turn requires its own authorization to manage.

SAP BW conversion

To prepare the existing SAP BW landscape for the future, the following investment steps are necessary:

1. Hana-certified hardware.

2. Hana licenses - in addition to the OEM for pure SAP BW use, also the Hana Modeller.

3. migration to SAP BW on Hana.

If S/4 is already being considered, then investment step 1 must also be taken - scaled slightly differently. So if an IT conversion is pending in terms of hardware anyway, such a step could already be considered.

With a BW on Hana, there is the possibility to already use the new features and functionalities of Hana and to gain experience with the real-time database.

SAP BW now also offers simpler modeling options (keywords ADSO, Composite Provider), which - especially with Eclipse-based forward modeling - significantly simplify the use of SAP BW.

Above all, the use of composite providers in connection with department-specific workspaces allows a self-service BI approach with which departments can enhance their reports with their own assignments and then execute them with their existing authorizations.

Even though such enhancements are likely to be performed only by a PowerUser, it gives the business a flexibility that complies with IT governance guidelines. The workspace itself is provided by IT.

Future use of SAP BW

After the initial migration of the existing SAP BW content, it is possible to build new BW content taking into account the layer model (keyword LSA++ etc.) in such a way that reporting is used for both operational and strategic purposes.

This represents an immense advantage for the business departments. If additional data is required, IT can simply add the necessary tables/views in the replication via SLT. Complex real-time data acquisition extractors (RDA) are no longer required and no longer need to be maintained.

It is also conceivable to use the BW functionality only for historization and data enrichment and in the end to build the reports directly from Hana without using the OLAP functionality.

Since currently the BEx query still uses the Surrogate ID (SID), about 80 percent of the total report runtime is consumed for the initial creation and mapping of the SID. Thus, with direct Hana usage, reports would be processed faster overall.

At the end of the currently planned roadmap is an S/4 that not only simplifies all known SAP models, but also includes BW functionality, among other things.

If it turns out that the central BW system could be absorbed into such a central S/4 - not only from a technical point of view, but above all from the point of view of IT governance - all the investments made so far will not have been in vain.

On the contrary, valuable experience was gained in dealing with a complex Hana landscape, which will help to make the right decision for or against a central data warehouse.