Skip to Content

HANA – Can the new Sheriff in town undo some of the horrors?

Speed should not be the only characteristic that differentiates HANA – there should be  additional virtues that give solid benefits. Of course every SAP project is different – but the difference is not to the extent that every project is 80% new. Rather, at least in my experience, the difference is more to the tune of 20 to 30%. While this is good for standardizing, there are some common side effects too which are not so good. There are some common requirements in most projects where we have to do less than optimal solutions to satisfy the requirements adequately. And since 70 to 80% of requirements are similar across projects, these sub-optimal solutions also are pervasive across implementations.

 

With HANA, the new Sheriff in town, can we get some better solutions in place without resorting to awkward work arounds?  

 

Those of you who are familiar with ABAP and BW reports in the sales side of the ERP/CRM world (you know -the familiar billings, bookings, backlog view) – you would have seen requirements like ” On an average, how long did a line item stay in a particular status?” or “How long did it take from the time a customer placed an order before we gave him the goods and got paid?” or “How many times did the customer change his mind on a given order?” etc.

 

I am sure we have solved such questions many different ways using both ABAP and BW – either using change history log tables (maybe some custom tables too) in ABAP, or by using some complex date logic (and a bunch of redundant DSO and Cubes ) in BW side. In general, these are the types of development objects that cause a lot of grief from maintenance point of view. Life would have been a whole lot simpler if we could report off the change log without huge over heads. From the application logic perspective, the complexity is typically on maintaining many different totals – and it is even more complex when reversals to transactions happen.

 

For those of us who worked on planning in BPS, IP and now BPC – how many times have we been requested for an audit log? like “I want to see who changed which data and when”. I used to hate this request when I was a hands on techie – and I would fight this requirement like crazy, trying to convince the business that preventing unauthorized changes, or altering business process is much easier than a technical solution of adding a characteristic which hold user id to the cube and the application.

 

Well, in the world of HANA – these tyoes of requirements should be relatively straightforward to solve. Why? For a few reasons – we don’t need to keep totals, since it is easy to total on demand. Also, change history need not be stored the way it is done now  in separate tables( and there are no updates, but only inserts). As a standard feature, rather than building custom reports that show the life cycle of a transaction sequence – it should be possible to get such a view from any application in SAP, including who changed what and when.  In case we do need to add additional columns to make some application logic work, this should be a piece of cake compared to what we have to do today.

 

Since requirements in planning, reporting, and transactions can all be met from the same system – separate instances of BW, BPC, APO etc should all mostly die away at some point (probably some will stay for sake of non-SAP data integration etc) . Considering the enormous investments across SAP’s install base, I am not sure how long this will take – but it will probably happen in the medium term.

 

However, I keep wondering how much and how quickly SAP will re-engineer existing code base to go beyond replication and make full use of in-memory capabilities. Since indexes, change history, totals etc are not required really – each application area probably needs only 2 or 3 tables (header, line items and schedule lines for example in SD). Now, with abstraction using frameworks and BOL like concepts, multiple scenarios can be mapped to the same few tables, making this whole thing even more lean and mean. That  should in-turn considerably reduce the amount of code needed to make the application work. Or maybe – unlike traditional SAP – more coding effort can be focussed on the front end side to make the end user happy, and less on backend.

 

Although a lot of mining is easier on change history in the in-memory world, I am not clear yet on how it works for status changes on various objects. Will SAP do an inserts-only paradigm, even though it is not strictly necessary? ( not necessary I think, because status is a fixed set of values, and one thing can only have one status at a time). Well, I hope some one who knows will let me know here.

 

I am not a big expert of sustainability by any stretch of imagination, but I would believe that moving more applications to in-memory has some kind of a positive impact in making world greener. Already with multi-core systems, a lot of server farms are able to shrink the number of servers. Coupled with in-memory benefits , this should logically result in less number of servers in the datacenters.

 

I sincerely believe HANA has the power to change SAP in ways we have not seen before – I am keeping fingers crossed, hoping execution by SAP and partners match the potential this offers.

3 Comments
You must be Logged on to comment or reply to a post.
  • Sorry Vijay, but this is just another of those blogs mapping hopes and phantasies onto HANA. Admittingly this is great technology with huge potential. But don’t overestimate what it can solve.

    Just an example: BPC and BW can share the same server incl. the DB – similar to the advantage that you claim for HANA when all sorts of SAP apps run on top of HANA. Yet, BPC is not able to consume BW infocubes directly because it needs the special style BPC cubes (1 key figure, account model etc.). This means that data needs to be copied from the BW infocube to the BPC cube. Now imagine that BPC and BW run on top of HANA. Will this problem go away? NO, absolutely not, unless BPC or BW move/change somehow.

    But even when looking at HANA 1.0 itself: have you tried to model the conversion of heterogeneous currencies in a table? Have a go and let me know what you consider the TCO of that!

    It looks to me as the sheriff walks around town with a water psitol handing out some funny marketing balloons.

    Tim

    • You may be 100% correct Tim. I must have been wearing rose tinted glasses yesterday night when I blogged 🙂

      OK – jokes apart, let me try to explain my point. The 1 key thing, special cubes etc is a BPC limitation, not a HANA limitation. My hope is, such systems will just die away – and planning/reporting will directly take place in the same system that has transactions. No redundancy, no crazy modelling etc.
      Since BPC cannot be cannibalized right away, I suppose this will take some releases to get to.
      Or may be something newer will take its place.

  • Hi Vijay,

    I think that it’s not the number of tables but a question of the approach: relation design versus NoSQL/key-value storage.

    A “virtual table” materialized in memory from a generic key-value gives every developer a lot of freedom.

    BTW: There is already an SaaS application that runs in memory: http://www.workday.com

    Workday uses only 3 tables for: instances, attributes and relationships.
    Seems as if they store objects 🙂

    use Google to find more technical information…e.g. Workday uses “append only” etc.

    kr, martin