Skip to Content

I’ve now been involved with a couple of SAP HANA projects and I am left astounded.

Not only by the impressing performance and flexibility our product delivers for certain use cases.

I’m much more astounded by the expected level of software maturity of the final project implementations.

Yes, I’m not talking about SAP HANA as a DBMS platform but of the systems created on top of it.

Barely any of the projects included specific plans to design a maintainable system.

A system that can be meaningful monitored and eventually debugged.

Documentation of SQLScript code, modeled views and table design pretty much never exist.

Why did the designer of this CalcView decide to use plain SQL instead of CE_-functions?

What’s the rationale behind choosing this specific data type for that column?

How come this object is owned by user SAPDEV while the remaining ones all belong to MYAPPSCHEMA?

Answering this kind of questions requires having the actual developer still at avail.

Testing of views and procedures is done manually, if done at all.

Automatic testing with protocols?

Not existent.

Test data sets to verify functional correctness (at least for given cases)?

Never seen in any project.

Static and/or dynamic code analysis (How deep is your deepest function call stack you say? How many parameters you need to pass on average? What breaks if I change this part of your system?)?

Unheard of in SAP HANA circles.

 

This list can be extended with more and more points, but really irritating is the fact that apparently our paying customers are actually not asking hard enough for these things.

As it seems to me, they simply expect all this to be implicitly given. It’s a SAP system after all, isn’t it?

Fair enough or is it?

It seems the immaturity of SAP HANA as a platform is taken as a general excuse to throw over board the preceding decades of software engineering and craftsmanship. (You might pick the label you want to put on professional, reliable and reproducible work here yourself.)

Implementation teams happily and knowingly produce code that cannot be maintained efficiently.

Of course they do, as it will be their follow-up contract to fix and re-implement functionality.

Should the question come up, why the original code doesn’t do it anymore, it’s too easy to finger point at the lack of features and at instabilities of the development platform.

And is it just me or is the productivity of SAP HANA developers really that much smaller than that of their ABAP, JAVA or C# counter parts?

All this might work as long as the actual costs for the implementation aren’t bigger than the immense bill created by hardware and license costs.

Typically this means, round 1 of the implementation can fly under the radar of system quality, often leaving behind what could only be described as a mess.

No doubt, SAP HANA projects still are using a new platform. Many of the inherited best practices are questioned and some things needed to be changed.

But let’s not forget that in its very core, SAP HANA is a relational DBMS that exposes SQL as the main development API.

Now, how come that systems, that are built against an API that is 30+ years old, are implemented on such a unprofessional level?

Seriously, did just the fact that your IDE of choice doesn’t directly integrate with your version control system stop you from actually using it?

Did you consider using a SCRUM/agile approach with any other development environment that doesn’t allow for automatic testing?

I agree with most of the single feature demands seen here in SCN or communicated by customers and partners.

But I can’t agree with the lack of demand for a better system development practice.

And I certainly can’t agree with an approach where the goal to minimize system response time outweigh aspects like functional correctness and maintainability by several orders of magnitude.

The question is: why can you?

To report this post you need to login first.

