Technology Consulting, HANA and the Ultimate Batch Process
As part of my role at Bluefin, I oversee our HANA projects. Currently, we have several large BW on HANA migration projects underway, and two of them have my attention. They share a lot in common – they are big complex reporting systems on large $1m HANA appliances. In parallel, I’ve been discussing with Vishal Sikka what he describes as “the ultimate batch process” — the process of software development. Bear with me.
BW on HANA represents a good amount of the HANA projects so far. I think this in part because IBM and Oracle databases make such awful data warehouse platforms, and in part because it’s a simple and comprehensible place for customers to start their HANA journey. Once you have seen the purity of what HANA can do, putting BW on HANA can feel crass, but it’s a popular and useful use of the HANA platform.
I’ve not been heavily involved in BW on HANA migrations for the last few months — instead I’ve been looking at SAP’s next-generation products including SAP River. The purpose of SAP River is to redefine and simplify the developer experience — to remove the “ultimate batch process.”
What is fascinating to me is now, looking at the BW on HANA migration process, how it is the antithesis of SAP River and Vishal’s vision.
One of my goals for February was to make some information publicly available on BW on HANA Migrations. I did it as a three part series: 10 Golden Rules for SAP HANA Project Managers, Licensing, Sizing and Architecting BW on HANA and 10 Golden Rules for SAP BW on HANA Migrations. I’m looking back on those articles and I realize that I’m just describing the symptoms of a broken batch process.
Why do we need such expertise to do a BW on HANA migration? I was talking to SAP Chairman Hasso Plattner a year ago and he made a reference to Basis consultants who are paid €2000 a day and how this should no longer be necessary. He asked me what I did some while later and I joked that I was an overpaid Basis consultant.
The unfortunate reality is that BW on HANA migrations, especially for complex environments (simple single-node HANA deployments are much more forgiving), require highly qualified resources. Their relative scarcity means they are in demand, and highly paid. And this is hurting adoption of BW on HANA.
Why can’t BW on HANA ensure that it is on a working HANA system, download the latest versions of software so that you know that it’s going to work? Why can’t it apply the right patches to your system so you don’t have to troubleshoot before, during and after migration? Why is it so complex and easy to get wrong?
Why isn’t there a single program you can run for pre-upgrade and post-upgrade steps, to make sure you get it right? Why isn’t there a single correction as part of this process that applies all the corrections for your system?
In short – why hasn’t there been an innovation in BW on HANA’s Ultimate Batch Process – the process of moving onto the latest version and onto HANA?
I asked this of a Basis consultant and he responded “I sort of assumed SAP kept it complex to keep the System Integrators in business”.
And yet, I don’t think that SAP ever intended this, although it’s certainly true that System Integrators relish the complexity and day rates that they can charge. Trust me, Basis consultants aren’t going to complain (and probably won’t be listened to if they do), because the complexity can be quite challenging and fun. Technical people love complexity.
I don’t for sure know what the SAP development team under Stefan Sigg think about this, but my guess is they have a lot on their plate and this hasn’t been pointed out as a priority.
There is a fascinating project going on at SAP this year, which is clearly one of the board’s highest priorities, because it made it into four out of 17 of Bill McDermott‘s slides at their Investor Symposium in New York. The project is led by Maggie Fox and is called 1DX or One Digital Experience. It’s designed to simplify the experience of dealing with SAP, through coming into the Web, the marketing and sales process, and support process. It’s another example of the Ultimate Batch Process. I’ve been working in the SAP Ecosystem for many years, and Maggie has her work cut out for her.
So here is my call to action: Spot these Ultimate Batch Processes. Call them out. Tear out the complexity.
Thanks to Dennis Howlett for telling it how he sees it.