Skip to Content

We have all read and seen the HANA announcements over the past few weeks and are excited and enthused about it.  SAP is certainly heading in the right direction and HANA just might be the killer app that they are saying it will be.

 

Now, before I start my rant I must admit that I am a big fan of “nerd knobs”.  I am never satisfied with defaults and wish that I had complete control over every device and software product that I use.   I grew up in the mainframe era at a time when code modifications were a necessary-evil when it came to customizing IT systems.  Fortunately, over the past 20+ years, our industry adopted open standards that allowed us to build agile, configurable IT landscapes that leveraged a common set of servers, storage, operating systems, and utility applications (databases, etc.).

 

With that said, I am a little worried that SAP’s approach to HANA is a bit too much “one size fits all” for many organizations.  I realize that many customers are attracted to the black box approach to systems but I am certainly not a fan if this.  Many of us try to implement a standards-based approach to application infrastructure and prefer to have standards in place when it comes to servers, storage, operating systems, and networking.  From what I have read and heard about HANA, it will be delivered as a preinstalled, preconfigured system that must be purchased by a hardware partner (Dell, HP, Cisco, IBM, Fujitsu) and will run on a certain version of SuSE Linux.   I realize that it is much easier for SAP to support this arrangement than to support open systems; however, that does not make it right!  Customers should be able to choose the hardware models & operating systems that they want to use; software companies do not have the right to dictate this.

 

I believe that it is inappropriate for a software company to package their applications in a black box unless they also give you options to install it yourself on your own standard platforms.  Although the “Open Systems” concept is not nearly as sexy as it was in the 1980’s, the fundamentals are still as important.  If we allow every software vendor to sell us black boxes, we will lose many of the synergies that we have gained by standardizing our platforms.

To report this post you need to login first.

7 Comments

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

  1. Bala Prabahar
    Hi,

    I read one of your other blogs on Business Objects. I guess BOBJ is also another black box. Wrong? Let me know if you found good documentation on internals of BOBJ.
    “Deliver as a black box” is the trend I’ve been seeing for a long time. It started with BW 10-12 years ago. RSA1 is a great wizard by the way. Anyone(with or without BW knowledge) can design/develop cubes with RSA1.
    Several months ago, I found a book: In-Memory Data Management by Aut.: Plattner, Hasso; Zeier, Alexander. I placed order with shipping date of 03/18/2011. I’m yet to receive that book. The point I’m making is that I at least found a book for HANA(well, not really HANA but for the technology used by HANA); but not for Business Objects Internals.
    Twenty+ years ago-i’m sure you’re familiar-when I started using RDBMS, we were reading manuals not on how to create a table or an index but on concepts such as check points, logging, data blocks in memory versus disk etc. Knowing internals used to be a requirement to do the job 20+ years back. Today anyone knowing internals is sidelined in almost all projects.

    Best regards,
    Bala

    (0) 
    1. Joseph Caruso Post author
      Bala,

      Thanks for your comments.  While I agree with some of what you said, the difference between HANA and BW & BOBJ is that unlike HANA, the customer can choose the platform that BW & BOBJ runs on.  For example, we currently run BW & BOBJ on HP UNIX and Oracle.  You might run it on AIX & DB2.  With HANA, you will have no choice on where to run it.  It will be packaged by your hardware vendor and you won’t even have root-level access to the OS!  What happens if a critical security vulnerability (or some other major OS flaw) is identified?  You will have to wait for SAP to provide you with a HANA-fix.  What if you want to use an enterprise systems management suite to perform alerting & capacity planning?  You can’t even install it on the HANA system since you cannot access the underlying OS.

      The bottom line is that SAP is taking away our ability to standardize our platforms and skill sets.  This is completely self-serving because it allows SAP to reduce their costs while increasing the customer’s TCO of the solution.

      Regards,
      Joe

      (0) 
      1. Bala Prabahar
        Hi Joe,
        You’re correct. The analogy is wrong. However what I meant to say was trend. The trend to deliver “something as a black box” started several years ago. It started with Software. Now everything, Software and Hardware. I guess what you’re going to experience with HANA is something I’m already experiencing with BOBJ and BW to a certain extent.

        Best regards,
        Bala

        (0) 
  2. Michael Nicholls
    While I can somewhat understand your concerns, I think we can maybe think about a HANA installation as an SaaS, where the service just happens to be running on a pretty coloured box in your data centre.
    (0) 
  3. Witalij Rudnicki
    Remember early days of BW Accelerator (or BIA as it was called at that time)? Back then you supposed to know only 5 parameters accessed through SAPGUI and ideally you should leave them unchanged. Since then the list of BWA tuning parameters you need to be aware of have increased probably ten times. The point I am making is that hiding complexity in HANA is not the same as eliminating complexity, and I think we are – at the technical side – are yet going to experience this (if not have yet experienced).
    So, although I share your pov and love for “knobs”, I do not really share your concerns 🙂
    (0) 
    1. Bala Prabahar
      Vitaliy,

      I agree hiding complexity is not the same as eliminating complexity. But what happens in real life? The complexity gets eliminated indirectly. Since complexity is hidden, a majority of people don’t want to discuss about it for want of time and $$$. And there is a good number of consultants who believe only in speed. All they want to do is check or uncheck a few buttons and deliver what customer wants. 
      I’ll give you just one example in S/W: SAP hid the complexity on table partitioning by providing that feature for E table in RSA1. Did they provide all types of partitioning offered by DB vendors? No, just one type on time variant. However they were open to customers who wanted to implement additional partitioning methods on more fields. But what happened in real life? Most customers eliminated the complexity by just implementing what SAP supports in RSA1.
      Implementing optimal partitioning schemes would require a good understanding of data and DBA skills. Customers even ask question: Who’ll support if person X who implements partitioning in DB level leaves the project? They don’t want to uncover the complexity.
      Regardless of what we discuss here, SAP will deliver HANA closed. I’m going to reread “Thriving on chaos”.

      Best regards,
      Bala

      (0) 
  4. Markus Doehr
    Not so long ago I made an upgrade from 4.6B to ERP 2004 (ECC 5.0) with Informix 7.31 on an RM600 (Sinix/ReliantUNIX) in SCROLL mode. No wizards, no maintenance optimizer (pain), no Java, just a plain 80 x 26 console and an R3up.

    Nowadays it’s all about fancy icons, nice GUIs and Wizards – or template installers – no matter where you look. You start something, enter some data and hope, that the traffic light turns green when finished. If it doesn’t, you may or may not have an idea about what happened and may have even less idea, how to fix it.

    Hiding complexity behind nice GUIs and “guided procedures” is, in my opinion, a really bad development; even if it works for 80 % of the cases, one has a hard time fixing the other 20 % because nobody but the development/developer knows exactly what is supposed to be done.

    Those 20 % keep me busy for most of the time and I would sometimes really appreciate having a good documentation handy instead of trying to follow ‘wizards’.

    My point is: even if the resulting product works for 80 % of the customers the other 20 % have a HARD time getting it to work at all for their environment.


    Markus

    (0) 

Leave a Reply