12 Comments

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

  1. Fred Verheul

    Hi Lars,

    Sounds like a fair warning. I can of course only guess at the reasons for not adhering to best development practices, but two things come to my mind:

    1. Lots of customers who’ve bought HANA will start small, exploring the platform and its possibilities. This is normally not a good point in time to adhere to a very strict development regime (it’ll only slow you down, and hey, you’re just playing around, right?). Out of this Spielerei the first applications start to exist, and all of a sudden things are starting a live of their won (first ‘project’ goes live because the business wants it, seeing the huge benefits, bla bla bla), and then the question becomes: when do you take some time to consolidate and enforce some standards, best practices etc? Probably later ๐Ÿ™‚ .
    2. You’re right that SQL has been around for a very long time, but in the last 20 years or so SAP has always been shielding this away from customers, because of the DB abstraction and therefore DB-independence. So for most SAP shops this is still very new, and you can’t really blame them.

    Of course these things are not meant to excuse this behavior, but it will take some time. Still, a very good signal that everyone intending to do something with HANA should listen to and act upon!

    Cheers, Fred

    (0) 
    1. Lars Breddemann Post author

      Hi Fred,

      thanks for the kind reply.

      I agree, the proof of concept phase, the tryout phase, the R&D phase, these implementation environments would struggle with heavy and strict implementation practices burdened upon the developers.

      Maybe I’ve just seen the “wrong” batch of projects, but my impression had been, that most of them had been clearly past these stages.

      They were implementing stuff. Coding business logic for actual users. Having real go lives and production hand overs.

      That’s where I am coming from in my rant.

      Did I see the “wrong” projects?

      – Lars

      (0) 
    2. Lars Breddemann Post author

      Hi Fred,

      thanks for the kind reply.

      I agree, the proof of concept phase, the tryout phase, the R&D phase, these implementation environments would struggle with heavy and strict implementation practices burdened upon the developers.

      Maybe I’ve just seen the “wrong” batch of projects, but my impression had been, that most of them had been clearly past these stages.

      They were implementing stuff. Coding business logic for actual users. Having real go lives and production hand overs.

      That’s where I am coming from in my rant.

      Did I see the “wrong” projects?

      – Lars

      (0) 
  2. Ravindra Channe

    Hi Lars,

    I agree with you. In my opinion it needs a different mindset to build systems on a HANA. Development team needs to understand the basics of HANA architecture like columnar and in-memory DB architecture. It could also be possible that many a times the development team had been working with Packaged implementation products like SAP BW or a similar DW toolset which provides a pre-defined framework for development and over a period the development team has side-lined the basic concepts of greenfield development.

    In last few years, I haven’t seen an application developer who would prefer to spend more time in design and architecture, testing strategy (about > 60 %) and less time on coding (about 30 – 40 %). After developing a basic design, people tend to jump to coding. Less people get into the development right from the scratch after fully understanding the requirement and not rely upon the fancy graphic editor which provides the code templates and faster ways of development. I fully understand that the new graphic way increases development productivity and has less chances of error, but at the same time these “template” development tools restrict the rigor of the development practices.

    In case of HANA, I think most of the projects want to be the FIRST one to have shown the “Successful implementation”. This leads to shorter development and testing cycles and tend to cut the corners.

    I guess it will take some time, but I am sure things will get better with expectations set correct from the platform like HANA.

    Regards,

    Ravi

    (0) 
    1. Lars Breddemann Post author

      Hey Ravi,

      thanks for you getting into this discussion and for your feedback.

      I’m not too sure however, if development on SAP HANA really requires a different mind set than development on other DBMS.

      Maybe one big hurdle really is that SAP HANA is put so much into the focus of the development activities while the “classic” approach to develop within a SAP project didn’t see the DBMS as the tool to solve problems with.

      I like your idea of how being first impacts software and solution quality. I think that’s in fact an important factor.

      – Lars

      (0) 
  3. Jan Penninkhof

    Hi Lars,

    I’m quite curious to know whether you think this has to do with HANA or the hit and run mentality in which projects are (unfortunately) just sometimes done…

    Cheers,

    Jan

    (0) 
    1. Lars Breddemann Post author

      Hey Jan,

      I’m pretty mixed minded on this.

      Frankly, and put nicely, I see a lot of improvement opportunities in the provided set of  development tools and methods for SAP HANA.

      And sure enough, less guidance and less support from tools typically leads to more errors and more stupid mistakes. After all, that’s what the tools should assist you with, shouldn’t they?

      On the other hand: the lack of super-sophisticated tools doesn’t prevent anyone from thinking through their code and their processes.

      If I develop a multi-tier solution, I will have to decide on how I can control cross-tier dependencies at one point.

      Laying back and to think “I won’t be around for v2.0…” is just not good enough either.

      – Lars

      (0) 
  4. Andy Silvey

    Hi Lars,

    it’s refreshing to have open and honest feedback from SAP’s side.

    Part of the cause needs to land fairly and squarely on leadership on the Customer’s side, and quality of resources on the Customer’s side.

    In the following blog, I’ve opened up and challenged the discussion that there needs to be more emphasis on SAP Certification as a SAP Industry Accreditation Standard and minimum proveable standard of a level of competence to be used in the process of resourcing SAP implementations:

    SAP Education and Certification as the first level filter for SAP Human Capital Candidate Selection

    Perhaps, what you have described in your blog is a business opportunity for SAP Education, as there is clearly a gap in the knowledge and approach of Architects/Designers and consequently trickling down to Developers in terms of shall we say, fundamental DBA activities. Perhaps this is an opportunity for SAP Education to create a Hana DBA Course. similar to the old course ADM505/5 Database Administration Oracle (535 DB2), it looks like the same is needed for Hana and with more emphasis of fundamentals of good DataBase Design.

    Thinking further, thinking about your experiences, it begs the questions, in these implementations, who is doing the Database Design, an experience Architect with strong DBA experience, or a Developer with little DataBase Design experience.

    Thanks again for the blog.

    All the best,

    Andy.

    (0) 
    1. Lars Breddemann Post author

      Hi Andy,

      first the good news: courses like the one you’ve mentioned are currently in development and I know they are, because I had been involved with SAP education on this very topic ๐Ÿ™‚ .

      What I find disturbing is your first line, though. Is it your experience that SAP folks doesn’t act open and honest?

      Not sure what to make of this, but I sure don’t like to hear that.

      Concerning the question of “who done the architecture?”, I’m under the impression, that the solution architect with a strong DBA background is a rather rare skill set, or isn’t it?

      Even in “other-DBMS” environments this seems to hold true.

      About the certification approach to weed out total misfits you proposed, sorry, but I can’t agree.

      This of course is just my very personal take on this, but SAP has put in quite some effort just to catch up with yet another round of test-questionnaires that had been leaked into the open and needs to continue doing that, to keep out cheaters as good as possible.

      On the other hand, most of the certifications taken are associate certifications. To pass those, typically it’s sufficient to have attended the courses without falling to sleep.

      The rather tough professional certifications on the other hand are not so popular – of course, since nobody wants to pay for not passing.

      And your strict approach of not taking anyone w/o certification would e.g. let me fall through the wire as I’m not certified for SAP HANA.

      Did I review certification questions and create new ones? Sure.

      Did I present standard SAP courses that are prerequisites for certification? Yep.

      Do I provide coaching and training to already certified colleagues and partners? You bet I do.

      I’m pretty sure that I can contribute to basically any SAP HANA related project – but I’m not certified and I got the feeling that there are others like me that are just not that keen on that.

      What do you think? Am I wrong on this?

      Cheers, Lars

      (0) 
      1. Andy Silvey

        Hi Lars,

        ok, first of all, i hope I didn’t have the wrong choice of words but what I wanted to say was I appreciated your openness from the perspective of freedom of speech, I mean, you have opened a discussion on a subject that perhaps not so many others would feel free enough to do. To confirm, there was no intention in the meaning of the words to suggest that SAP does not tell the truth.

        Yes DBA is a rare skillset, but elementary db design for applications development and the developers conforming to the design standard is not rare, and what I wanted to say was, #1 the leadership has to be questioned, and then, the Developers should have some professional discipline to look at the database design and stick to the standards of the design to avoid the elementary mistakes which you’ve listed, like for example matching wrong datatypes in applications.

        Regarding the certification, this will need leadership from SAP to lead the Customer base to look at certification with more enthusiam.

        I am similar to you, prior to last week i’d never taken a certification, and as I said in the blog, if we know our subject so well, as you clearly do, then why not just sit the exam and get the certification ?

        All the best,

        Andy.

        (0) 
      2. Andy Silvey

        Hi Lars,

        regarding your feedback about the courses, it is indeed good news that courses are in development, what we need, looking selfishly from my Basis Administrator perspective, is a Hana course along the lines of the curriculum preparing the Administrator for a NetWeaver Hana certification like:

        SAP Certified Technology Associate – System Administration (Hana DB) with SAP NetWeaver 7.31

        basically a Hana version of the equivalent DB2/Oracle/Sybase curriculum for the certification etc

        SAP Certified Technology Associate – System Administration (Oracle DB) with SAP NetWeaver 7.31

        such a course and curriculm certification path would be a nice complement to C_HANATEC_1 and C_HANAIMP_1.

        All the best,

        Andy.

        (0) 
        1. Lars Breddemann Post author

          Hey Andy,

          agreed.

          I even would say, more is needed than what the classic ADM courses provide.

          Let’s see how the new courses cover the broad topic of SAP HANA.

          – Lars

          (0) 

Leave a Reply