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.