Skip to Content

Geek’s Dictionary: What is the Walldorf Kiss of Death?

I suppose some of my colleagues in the SAP field would consider me a rather blunt fellow because I always try to convert the fancy diplomatic messages I am confronted with into plain text. Sometimes I can be a bit slow and it takes me a long time until I figure out what something really means. Let me share my newest discovery and entry in the Geek’s Dictionary: The Walldorf Kiss of Death.

The Walldorf Kiss of Death is what occurs when SAP announces that they are really tired of something and would everyone like to know that they will henceforth ignore it whenever possible, but nevertheless honours all legally or otherwise binding obligations around it.

In the technology area, it occurs when they consider a technology so out-dated or non-strategic that they would love to throw it away and never give it a second thought, but acknowledge that it has adoption among customers whose investment must be protected. Henceforth, they will support it, i.e. handle OSS messages and fix bugs in Support Packages, Notes, and Corrections. But they will usually not use it in new developments or add features, no matter how hard customers cry for them.

So how do you know when something has been given the Kiss of Death by SAP? Well, the next time you talk with an SAP executive or someone else who has insight into SAP’s strategies and the obligation to be diplomatic, and you ask about a particular technology that may or may not be on the death list, watch out for the key phrase:

    “…will be/stay/remain with us for a long time.”

That is, in my experience, how they rhetorically apply the Kiss of Death.

On a related note, the German employees of SAP became really nervous when then-CEO Léo Apotheker said in an interview that

    “We achieve about 80 percent of our sales outside Germany. But our roots are in Walldorf, and we don’t want to cut them off. Otherwise we’ll lose our identity.”

The Walldorf engineers must have been afraid that this would be their kiss of death, their ticket to obsolescence, and right they were. Thankfully, Léo’s successors did not follow up on that.

Now, with SAP TechEd 2010 Berlin and Las Vegas right behind us and Bangalore ahead, it is high Walldorf Kiss of Death season, so watch out for all those announcements about the long-term commitment to technologies that smell funny. 

By the way, if you ever read Ray Kurzweil’s book “The Singularity is Near”, you will find very similar phrases in his ideas on how the robotic descendants of mankind will regard their biological predecessors: We will always be special to them, and we will stay with them for a long time.

I’m already scared.

