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.

New Picture (2).jpg

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.

To report this post you need to login first.

7 Comments

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

  1. Martin English

    The first time I assisted with SAP OS/DB migrations, on an SAP release starting with 4, the SAP tools had a bug where tables larger than 1782579200 bytes were reported as containing 1782579200 bytes.

    I’m doing some migrations at the moment, not HANA related, just moving platforms for some traditional 7.0 / 7.3  ERP systems. Same bug, still there

    (0) 
  2. Steve Rumsby

    I think the fundamental problem is that working on new stuff is always a higher priority than making the existing stuff work better. New stuff sells, better old stuff doesn’t. I don’t think there’s a real reason why SAP installs and upgrades have to be so complex. The process could be much more automated than it is today.

    Just use cloud services. Then you’ll never have to install or patch ever again… 😉

    (0) 
  3. Tim Carnes

    John,

    I’ve a hard time understanding why you wrote this.First, River is net new and no or hardly any productive customers, BW has a 17 year legacy and 16k customers. They are not playing on the same pitch.Then, what do you intend? Blaming some SAP guys, even mentioning names? Provoking? Finally: what’s your experience regarding migrations to Suite on HANA? Is the situation better?

    You leave me with lots of questions …

    Best. Tim

    (0) 
    1. John Appleby Post author

      Hey Tim,

      Thanks for calling it out, I appreciate it.

      I only mention River because it put me in a state of mind to expect that software be simple. There’s no comparison between River and BW, for sure.

      The intent of the article was a call to action to simplify a process which has been making SIs rich for years and delaying customer upgrades. It has nothing specifically to do with BW, or HANA for that matter – it’s common to all upgrade and migration projects. Steffen is not specifically to blame, but he can do something about it.

      Happy to answer all your questions and it always peaks my interest when someone reacts negatively to a piece of content.

      Let me ask you this, since I don’t know you. Have you ever done a BW on HANA migration? If so, do you think the user experience is acceptable?

      John

      (0) 
      1. Tim Carnes

        John,

        my point is that the goal doesn’t always justify the means. I’d hoped for some directions leveraging your experience. I’ve done migrations and we probably share the same goal.

        Tim

        (0) 
  4. Chandrakanth Angannagari

    Hello John

    I am a fan of your articles as they do bring the latest information quite concisely. I would like to give my feedback have been a Basis consultant myself. I dont quite agree that SAP has made the migration to BW on HANA complex. Any migration requires a lot of things to consider and is one of those life cycle management exercise which we dont do every 6 months.  I do recall unicode migrations were really complex with too many sap notes coming in play. And HANA being an evolving product, its quite natural that we need to evolve with it.

    However having said so, the migration to HANA itself i have found to be much more simpler with all the artifacts and the beautiful tools like DMO and other new features in SWPM developed. I have been part of PoCs for our customers and i did really find things which were manual before are now automated. (Infact i sometimes feel insecure because its so easy these days … ) . I dont deny that there are errors and we have SAP messages to deal with but thats software. It never is bug free.

    About the pay , well why not? Dont you agree that the Basis folks (especially the skilled ones who have similar project experience) play one of the most important role in such a migration project. I think they are the ones who are really the onus-bearers who bridge the BI guys and the project managers (sometimes have to encroach each of their spaces and make them understand what SAP advises) . I think the pay is well deserved (speaking for such migration projects ).

    Thx

    Chandra

    (0) 

Leave a Reply