If you’ve been following my blog series, you should by now understand how SAP Lumira Server uses SAP HANA as an execution platform. If you haven’t, now’s a good time to read these entries:
The most common question from existing SAP BI 4 customers is, “Why do I need a HANA system just to share a Lumira Storyboard with another BI user?” Hopefully you should have a good idea of why that is, but let’s dig a little deeper.
From my previous article, you now know that everything a user sees in Lumira is dynamically generated based on:
- The storyboard definition
- The values in the dataset at the time of execution
- Any selections or navigation the user has done up to this time.
Now let’s take a look at how the SAP BI 4 integration actually works (Note: this functionality is in Ramp-Up right now and is not released at time of this writing).
The diagram below is a drastic oversimplification of the BI Suite architecture but shows the additional code that performs the magic of integration in black:
You will notice there is still a Lumira Server on HANA system in the deployment.
The integration piece effectively adds another service on the BI Platform that bridges Lumira Desktop with the Lumira Server on HANA system so that user workflows are consistent with the way they already interact with the BI 4 system. This means users can use their existing credentials for authentication, can publish to BI folders they already have access to, and can view Lumira content integrated into BI Launchpad alongside their existing Crystal, WEBI, or other BI content.
The Magic Behind The Curtain
If it sounds like the goal is to shield the fact there is a Lumira Server in the background, you are right. BI users really don’t care how many systems are in the background, as long as they only have to deal with one. Making it appear that SAP Lumira is just part of the platform makes it easier for users to adopt while providing some impossible-to-beat benefits like being able to leverage existing Universe connections, single sign on, and single source content management.
IT people definitely care how many systems there are because they want to reduce TCO, so the BI4 integration also brings Lumira administration to the Central Management Console (CMC). Lumira Datasets are represented in their own section and refreshes can be scheduled (if its source is based on a Universe connection), rights can be applied, and even desktop permissions can be modified, all from the CMC interface they already use.
It is critical to note that Lumira storyboards and datasets are represented in the BI Platform (as InfoObjects actually), but are still physically stored in the SAP HANA system just as in a standalone Lumira Server deployment. The BI Platform takes care of all content management responsibilities, so when a user deletes a storyboard from BI Launchpad, it is removed from the system and the BOE InfoObject representing the storyboard is also deleted. When an administrator schedules a dataset refresh from the CMC, the platform accesses the Universe source and rewrites the updated dataset into the HANA system.
Why Can’t We Just Put Lumira Server on The BI Platform?
Invariably one of the questions that always comes up is that if we took such painstaking effort to integrate Lumira storyboards and datasets into the BI Suite and even made it seamless for the BI administrator, why would we just not put the whole Lumira Server on the BI platform to begin with?
As you likely read from this blog article, Lumira Server uses HANA’s calculation engines in a way that is truly unique. Lumira Desktop does not have these calculation engines and therefore relies on emulation of this functionality. Today, to put that functionality on the BIP itself would mean a significant load on the BI system to the point where the solution would be unacceptable even for the smallest deployments.
What we are working on though is to integrate some enabling in-memory technologies into the BI Platform to handle those small-footprint cases. This will mean that an option that doesn’t require an SAP HANA appliance would be available while still preserving the ability to scale up to using the HANA calculation engine capabilities when the needs of the business grow.
So, Should I Wait Instead of Deploying SAP Lumira on HANA?
Probably not – the goal of bringing enabling in-memory technologies to the BI Suite is not to replace SAP HANA – It is not technically feasible to replace all of HANA’s functionality in a footprint that would be any smaller than what HANA itself requires (if it was, wouldn’t we just make that HANA? 😛 ). However we recognize that many customers have smaller use cases where the ability to work on large or complex datasets is not a requirement and the steps involved in deploying a HANA system can be an obstacle to getting SAP Lumira adopted in their company quickly.
One thing we should not forget in all of this talk about SAP HANA being a challenge for some customers – A “Limited Runtime License” of HANA is already included in certain “BI Suite” licenses right now. This allows you to deploy SAP HANA on certified HANA hardware of any size (CPU or RAM) but is restricted to Lumira use cases. This license does not enable using HANA as a database or application platform for any other solution, but is exactly what the doctor ordered for Lumira Server.
If you are considering an SAP HANA system today so you can deploy Lumira Server, you are still investing in the right direction. Whether you are looking at a full use HANA license or use the “Limited Runtime” license that is now included in the BI Suite, this is likely a step you will eventually take as your deployment starts to take on more data and more users.
However if Lumira Server isn’t an option for you at all because of Lumira’s current dependency on SAP HANA, we hear you. We are heading down the path of providing a smaller footprint option, but in the meantime don’t forget to re-evaluate HANA’s new limited runtime licensing for Lumira Server as “free HANA license” should be a pretty hard thing to pass up for some of you. 😉