You must be Logged on to comment or reply to a post.
  • That sounds a lot like what I've heard about SAP Business Workflow.  But surely, that can't be true.  Too many companies have embedded SAP Workflow in their processes, right?  I mean, we can all learn and benefit from new technologies and tools, but sometimes SAP customers need to run their own businesses first.

    Just my 2p,
    PS: Thought-provoking, as always!

    • Well, Sue, it doesn't at all mean Workflow is dead but it sure as hell tells you that the person you were speaking so leans towards that position. 🙂
  • Great blog, Thorsten.

    The beauty of this thing is that with a bunch of smart customers, partners, consultants etc - old and new systems will continue to co-exist somehow.

    I remember a lot of concern when BDC was not working for the new controls in R/3 and a lot of code had to be rewritten using BAPIs etc, and then the concerns went away. Similarly BSP, BPS etc all had their 15 minutes of fame, and associated cheerleaders. With such a lot of geeks around us - anything that SAP comes out with will have enough people cheering for it, and they will find cool things to do with it.

    And everything doesn't totally die either - there will be one little thing that will keep it alive. BSP has a new life with CRM. BPS which is not the strategic planning technology anymore, will continue to live because CRM only integrates natively with BPS and not IP or BPC.

  • I am wondering about SAP-specific tools such as E-CATT - you hear nothing about that, but hear that you should purchase HP's Quality Center for testing. 

    Great blog, as always, Thorsten!

  • Hello Thorsten

    You may remember the article published by the Gartner Group at the beginning of this year (

    The answer of SAP was "...a strategic commitment to SAP-PI...".
    At TechEd 2010 in Berlin is was announced that the ABAP stack on SAP-PI is dead (apparently the Java coalition has succeeded the battle). In the light of you special dictionary such facts become a different flavour.
    Is this already a flirt with the Dementors?

    The lack of the ABAP stack on SAP-PI will cause use a lot of headache and work (for details see: XI/PI: Generating EDI Interchange Control Numbers Using ABAP Class Mapping).
    On the SDN (or is it SCN? SNC?...?) it took me quite some effort to find the references to SAP-PI under "SOA Middleware".

    I believe (but do not count on my faith) that all SAP systems that have a firm ABAP “kernel” will remain in the long-term.
    Thus, has SAP-PI already been short-listed?


    • Uwe,
      I don't want to kick off a wave of pessimistic prophecies, and I'm not a PI expert, but my understanding is that there are use cases for which the double-stack option is perfectly valid and SAP doesn't seem to be looking to replace those ABAP-based functions with a Java-based implementation. From what I hear, there is no reason to fear that the ABAP side of dual-stack PI installations will no longer be supported. SAP has made it clear that they don't like the dual-stack architecture anymore but this seems to be a niche use case that will stay.
    • And regarding the Dementors - I keep asking about the relationship between the Mentors and the Dementors but everyone seems to be evading that questions. Is this a separate group or the darker side of our personalities, like Jekyll & Hyde?
  • Thorsten,

    after the kiss, there is a new life picking up the pieces left over from its prior existence, just like in reincarnation there will be something new. SAP does watch its customer base and competition and we may see the dead technology (project, etc) raise from the ashes. before that happens, it's pretty dark out there.

    Walldorf is not any different than Redmond, Armonk, and Redwood Shores and a bunch of other nice IT ego towns. Cupertino is my favorite town, though.

  • Hi Thorsten,
    It was great to meet you and the other SAP mentors face-to-face last week.

    There's many things to consider when a vendor publicly announces (or decides internally) that a given product or release has reached it's end of life and I'd like to look at this from another perspective;  I'll use the R3 46C story as an example.  Due to popular demand, SAP has had to extend the support life of this release several times.  Even when using the stick of additional maintenance charges, many customers have not moved to ECC5, let alone Business Suit 7 (who chose that name ? I can't abbreviate it without laughing). 

    In fact, from the business perspective, it can be very financially rewarding to run an unsupported release of SAP; for a start, there's no maintenance payable.  You do need to retain the technical and business  knowledge to support the older system.  Depending on what other SAP releases you run, you may have access to for unsupported releases, and it frees up budget for other (hopefully SAP related) expenditure.  I don't know what attitude the 3rd party supporters like Rimini have towards this, but I do know that my company (a major SI) will take on support of expired releases of R3 (or older !!) as a quid-pro-quo for getting other business from the customer.

    One of the problems (from an SI perspective) is that neither we (the SI) nor SAP do that good a job of selling the business benefits of an upgrade, let alone the equally useful technical benefits (even if these are not as obviously an area of 'business improvement' as the end-user benefits).  I don't know whether it's bad sales tactics by us (or SAP) or just a desperate measure to avoid recreating a current set of data quality issues in the new release, but I have seen some customers keep the 46C system running, and do a brand new implementation of the newer releases.  Another motivation is that, because they haven't picked up on how fast SAP is changing these days, they think they can sit on whatever the current release levels are for 7 or 8 years again to minimise upgrade costs.  However, I think the users (be they business end users, technical users or in between) would rather see incremental changes, an evolution rather than a revolution 🙂  Further to this, it will be interesting how many 46C customers investigate the new "Gateway" product as a replacement for upgrading altogether.. 

    PS While I've answered this seriously, I must explain the title of this comment; I still look after two R3 landscapes that are running extremely (20th century) old releases of R3.  In fact they weren't even supported by SAP during the Y2K mitigation process.  So, even though Walldorf has pronounced them dead and buried, there are still zombie 2.2 and 3.0 systems pottering along out here .....

    have fun 🙂
    Martin E.

  • Hi Thorsten,
    You definately know how to choose the headlines that capture attention.  If you look at things from a coder's perspective, then I suppose you could claim a project is "dead" once their work has finished. 

    But taking the customer's perspective, utility is much more important than what is the development backlog.  In fact, many of the coders who will tell you a product has no future because their project is done are the same ones who act like a vision has been realized on their first release.

    When a product has reached sufficient utility so that customers can enjoy the benefits of productive solutions, the products will have a long tail of usage.

    As commenters above have correctly pointed out, customer usage and demand is a powerful force in causing extended support or additional development investment. 

    However, as the technology business goes, things do get obsolete, whether its products, architectures, or approaches.  Software companies have to adapt to market changes at the same time bringing incremental and sometimes disruptive innovations to market in order to remain viable.  This may lead to a change in investment in future features, but it does not remove existing utility of a product. 

    To call them "dead" or even "dying" is hyperbolic.  In the market R/3 is hardly dead.

  • Thorsten,
    Although many experiences with a 'Kiss of Death' have nothing to do with SAP - in some cases they do!
    I, for one, cannot sunset something because I want to, or because there is a sexier way to do something, or because there is a new toy I want to play with.
    I need the buy-in from my customers.  And if they choose to do business in such-and-such a way for the next 2 decades, I hope I am around to support them - even if it is not my personal choice. 

    This is a truth - the customer cannot be beaten with a stick to adopt.  The customer can be led, perhaps with a carrot, but whatever the tool, the customer (and no, I am not saying the customers are 'donkeys' at all) will need to move somewhat willingly.  It is our job as their IT professionals to help them like the carrot, not to sharpen our sticks.

    As Greg notes, R/3 is still not dead - a recent survey done by ASUG and many other user groups - around the world - shows that nearly 54% of the respondents were on earlier releases than ECC 6.
    That's just an example, of course, but I think you get the point.

    Thank you for sharing your opinion!!! Always interesting to hear what you have to say.