Skip to Content

In a world of lacking resources either you are rich or you have to be smart. SAP seems to be rich and loves to do everything twice.

Usually you fight against the lack of resources by being smart and avoid doing nthings twice. But since it’s early R/2 days SAP loves to do double work.

And the pity is that it is not an evolution where a new component replaces and old one. No, both elements remain in competition with each other with a more or less large intersection – and the customer always has to worry about which one to use.

Do you remember the wars between the SAPDYNP and the SAPPG38 guys? Every party tried to do the same things the other one did, but differently. So, instead of simply attaching dynpros to reports for selections, we now have to struggle with two types of screens, dynpros and selection-screens (and an impending  carpal tunnel syndrome when coding the latter).

A smart developer facing the customers heterogeneity would adopt a cross compiler framework, so he/she codes only once and then he/she throws the code through the cross compiler for the different customer environments. This would have been smart! But SAP is rich and for the SAP Gui development it prefers to use Microsoft products which notoriously bind you to the Microsoft Windows platform (Honi soit qui mal y pense) and then SAP rejoices in rewriting all gui coding a second time in java (unfortunately not all modules).

Do you wonder why you have to bother with both an ABAP and a Java instance? I have often seen my BW colleagues scratching their head trying to figure out on which platform they should implement their requirements.

But the Gui is from yesterday. Now we have html-stuff because it is reputed to be more modern. So all new transactions are realized as WebDynpros for Java, oh, pardon, as WebDynpros for ABAP.

Ok, let’s just talk generically about WebDynpros. They all have the same MVC paradigm and look&feel and so on. But what’s that? There is a second UI with another programming model and another look&feel, the CRM UI, sprouting in front of to the WebDynpro one. So what?

Play It Again, Sam, and again, and again…

