Skip to Content

Since we announced Lumira Edge edition in the second half of last year, I’ve had countless conversations and threads asking how our innovations with Edge edition and later with Lumira and the BI 4 platform will eliminate the need for buying or deploying SAP HANA.  Every conversation inevitably has me paraphrasing the fairy tale character Rumpelstiltskin at some point, “Yes, it is possible to have the magic of HANA without a HANA, but magic always comes with a price!”

/wp-content/uploads/2015/01/rumpel_animated_620763.gif

The discussion usually turns philosophical: There are people who would argue that “magic” doesn’t exist in this world and it is nothing more than misdirection and illusion.  However if you allow yourself to suspend your disbelief for just a little while, things that defy your mental model can appear downright magical.  How else could children believe there is a magical bunny hopping around that hides chocolate eggs everywhere? Kids know logically that there isn’t an Easter Bunny, but suspend their disbelief long enough to find the eggs and get the chocolate – at the end, it was fun and chocolate was involved, so it doesn’t really matter that giant rabbits aren’t invading the place – Rumpelstiltskin would say, “a means to an end Dearie!”.

The thing about magic though, is as soon as your disbelief overpowers your belief in that magic, the illusion vanishes and you feel fooled or deceived. It’s the same when the cost for something outweighs the benefits it provides to you.    As we get older, we learn that “there’s no free lunch” and you can never get “something for nothing”.   We know there is a cost to everything, but if the benefits we get really far outweigh those costs, do we really care how that magic was performed or if it was “real magic”?

The answer should be a solid, “NO!” – it may be “interesting” that a product uses in-memory technology to be lightning fast, but do you really care if it is “in-memory” as long as it delivers superior speed and scale at a more attractive cost than all other alternatives?    Hopefully you care more about the business benefit, because there’s no point in waving a magic wand around if it doesn’t actually solve any real problems.

SAP has a big “Magic Wand” called SAP HANA.  It truly is magical – A wave of the wand can reduce huge piles of data into real-time analytics, it can compress time by doing things faster than anything else on the planet, and it disrupt everything you ever thought you knew about data (I hear rumors it can also slice bread and soon can be used as a desert topping too 🙂 ).   SAP HANA (and therefore SAP Lumira Server) creates some incredible magic, but each customer must choose whether the magical benefits are worth the cost.

Many customers want SAP Lumira Server but don’t have an SAP HANA system or aren’t ready to buy one just yet.   They are also looking for a little magic too: “SAP, please wave your hands and make the HANA requirement disappear!” If you look more closely though, the request is really, “Give me a smaller Magic Wand so I can get Lumira Server functionality without needing HANA because we need something smaller, more affordable, and easier to use/deploy”.

This is where SAP Lumira, Edge edition or “Team Server” comes in.   You can read more about it SAP Lumira, Edge edition: What Is It?.

Magic Always Comes With a Price


Edge edition is a product that uses such a smaller magic wand.  This is clearly SAP agreeing that different customer segments have different needs. (You can read more about this at: SAP Lumira Server is Not a Ford Model “T”).  It will be truly magical when we release Edge edition/Team server and enable thousands of customers to create, edit, and share Lumira content without requiring SAP HANA.   But what is the cost of delivering on this magic?  Costs are not always monetary – fundamentally, a cost is quantified by what you lose.

So let’s take a look at some of the benefits of using a “smaller wand” and some potential costs for the magical feat of eliminating the HANA dependency:

1. Smaller Footprint

SAP HANA is typically deployed as a hardware appliance with lots of RAM and many CPU cores.  This type of footprint provides a significant level of power even in its base configurations, but in smaller or less intensive workloads, those resources might not be fully utilized.   Those who read How SAP Lumira Server Runs on SAP HANA, know that Lumira Server doesn’t use HANA as a database, but as an in-memory execution engine.  To reduce the CPU and RAM footprint, we need to turn to different in-memory engines and use different techniques because HANA is written to scale linearly and works best when it can stretch out across a lot of cores.

A solution optimized for low resource usage practically guarantees a performance delta against a larger machine using a more efficient engine. But customers with lighter workloads or smaller datasets may find the costs in this regard an acceptable tradeoff to purchasing an SAP HANA system right away.  The reverse is also true: When speed or size becomes a real issue, it’s a clear sign you should have already migrated to a HANA-based solution or at least should start planning for one now.

