Will SAP HANA replace SAP BI?

My first question when I into the diagram below is will HANA be able to replace the SAP BI (backend)? In my opinion, after going though some articles by Thomas Zurek , I do have the impression that the future data modelling and transformation can take place in the database-level modelling tool .In one of  the talk on HANA by Daniel Rutschmann, he answered the question by saying that BW will not be replaced as there is a need of having a datawarehouse system for harmonization and consolidation purposes, eg. to consolidate data from more than one ERP system in a company (But bear in mind, any multinational company out there will surely put aside a big budget to cut down cost of operation and to standardize the process through convergence of all the ERP systems into one single instance). John Appleby says 'No', with one of the reason being the business content (But it won't be a surprise that SAP is starting to look at building HANA around the business suite, just post data directly in Memory!).

This is an interesting forum that discuss some of the confusion and in this clip, you can see how well SAP BO integrate directly with SAP HANA. This is also an interesting technical step by step document that demonstrate how a variable is applied in HANA modelling.

SAP HANA Overview and Roadmap 

Five Factors for a Successful SAP HANA Implementation

Five Factors for a Successful SAP HANA Implementation

The ability to manage "big data" in real time has revolutionized the way businesses analyze and manage performance. The revolution, though, lies in more than just quick data processing – instead, new database technology from SAP radically changes how and when businesses use the information they receive, regardless of its volume and complexity.

With SAP® NetWeaver® Business Warehouse (BW) running on SAP HANA, SAP has changed how organizations think about data management technologies, construct applications, and consume the results. Businesses that adopt new technology can sharpen their competitive edge by dramatically accelerating the speed of not only data queries but fundamental business processes.

You can benefit from this new database model in one of two ways:
1. Upgrade your existing installation to deploy SAP NetWeaver BW powered by SAP HANA, ending up with a single instance of SAP NetWeaver Data Warehouse
2. Install a new instance of SAP NetWeaver BW 7.3, running a parallel landscape
(To find out which implementation option is right for you, see this article by Tom Kurtz.)

Whatever option you choose, five major factors affect the success of your implementation:

1. Up-front assessment : Before you begin, it helps to understand the requirements and scope of a SAP HANA implementation. Assess your overall architecture, database platform, business applications, and current SAP NetWeaver BW footprint. You also need a clear understanding of the technical elements of your implementation. Do you need to upgrade to SAP NetWeaver BW 7.3? If so, which version will you be upgrading from – 7.x or 3.5? What about requirements such as authorization migration and Unicode migration?

Before SAP HANA, SAP BW consultants routinely followed a Layered, Scalable Architecture (LSA) methodology for building and structuring the business warehouse. The LSA methodology helped create a standardized approach that organized data by functional area, geography, and other key dimensions. With SAP HANA, the new LSA++ methodology takes advantage of in-memory capabilities to deliver simplified data models, increasing flexibility and optimizing enterprise performance management. Using LSA++, which is a fundamentally different approach to data modeling, requires careful upfront planning to optimize your SAP NetWeaver BW solution powered by SAP HANA.

Performing an upfront assessment will align the HANA platform with the strategic solution landscape. Accurate scoping and a clearly defined architecture and design will help you stay on schedule, meet financial budgets, and identify necessary skills and personnel.


2. Data quality and sizing: With a SAP NetWeaver BW on SAP HANA implementation, as with any data solution, the results are only as good as the data you start with. Take the time to analyze existing data, clearly define which data should be migrated, and specify the volume of data to be stored, and you'll be more likely to accurately size the required HANA hardware – and limit unexpected changes during the implementation.

Also consider the data to be stored in the SAP HANA system. You must understand both the frequency of data loads and which elements and volumes need to be loaded. SAP BW Data Store Object (DSO) improvements provide significant data load performance benefits and directly take advantage of SAP HANA's column-based data processing. However to ensure optimal performance and a robust and scalable solution, you'll want to clearly architect the data elements and points of integration.

Data management must be an ongoing consideration, and your final data optimization exercise should be performed after migration. To take full advantage of SAP HANA in-memory capabilities, deploy SAP HANA as the database for the SAP NetWeaver BW instance following the principles for LSA++.

3. Related project components : An SAP NetWeaver BW on HANA migration is likely to interact with a number of other systems and applications; consider how the interplay among them will affect the project. For example, SAP BusinessObjects™ Business Intelligence (BI) solutions are often used for SAP HANA solution output. Ensure best practices for business intelligence implementation, and ask the project team to consider data output formats.

Also consider how data gets into SAP HANA. It may seem straightforward to load SAP ERP data into SAP HANA, but what about the ETL approach for data from non-SAP sources? Mismanaged data can lead to project escalations and delays.

Increasingly SAP NetWeaver BW on SAP HANA projects are not just for reporting and analytics purposes. SAP solutions are also taking advantage of SAP NetWeaver BW on SAP HANA as a platform. For example, SAP Business Planning and Consolidation (BPC), SAP Business Warehouse Integrated Planning (BW-IP), and SAP Strategic Enterprise Management (SEM) products all have the capability to take direct advantage of SAP HANA in-memory and high performance capabilities. If your project contains one of these solutions, you should ensure it includes the specific, related SAP HANA functionality.


4. Project management : There is no single timeline for an SAP HANA project. Each project is different; each has distinctive contributing factors, characteristics, and objectives. Use a standard project methodology, such as the SAP ASAP implementation methodology, to ensure that a project addresses all critical activities, phases, and deliverables necessary for success. The SAP ASAP methodology has been updated to incorporate SAP HANA activities required for a standard in-memory project. Accelerators, best practices, and implementation tools have also been updated or developed to shorten project timelines and reduce risk. Methodology, timelines, and key activities will vary based on your technical landscape, expectations for in-memory functionality, and use case.

Of course, with complex SAP HANA projects the need for robust project management only increases. Strong project management can provide visibility while ensuring the best possible outcome for each project.


5. Skills and experience : SAP HANA is a new technology – the success of any implementation depends in large part on your ability to find experts with needed skills. Critical resources will also vary depending on how you leverage the SAP HANA in-memory solution and the use case you choose.

Consultants at SAP Services HANA Center of Excellence (COE) have in-depth skills and knowledge that come from having performed a multitude of complex implementations. Based on extensive experience with numerous successful SAP NetWeaver BW on HANA implementations, the SAP Services HANA COE can advise you of the best approach and alert you to common pitfalls. With a large pool of certified talent, SAP Services HANA COE can help ensure the success of your SAP HANA implementation while speeding timelines and managing the return on investment.


Learn More
Let SAP HANA Services help you optimize your SAP NetWeaver BW on SAP HANA implementation. We can help with assessment, data sizing, and quality issues; solution considerations; project management; and more. Whether you need initial advisory design or a complete implementation, SAP's expert planning and installation services can help you streamline and accelerate your migration plan for maximum benefit.

via Content in SCN 

The OLAP Compiler in BW-on-HANA

The OLAP Compiler in BWonHANA

This blog is about a functionality that I consider as one of the crown jewel of BW-on-HANA. The approach has evolved over many years; early discussions started around the time when the BW accelerator (BWA) got initiated (around 2003, project Euclid) and were ignited by the fact that BWA (and its sequel HANA) provided a layer for processing multiple and sequenced calculations close to the data layer. This has not been possible before as we did not have control over the data processing layer of the standard RDBMS underneath the classic BW. The latter is restrained by SQL as the standard API. This blog – as a side effect – will show in what way SQL limits analytic processing, especially fast analytic processing. Also, it will become apparent that BW's OLAP has converted into a kind of sophisticated compiler for HANA's calculation engine. That combination will be hard to beat when you go beyond demo, "hello world style", single table group-by and other simple analytic examples. 

An Example

Let's look at an example which looks as if it was of "hello world style" but which quickly reveals some challenges. In figure 1, a standard OLAP query result is displayed. 

It shows the quantities of sold items per product and country. In addition, the number of distinct customers who bought those products can be seen. Finally, the quantity relative to the overall number of sold products in a country are presented as percentages.

Figure 1: Example of a result of an OLAP query

Some Challenges in the Example

Now when you carefully look at the example of figure 1 then you see some of the challenges: 

The numbers of distinct customers do not sum up. There are 5 distinct customers buying pencils and 3 buying paper, both in Germany (DE), but only 6 – and not 5+3=8 – buying products in DE. There must be 2 customers that have bought both, pencils and paper. In processing terms this means that the subtotal (e.g. by country) cannot be calculated out of the preceeding aggregation level (e.g. by country and product) but needs to be calculated from the lowest granularity (i.e. by country, product, customer). The calculated key figure quantity per country refers to the key figure quantity and sets the latter's values in relation to its subtotals. This means that the quantity key figure and its subtotals has to be calculated prior to calculating key figure quantity per country. This means there is an order of processing imposed by mathematics.

Figure 2: Challenges in the example

What you can do with SQL

In order to calculate the result of figure 1, classic BW (or SQL-based OLAP tools in general) would issue a SQL statement that retrieves a rows similar to the one shown in figure 3. That row constitutes the base set of data from which the result of figure 1 can be calculated. It is not the final result yet but from that data it is possible to calculate the final result as indicated in figure 1. Don't get fooled by the small amount of data shown in figure 3, As you can see, it is necessary to get the details on the customers in order to calculate the distinct customers per group-by level. In real world scenarios – just imagine retailers, mobile phone or utility companies – the customer dimension can be huge, i.e. holding millions of entries. Consequently and caused by real-world combination, the result of the SQL query in figure 3 is likely to be huge in such cases. That "sub-result" needs to be further processed, traditionally in an application server, e.g. BW's ABAP server or the Web-intelligence server. This implies that huge amounts of data have to be transported from the DB server to such an application server or a client tool. 

Figure 3: Rowset retrieved by a SQL query to calculate result of figure 1

By the way: BWA 7.0 accelerated exactly this part of OLAP query processing, i.e. the basic data query. Subsequent processing on top has still been executed in the application server. This is not a big issue as long as the OLAP query is dominated by the SQL processing. However, it comes short - as in this example - when the result of the basic SQL query gets huge and requires significant data transport from the DB to the application server and then significant data traversals to calculate the final result. 

The "OLAP Calculation Graph"

Now based on the result shown in figure 3 there is a natural sequence of how to calculate the various formulas (behind the calculated key figures) and the various group aggregations (i.e. the subtotals and totals). 

Many of those subsequent calculations can be considered as SQL queries on top of figure 3's result. Figure 4 shows the resulting dependency graph: LQ is the label for the query of figure 3; L1, L2, ..., L6 are "queries" or calculations on top. BW's OLAP compiler basically derives that graph and sends it down to HANA's optimizer (using a proprietary interface), HANA optimizes and processes that graph and sends back the result. Please beware that the result is not a rowset, at least not in the normal sense. It is heterogeneous sets of rows that are returned and that need to go into the appropriate result line in figure 1. In short: the compiler creates a graph to be sent to HANA and then there is a postprocessing step that receives the result and converts it to the desired result set of the OLAP query (i.e. a cellset as in fig. 1). 

Figure 4: Graph derived for processing the final result (as in fig. 1) from the data in fig. 3

Concluding Remarks

Author think there is a few fundamental things that become apparent even by looking at the simple example discussed in this blog: Even though individual processing steps can be expressed via SQL, it is in the end a well defined sequence of processing steps that yield the result.

Accelerating the individual steps helps but falls short. For example, an OLAP client tool can derive an OLAP graph like the one in fig. 4. One alternative is that it issues for each node in that graph a SQL or SQL-like query. To avoid the data transport, it can materialize intermediate results. However, this constitutes an overhead. As a second alternative (the one frequently met in practice), it is possible to issue only the basic query - labeled "LQ" in fig. 4 - and transport a potentially huge result set over the network to the client in order to calculate the rest on the client level. This is the traditional approach which obviously also suffers from the transportation overhead.

BW-on-HANA resolves those issues by providing a powerful option to define an OLAP query - i.e. the BEx query - this is a precondition to allow all of that in the first place, sending down the entire processing graph to HANA and allowing HANA to optimize and pipeline the individual processing steps, and

having the capability to assemble the partial results of the processing steps into the final (OLAP) result.

 

via Content in SCN