To report this post you need to login first.


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

  1. Kumud Singh
    Hi Riccardo,

    Very well agreed with the DO IT AGAIN concept of SAP. But then, what is the crux of this blog?
    Even I do realize that SAP is constantly improving its products, older versions etc. Is it bad to have both the old and improved version at the same time?That can be taken as a marketting strategy and many more thoughts can be poured in here.


    1. Riccardo Escher Post author
      Hi Kumud,

      I agree to you if the improved new version of a product is able to be the replacement of the old one like NW04s is the replacement of NW04.

      But unfortunately SAP loves to put a second (and a third) technology implementation in addition to an other one (please see my examples), so that we customers have to juggle both.
      SAP is rich and can affort it, but we customers have the stress of setting up additional know-how. Now we have ABAP experts beside to Java experts, CRM UI experts teasing WebDynpro Experts, and so on.

      The most funny dilbert like waste of resources is IMHO the reimplementation of SAP Gui For Windows active-x controls as java beans. This is an impressive demonstration of opulence. A counter-example for smart development might be found in Open/LibreOffice ( the same source code supports three different kind of operating systems!

      If you are rich and have plenty of time you can enjoy this luxurious richness of coexisting technoloigies like an adventurer does in the tropical rainforest.

      1. Stephen Johannes
        Let’s be honest most of these parallel solutions have been rolled out that unless you are willing to not learn the “new solution” within 3 years of its release there will be no impact.

        A luxury would be having business requirements that do not evolve and force use of new technologies to solve the problems.  In terms of the UI pieces you allude there is a valid business reason for this.

        Competing UI technologies
        CRM PCUI – bad bad bad needed overall
        CRM Webclient UI – ABAP Webdynpro was not ready when CRM needed it.
        ABAP Webdynpro – java version came first

        For any of these solutions unless you went out on the bleeding edge of the business suite releases, most of the new stuff does not impact you until at least three years later. 

        Take care,


  2. Gregory Misiorek

    customer first, developer second, correct? from an engineering point of view, some redundancy doesn’t hurt either, does it? how about parallel development? SAP is not only rich, but also smart by embracing the latest technologies, e.g. XBRL or Objective-C (?), but without throwing the baby (customer) with bath water (development tools). SAP integrates not only via DUET (with Microsoft), but also via ALLOY (with IBM) and believe me i’m not a big fan of Lotus Notes. i like your pointing out that this “habit” or strategy goes back to the days of R/2, of which i know nothing.

    SAP is not only doing mobile, but also taking care of the installed base, which hasn’t even begun thinking about mobile. shouldn’t SAP make up their mind and decide which one they want to do?

    play it again, Sam because i like the tune and we are on an evolutionary path with history repeating itself, but with a new twist. SAP is very smart doing that. Honi soit qui mal y pense.

    @greg_not_so’s tweet #55232149527330816

  3. Former Member
    Well let’s shoot them. Or I know STOP using SAP. Or don’t use the newest technologies provided by SAP.

    How many programming languages are there? MMMMmmm… I don’t think SAP supports them all. How many different ways of doing things are there?

    Web UIs? You better talk about MII too! It’s a personal favorite of mine.

    What would be the fun of SAP if they were not moving forward? There will be sometimes when they fail in something new. What I like is that they still support the “old” stuff.

    My company is not bleeding edge. So the changes do not affect us too badly.

    Besides – you’re talking job security for us.

    Now I must say I agree on one point. My basis friends are struggling with the 2 different stacks. JAVA and ABAP. Sometimes they don’t play well with each other.

    But personally – I think change is great. I like the option of doing things differently. You get to use the best solution for your project.

    So play it again Sam! I love that tune.

    1. Riccardo Escher Post author
      “you’re talking job security for us.”
      The best argument I have read up to now :-]]]

      But seriously: You (and I mean also the other commentators) are missing my point!

      I don’t argument against evolution or against new technologies, I love both – my motto is “placet experiri” ( – but I don’t like it when they are introduced in a more or less chaotically manner – without an _*architecture design*_ behind it.

      So to use the tune metapher: It’s more the sort of a dodecaphony ( than a harmonic tune.
      Not so easy and nice to play it again …

      I have the impression that at SAP there are many department silos: sometimes one department dashes forward with something new without much regards to the work of the other departments (yes, there is a sort of dialog simulation with the others, but very formal and substantially every department does it’s own thing).
      Then, afterwards, they have to be recaptured.

      For example the new CRM UI: shot from the hip without waiting for the others.
      Now the Netweaver Business Client Developers are facing the problem that the CRM UI has an own navigation, so when you open it in the NWBC you will have two navigations – an allegory! :-).

      Obviously they will invent some trick to make it work, but why not architect a common strategy *before* the solipsistic creation of a new technology?

      1. Former Member
        Agreed – sometimes right hand, doesn’t understand what the left hand is doing.   That’s an interesting thought.  I know we’ve talked about it at my work.

        There does seem to be silos at SAP.   Workflow objects vs. class/objects.   Now workflow uses class/objects too.  But at one point it didn’t.

        I think SAP is just so very big.  It’s hard to keep the development the same until after the fact.  Projects are probably going on at the same time.

        Your right – I missed your point.  Thank you for the clarification!


      2. Stephen Johannes
        The problem is you forget that SAP sells business software first, with technology to solve the problem second.  SAP had a business problem with CRM in this case.

        The PCUI for SAP CRM was pretty much despised by business users and SAP CRM professionals alike.  SAP needed a new user interface for SAP CRM or face losing about 50% to 75% of their CRM install base.  There was no time to wait for a perfect technology strategy and instead a solution was needed first.  In a ideal world you can wait for technology to be ready, but in this case it was a make or break situation.

        I personally think that if SAP wasn’t facing a situation where they could lose most of their CRM install base, they might have waited longer for the other technologies to be ready and thus CRM would not have been an odd duck technology wise.

        Once again we need to remember that the business needs should drive the technology solutions and not necessarily wait for technology to catch up with the business.  That’s why “new technologies” such as HANA are great because they address specific business problems instead of just focusing on hey let’s figure out first how all in-memory solutions should work before trying to solve a problem first.

        Take care,


        1. Riccardo Escher Post author
          Business Needs? Yes, there are always business needs behind any change.

          Also in our company the developers always have incredibly urgent business needs when they have to justify some strange and ugly trick they want me to accept (I am the responsible for the development and transport rules).

          It’s like in politics, it’s called the strategy of doomsaying (“If you don’t do what I want you to do our company will fail, terrorists will destroy our country, an asteroid will smash the earth, …”) combined with the strategy of There-Is-No-alternative (“Do what I want or face destruction: a third alternative is impossible, so it’s useless to discuss”).

          But usually business needs don’t attack you like a tsunami. Legal changes, market trends, new company strategies usually announce themselves much time before a software milestone.

          *If* you are determined, if you are committed, you *can* do a good architecture design, always!

          The new CRM UI for example, I know it’s history.
          You quote horrible figures, but how did it happen?
          Did all the SAP CRM customers make a world congress where they decided to give SAP an ultimatum: If SAP doesn’t create a new UI in the next three month 75% of us will quit?
          No, I am sure that the problem finding was a long process, not an immediate enlightenment.
          I am sure there would have been enough time to design a new UI roadmap (by the way, I prefer the CRM UI and don’t like the WD look and feel).

          Michell said, the left hand doesn’t know what the right one does and that SAP is far too big to coordinate development. But often they sit in the same building… And for example the development of the Linux kernel shows that it’s possible to coordinate worldwide an incredibly heterogeneous crowd of developers for a really good “product”.

          IMHO it’s not the size, I have the impression that there might be a tradition of department egoism which inhibits successful software architecture (this was the motivation behind my recalling the mythical R/2 department wars ๐Ÿ™‚ ).

          I remember another example for irritating double tune: once I attended a presentation of the new E2E Change Control (Solution Manager), which also tracks transport requests.
          As a ChaRM user I asked the developer why they don’t use the already existing ChaRM reporting as a source of truth, which already collects all transport requests. He answered, that so they are independent from the ChaRM.

          Nice! The ChaRM Reporting collect job runs over 2 hours several times a day consuming heavily resources on our solution manager and on our satellite systems and now we have to schedule another heavy job which collects the same data only because the E2E diagnostic team doesn’t like to coordinate with the ChaRM team?
          Deep sigh…

          As company Rules&Regulation agent I use this method: the first colleague that comes with a business need for a new development will do the job and will (in coordination with all the stakeholders) implement an api for his development and document it so that the next who will come will use this api or interface instead of coding a parallel or concurrent product.

          But let’s close this very interesting debate with an optimistic outlook.

          I was very well impressed by the key note of Jim Hagemann Snabe at the DSAG congress last September.
          He explained his decision to postpone the roll out of the new business suite – despite of all business needs and marketing thoughts – with the need to have more time to improve quality by creating and operating hundreds of test scenarios.

          To my knowledge this test environment is new!
          In the past usually SAP argued that the high customizing flexibility of its products makes it impossible to really test them, because every customer customizes his own and unique business suite.

          So I begin to hope that the new boss, who comes from the development, will also inspire an opening of the “silos”. May be the developers will be given some fresh air while meeting the customers.

          I also notice that the new buzzword “one source of truth” is being adopted by many product managers.

          So let’s hope that we will face a new and sunny future ๐Ÿ™‚

          1. Former Member
            Ahhhh…  BUT I didn’t say they weren’t in the same room.   Right hand and left hand can be in the same room working on different priorities and trying to get a project complete.

            Yes, good programming is key.  We have code reviews here to try to stop the junk due to bad architected solutions from getting through to our systems.

            Sadly – when it comes down to  the end of our projects, well stuff gets through.  We tend to lower our expectations.  Only catching the most important things. 

            Now take SAP do they have a cross functional team looking at all technology?  I don’t think that is feasible.  There is just so much.  But maybe I’m wrong.  Maybe it is a possibility, and maybe they do it now…  You and I don’t see it with the different approaches to similar solutions.   BUT we don’t know the reasons for using the different approaches either.

            I’m keeping my fingers crossed for a new sunny future too!  Ease of use – what a concept.   I know business need does outweigh the developers “Nice to have” are technologies that are the same.  We can learn and do learn to change.  (Job security)  Our business doesn’t have the time.  They have serious needs.  Our job is to keep our business running; not develop the perfect software on the perfect platform / language.   We have to be flexible to give our business the advantage.

            Always – supporting the flip side!  I Love this discussion.


          2. Stephen Johannes
            I think you are missing the point that SAP saw it’s lunch being eaten by Siebel,, etc and knew it had to do something different.  The writing was on the wall that if they didn’t something, SAP shops that chose the solution because of integration to ERP, would dump it.

            Now if they waited for the geeks to figure out whether Java, ABAP or something else is the right solution, they would have missed a busines chance, by letting technology not the business market drive decision schedule.  A delay of about 6 months to a year if they waited for a UI strategy would have essentially killed the product completely.  The SAP CRM customers didn’t need to tell SAP collectively in one room that a change was needed.  It was just a natural process of end-users rejecting the solution that moved things up.

            If you look at the whole Business Suite Innovations 2010 debacle, I see that as a big mistake in trying to make every single solution with different speed needs be on the same schedule.  It’s like asking marathon runner to complete a race while staying behind a toddler who must also complete the race.  It can be done, but probably won’t yield good results for either parties which need different timeframes and goals.  Otherwise we don’t need separate systems(ERP, BI,SCM,CRM), and should just go back to a monolith type system(R/3) since we aren’t getting any business advantages for having all these other boxes beyond paying more to hardware and software vendors.

            Take care,


        2. Former Member
          I fully agree that technical decisions like CRM UI are business driven.  So there are sometimes good reasons not to wait for the perfect global technical solution, but to go with a solution valid only in a certain area. 
          But e.g. in the BW area there are several examples where only a really rich  company like SAP could overcome the different misleading decisions.
          The investment into the new homebrew  frontend tools like BEX 7.x , BEX-Web JAVA, Report Designer 1.0  had a quit high burn rate without any suitable results.
          Of course there was a real business reason to stop the further development and to acquire  Business Objects with there state of the art BI tools. That was the only way to catch up with the competitors in a consolidating market.
          For the customer this means he can now “choose” between several Tools (BEX 3.x, BEX 7.x, BI 4.0 )  but at the end he has to  PAY  for this  suboptimal design decisions.
          So that SAP remains to be the really rich company it is.

  4. Gregor Wolf

    While being on the train with Riccardo Escher to the DSAG Technology Days Bertram Ganz sent me information about the SAP Web IDE. It is now also available not only in the free SAP HANA Cloud Platform Trial. But also as a paid version for 66$ per 5 named users and month. SAP offers this via two platforms:

    In SAP HANA Marketplace have the possibility to change my location to Germany and get the offer also in Euro (49 €). In the SAP Store my Location is fixed based on my SAP Service Marketplace profile to Germany but the Price is displayed in USD until I switch the language to German ๐Ÿ˜• .


Leave a Reply