Skip to Content

Should SAP do 90 day release cycles?

Innovation needs to get to customers before it is too late – else its value will diminish. This has not exactly been SAP’s strength historically, but from what I heard at the Boston Run Better Tour – SAP is very confident that they can get products out on a quarterly schedule.This is definitely a positive sign, considering SAP wants to be a big player in the on demand world.


On first sight – this is a terrific idea. But I do have a few concerns as well.


1. Publicly traded companies live quarter to quarter. Quarter end is the most stressful time there with every one running around like crazy to finish the quarter in a short window. Does it make a big difference really if an invoice is paid on July 1st instead of June 30th? well, no if you are not answerable to the analysts and yes if you are answerable. I would hate to think software developers get into this mania to beat artificial deadlines. And will analysts penalize SAP’s stock if they miss a quarterly release schedule?


2. What about quality? If you are forced to release every 90 days – you will typically get a month at most for testing. For a system as complex as SAP – I find it hard to believe that good testing can happen in that time, at least for first couple of years. 


3. How many features will go into a release? Will developers try to sandbag, and put very little into each release to make sure they are comfortable with the quality of code they are releasing? Or someone could feel the need to be a hero, and try to overdo what goes into a release, and end up in a quantity beats quality scenario. How long will it take to strike a balance?


4. Do customers really want something new every 90 days, even in the on-demand world? In the on premises world, I don’t know any one who wants to upgrade every 90 days. In on demand world, maybe this is less of a problem. But a certain amount of non-disruptive nature needs to be built into the live updates. Turbotax can change every year – I don’t care all that much because I only need to use it once a year. I would be driven nuts if Yahoo email changed frequently, since I need to use it every day. If a sales order screen changed every 3 months, I am not sure how many people will like it either.


5. When you raise OSS notes, will we start hearing “just wait another quarter” as default answer?


6. How will certifications work? will u get certified on the Quarter 3, 2011 version of a module?


7. How will pricing work? Should customers buy every release? can they skip releases that offer things they don’t like? Will there be a switch framework kind of thing where we can choose what to accept?


8. How much advance notice will customers get for each release? If a certain release needs training or major change management, will they get enough time to get to that? and will they (and their consultants in case such help is needed) get enough training to be prepared for what is going to hit them?


I maybe totally off-base here – and will gladly stand corrected if some one explains the right way to think about this.

