Just in case you missed the first parts, here you can find:
- Part 1 – which discusses the set of different customer landscapes and a non-SAP OLTP landscape
- Part 2 – which discusses a customer with SAP ERP (not ERP on HANA)
- Part 3 – which discusses a customer with SAP ERP on SAP HANA
So this time let’s discuss the options for a customer in landscape #4, so a customer which has a heterogeneous landscape deployed with some parts being SAP and some parts non-SAP.
Figure 1: Current landscape #4
Remember – the goal of this blog is to discuss, how a customer with such a landscape could now leverage SAP HANA, but …
…our customer already has SAP HANA.
As shown in Figure 1, our customer uses SAP ERP on SAP HANA and a non-SAP OLTP environment and there might even be other data sources out there.
Lets put this into an actual scenario, so lets work with the assumption that:
- Our customer uses the SAP BusinessSuite to cover the Finance aspect of his business
- Our customer uses a non-SAP ERP system – like Oracle, Salesforce, … – for the Sales aspect of his business
- Our customer uses a relational data base for some credit history and some credit rating information about his customers
Our requirement now is to provide our VP of sales to provide an answer to the question if there are opportunities in the sales pipeline where our VP of sales should consider giving a bigger discount to the customer to close the deal in the last days of the quarter.
Now that means we need:
- the data from the SAP BusinessSuite for the open invoices and open orders
- the data from the non-SAP OLTP system for the current pipeline
- the data from the database for credit history and credit ranking
The first option to solve our problem could be to create a Data Mart and to combine the sales data coming from the non-SAP OLTP environment combined with the credit history and credit ranking information stored in the 3rd party database.
With SAP BusinessSuite on SAP HANA we could also create a agile data mart (virtual or physical) inside of SAP HANA giving us access to the Finance data.
…but that does not really solve our problem, we just reduced the number of data sources from three (SAP BusinessSuite on SAP HANA, 3rd party OLTP, 3rd party data source) to two data source – but no data federation (see Figure 2).
Figure 3 Federation in Semantic Layer
Our goal is to present a combined set of information – Finance, Sales, Credit History – , so we need to combine the information in one of the software layers we have in our landscape. Figure 3 shows the first option we are using by leveraging the SAP BusinessObjects BI suite and the data federation capabilities of the semantic layer.
We can leverage the semantic layer of the SAP BusinessObjects BI suite and create a so called multi-source Universe and in that way we would be able to present a combination of the data.
Advantages of the approach (Figure 3):
- Data can be combined before “hitting” the reporting layer so that the business user sees one combined set of data
Disadvantages of the approach (Figure 3):
- Not all of the BI client tools are able to leverage a Universe as data source, so we would not be able to use Analysis, edition for Microsoft Office, Analysis, edition for OLAP, Design Studio
Figure 4 Consolidate in SAP HANA
In Figure 4 we are looking at an alternative for our problem. The customer is using SAP BusinessSuite on SAP HANA, so we could also leverage the capabilities of SAP HANA to solve our problem. We would like to present one set of information to our business users, so for now in SAP HANA that would mean that we would like to use one SAP HANA model that has access to all the required information.
We already looked at the option of creating a virtual or physical data mart on top of SAP ERP on SAP HANA in Part 3 of this series, so I won’t repeat this here.
In addition to the Finance data from the SAP BusinessSuite we would then load the data from the non-SAP OLTP and the 3rd party data source into the SAP HANA system (see Figure 4).
Now with all the data available in SAP HANA we are able to either create a complete new SAP HANA model, but we could also leverage existing models from SAP HANA Live and extend them to combine the SAP BusinessSuite data with the information we loaded into SAP HANA for the sales and credit information.
Advantages of the approach (Figure 4):
- All data is available in a single place, which allows to create one set of security, one set of data models, …
Disadvantages of the approach (Figure 4):
- We need to extract the data from the source and load it into SAP HANA, which is more effort and not really “real time” anymore
Figure 5 Federation with SAP HANA
So looking at Figure 4 we are able to solve our problem and we are able to deliver the required information to our business, so we could stop here, but as I mentioned in the disadvantages, this also means that we need to extract the information from the source and load it into SAP HANA…
…. and that might not always be what our customers are looking for.
Before I continue now with Figure 5, please be aware that the next paragraph refers to future capabilities that are not available yet and the usual disclaimer applies here.
Figure 5 shows something that is being worked on right now, where SAP HANA allows you to federate data that is “inside” of SAP HANA with data “outside” of SAP HANA – so basically like a virtual data model inside of SAP HANA.
So how does our customer in landscape #4 benefit from items, such as SAP HANA Live, and SAP BusinessSuite on SAP HANA :
Right now our customer is able to leverage SAP HANA as an agile data modeling environment and can quickly create a combination of data from SAP ERP and non-SAP data. Yes – given right now the data from the non-SAP environment needs to be loaded into SAP HANA as well, but as shown in Figure 5 in future that will not always be a requirement anymore with the upcoming federation capabilities in SAP HANA.
If you think this material is helpful, please share it further and rate / like the blog post.