Incidentally, it is important to note that the consequence of using a smaller footprint system when it isn’t ideal is that the costs (in this case response time, efficiency, data size) outweigh the benefits and the system no longer appears magical – it just becomes downright frustrating to use.

2. More Affordable

106Rumple1.jpg

SAP HANA is seen as expensive – and for really small workloads, it likely is against the alternatives.  Part of the reason is due to all that RAM and all t hose CPU cores – but it is also expensive because HANA requires “certified hardware” which is another way of saying “hardware configurations that have guaranteed performance numbers and support agreements”.   If we loosen the reign on performance and scalability to reduce the hardware footprint, we should be able to use commodity hardware of a different and potentially lower specification – or even deploy in a virtual environment.  This would not only lower the acquisition cost, but in many organizations there is either already equipment that could be repurposed or there is a virtualization farm just waiting for another machine to be provisioned.

A solution that is more affordable because it does not focus on performance and scalability will be, well… less performant and less scalable. Again, for customers with more modest requirements this likely won’t be an issue.  Keep in mind though, as they grow, they simply cannot move to a bigger machine – they may have to migrate to a HANA-based Lumira Server.

I’ll be explicit here: a Lumira Edge edition server on the same hardware configuration as a Lumira Server on SAP HANA cannot be expected to handle the same workload.   If you are planning an Edge edition server on 16 or more cores, you likely would be better off to start with a HANA system for about the same price.

3. Easier to Deploy

SAP HANA has a higher TCO than other solutions because it does everything: it is a database, it is an execution engine, it’s a platform (not to mention the aforementioned bread slicing and dessert topping capabilities).  By focusing on only what SAP Lumira needs and simplifying the installation, configuration, and operation, we really believe we can offer a solution that smaller companies and lines of business (LOBs) in larger organizations can deploy – with, or without their IT department’s help.

You are likely seeing a pattern here – the “benefits” of a simplified experience has a “cost”: potentiallyless functionality.   This could be in the form of a simplified security model, fewer enterprise integration options, or even lack of “enterprise readiness” features common in more mature and complex platforms like the SAP BI 4 Platform.   For customers who are focusing on the use cases Edge edition is targeted for, this shouldn’t be much of a problem.  However if you are looking for how you can extend the solution yourself, how it can fit with your other systems, or how you could satisfy multiple groups at the same time with this solution, you are likely better off with either SAP Lumira Server on SAP HANA or an SAP BI 4-based Lumira solution (which you’ll likely see in 1H2015).

Room for More Than One “Magic Wand”

Magic-Wand.png

After reading this article, it is likely you fit into one of two groups:  The first is happy and cheering that SAP Lumira, Edge edition is still attractive given the limitations of this “non-HANA” approach.  The second group sees those constraints as decision points that may very well eliminate such an attractive solution as a real-world option.  If you part of the latter group, it’s very possible you need to consider either a HANA-based or BOE-based Lumira solution instead of Lumira Edge edition.   It sounds bad, but it is actually a Really Good Thing – it means you understand the value of Lumira and are thinking bigger than what Edge edition is aiming for.  However if nothing I have written has fazed you yet, Edge edition is worth a much closer look.

Like all magical stories, yours too can have a happy ending:  It is good to know that if the novelty of a smaller magic wears off before your larger workloads are satisfied, your story can continue –  as long as you realize you just might need a different, and perhaps bigger magic wand 😉

Do you like the concept of having “more than one magical wand” at the cost of not having “one wand to rule them all”?  Hit “Like” or sound off below.


** Please note that while I am an employee of SAP, the opinions here are my own and may coincidentally align with SAP’s. This article is food for thought and not an official statement on capabilities or limitations of any products mentioned here.

To report this post you need to login first.

6 Comments

You must be Logged on to comment or reply to a post.

    1. Henry Banks

      Hi,

      Thank you for submitting your enhancement request over here already : https://ideas.sap.com/SAPLumira/D26614

      My feeling is that this will first be supported through a BI Universe (OLAP .UNX) – currently not supported, but planned.

      your ‘keep it live at source’ rather than ‘download’ is harder to answer.  i believe that we’ll do this first for our native connectors HANA and BW, then other strategic investment areas, hadoop etc.

      As for a native connector for non-sap olap sources?  There are similar fringe requests coming from the martket, but its not clear if and when these will be considered for implementation in future: Design Studio needs to support non-SAP OLAP sources, like Hyperion Essbase and MS Analysis Services : View Idea

      Regards,

      H

      (0) 

Leave a Reply