You must be Logged on to comment or reply to a post.
  • I think it’s really important to make a distinction between the Business Suite and “edge”, on-demand, and SME releases. For the Suite, or apps/tools that have extensive Business Suite dependencies, I don’t think 90 days is realistic in the near future. Nor do I think that is what SAP is aiming for. Think “Business Suite Innovations 2010” for a recent example that did not pan out schedule wise.

    However, for on-demand release cycles, I believe 90 days is the release cycle to aim for and for SAP, this may well be doable. SAP has been getting ByD updates out every six months now pretty reliably, give or take a month. It won’t be easy for SAP to get most of the on-demand apps onto 90 days cycles but I don’t think it’s unrealistic. And I do think it will help SAP in the market if it can get into this rhythm.

    For what it’s worth, my impression from the Boston event was that the talk of 90 day release cycles was more about on-demand products than the Business Suite. Someone from SAP may be able to clarify. That would make a nice blog. 🙂

    – Jon

    • completely agreed that this makes more sense in on-demand world, Jon.

      I understand that SAP is now hitting its stride with 6 months releases – but ByD has such a small install base, that maybe my concerns are no big deal. Assuming it scales big time – and I hope it does, I would probably still have the concerns I listed above.

      • Vijay – I could also see SAP focusing on quarterly releases for packaged analytics apps. If ByD does scale to the point that there are 10,000 or 20,000 customers – well those are the kinds of problems I suspect SAP would love to have. 🙂

        Sometimes SAP takes too much of a hit for being cautious with new releases and doesn’t get enough credit for rigorous testing and reliability of the transactional core.

        Having said that, there are tradeoffs all over the place and you raise some points SAP would have to keep firmly in mind with accelerated releases.

        The problem I see right now, however, is that you go to these SAP shows and rarely is there a General Availability product to talk about. Most of the stuff people really want to talk about is in rampup, so folks leave these events without enough information, particularly around pricing. SAP is aware of these issues…and Dennis Howlett’s point on the 90 day release cycles could help to reinforce more of a message of generally available products rather than always looking ahead to products later in the calendar year.

        Maybe if we blow up the comment thread enough we’ll get SAP to chime in. 🙂

        • Jon, Vijay,

          I think the Ramp-up vs. GA distinction is a key point. If you listen to keynotes at SAP events, you hear about a lot of great products, but the vast majority of these are either in development or in Ramp-up. Very few are GA.

          GA is the keynote kiss of death 🙂

          I think the 90 day number we have been hearing was with reference to “start of ramp-up”. So SAP is probably talking about a 90 day cycle prior to ramp-up for on-premise software and a 90 day cycle prior to beta-testing for SaaS solutions. That’s just my speculation, but it’s based on hearing the 90-day comment from Vishal and also hearing him talk extensively about software and hardware SAP has “delivered” but which are clearly still in ramp-up (BW 7.3, HANA 1.0, and BI 4.0, for on-premise, and Sales on Demand as an example in the SaaS space).

          I think SAP hurts themselves by focusing so exclusively on software that is not yet generally available. People spend time watching these sales events and hopefully come away wanting to buy software, but when they try to buy it they are going to be thrown into the confusing world of ramp-up.

          More to the point, I would carefully watch ramp-up durations to make sure that they don’t expand to encompass the time shaved off of the development cycle. The key metric from both customer and financial perspectives is time-to-GA.


      • Vijay, Jon

        My impression also was that the 90 days were for On-Demand rather than on-Premise.

        Whilst I would like to see shorter release cycles, I can see Vijay’s point about real customer appetite for ongoing release cycles. In the on-premise world we call that “upgrade fatigue”.

        Also, what happens if a customer decides not to go for the latest release? I’ve mentioned the problem of customer lock-ins before. It’s great when you can hop onto an on-demand product, but what if you don’t like the new features anymore and then decide to move away from it? How easy is it to move away?

        Another question that only time will have an answer to is: Will these leaner and agile devs such as Workforce Planning with a smaller initial functionality offering have what customers want? In other words: will customers be willing to take a hit now for the sake of quick delivery and then hope the functionality comes later?

        I don’t want to talk the shorter release cycles down, because I’m all for the innovation. But they do come with downsides and customers have to be aware of them.


        • That’s my understanding as well: short cycles for on-demand and BAS applications. Besides shorter development cycles, I am curious what is SAP target for sales cycles?
          All in all, the mantra is “time-to-value”. It should not be just reduction of the development cycle for “something”, but for “something that gives customers the value”.
    • “4. Do customers really want something new every 90 days, even in the on-demand world? In the on premises world, I don’t know any one who wants to upgrade every 90 days. In on demand world, maybe this is less of a problem. But a certain amount of non-disruptive nature needs to be built into the live updates. Turbotax can change every year – I don’t care all that much because I only need to use it once a year. I would be driven nuts if Yahoo email changed frequently, since I need to use it every day. If a sales order screen changed every 3 months, I am not sure how many people will like it either.”

      Yes, especially in the On-Demand world. 90 days is in fact too long. Most start-ups who tailor their businesses to other small businesses are pushing updates by the day. Some examples:

      Google Chrome, they update every 6 weeks:

      Ggoogle maps: Look at all of the updates done in May 2007 within a two week timeframe!

      Yahoo mail? They probably update way more often than you think. The difference is that they incrementally do it without you noticing and they only push functional updates that don’t disrupt. If they are disruptive they are so small that your behavior isn’t hindered. Gmail did this tirelessly. They added voice, video, tabs, sorting, etc, etc. all without confusing the user. The innovation pace has been astounding. Also, if you look at the likes of Salesforce, 37signals, etc they all push updates very quickly, you just don’t notice them. As the software has matured, functional updates are most likely quite less but bug fixes are pushed all of the time. In order to make a truly great product SAP needs to “quiet the lizard brain” (

      This is the underlying problem with SAP ByD. It has no understanding of how small businesses operate. Big ERP = fit the process to the software. Small Biz = fit the software to the process. Not to mention there is a huge lack of user experience focus and understanding for ByD. This is why SAP hesitates to push anything quicker than 90 days or heck 180 days. What if the sales order screen changed every 2 weeks so it made the person think less? The release cycle discussion becomes arbitrary.

  • Vijay,

    Good point, but I think in the on-premise world, if the enhancement packs could be delivered in 9 months from start to GA, it would be great.  I would even take 12 months.

    The traditional release cycle has looked liked:
    Developed in 2009,
    Rampup in 2010 with release in Q2 2010(if you are lucky).
    Implemented by GA customers by Q4 2010. 

    That’s 24 months from idea to actual mainstream use.   By the time you have the late adopters it could be three years from the initial start of development, before it is used.

    I don’t know what the solution is because obviously applying EHP every year is not ideal and almost leads to needing to have everything new be on the edge in order to stay current.

    Take care,


  • @vijayasankarv,

    i come from a different angle when thinking about 90-day releases. in my book, it conforms to the rest of the business world that runs in quarters, especially with analytical applications. it’s the next reporting frequency down from annual and up from monthly. the sales planning, expenses, and budgeting follow closely.

    hey, banks like to do it daily and they are the biggest kahanas out there.

    @greg_not_so (no tweet)

    • yes – rest of business runs by quarters, but we also know the crazy stuff that needs to be done at quarter close. Also – the types of things done at quarter close are repetitive – and large part is mechanical. Software development is not exactly mechanical. So is it a good fit?