Skip to Content

Square One

Take SAPPHIRE NOW and SAP TechEd in Las Vegas, Bangalore, and Madrid this year talking with customers, partners, analysts, bloggers. Add to it many internal conversations here within SAP. What you end up with is the certainty that there is enormous interest in today’s SAP NetWeaver and the strategy how we evolve it into the realms of In-Memory, Cloud, and Mobility. All the feedback we get leaves you with the strong impression that our innovation strategy resonates very well with our customers and partners, and our products and solutions are evolving in the right direction.


We seem to be addressing the right needs, adoption figures point into the right direction, feedback from customers gives you a great day. How come? 


Now while I am not a radical believer that “the right process will yield the right results” by default, you can pretty safely bet a month’s salary on the fact that “the wrong process will rarely yield the right results” — if only for statistical reasons. So besides seeing that apparently we are “doing the right things” for our customers and partners, I am very happy to see that probably this is also related to us in NetWeaver R&D “doing things right” and very differently compared to former times. Actually, I am absolutely convinced about this one. But who knows about this outside SAP?


This is why after being back in the office after “TechEd season” an indefinite and urgent feeling kept creeping up at me suggesting to start a blog around new SAP NetWeaver releases, products and innovations, and how they actually link back into our working mode and processes, how we do Lean Software Development, drive innovation together with customers, continuously improve our internal workings. Hopefully, this will give you some more insights and perhaps even trigger some dialog and discussions about further directions and enhancements.


Three weeks ago there was an event on my calendar that I wanted to take as an opportunity to share some more background information in this first blog post (tada!) with you: We shipped SAP NetWeaver 7.31 into ramp-up as planned on November 21st.

SAP NetWeaver from Inside

What many people don’t know is that we — SAP NetWeaver R&D — went through a massive change in our development processes and methodologies since NetWeaver 7.0 (or 2004s as it was called originally) was released to the market in 2005. In 2008 we started in NetWeaver R&D to completely change our processes towards Lean Software Engineering and adopt Agile Software development methodologies like Scrum, XP, TDD and others. An excellent reading, by the way, and one of our Bibles in this endeavor was “Scaling Lean and Agile Development: Thinking and Organizational Tools for Large-Scale Scrum (Agile Software Development)” from Craig Larman and Bas Vodde (available at your favorite retail bookstore). It was and is a very systematic change that has in the meantime been applied to all of R&D at SAP.


Putting the customer first and having our development processes actually aligned around this has become a primary objective. In order to understand the magnitude of change, you have to know that we talk in my unit alone about 2000 R&D folks working in 7 development locations all over the world (Germany, India, Bulgaria, Israel, US, Vietnam and Norway) not counting the neighboring functions in Solution Management, the Field organization, Support et cetera. So changing towards Lean and Agile has not been trivial and required considering scale and complexity of organization, processes and products from the start.


If I compare, where we were in terms of SAP NetWeaver product itself and our development processes to get to the solution back then and put it in relation to today, we have come a long way: We’ve significantly cleaned up our product architecture and reduced dependencies. We’ve aligned behind a single, simple, agile and still scalable approach to development following Scrum “by the books”. Team empowerment was (rightly) valued over formal micro-management and micro-governance. Customer engagement became central. Continuous Improvement in the Lean sense has become a systematic activity integrated into the DNA of the organization (perhaps I should write a separate post on this one alone). We have a highly reliable release schedule. Portfolio cycles are short and relatively painless. Development phases are tact-based with ongoing integration and “working software each tact” is the ambition as our deliverables are being consumed continously by internal stakeholders or – where possible – validated with customers.


As a result, now we can reliably deliver a new version of the SAP NetWeaver components underlying SAP Business ByDesign every 6 months and we can reliably deliver an Enhancement Package size SAP NetWeaver release every 9-12 months to SAP Business Suite and our external customers. This is indeed a different organization and process behind the SAP NetWeaver platform compared to 2005. I can still remember a several months long portfolio cycle for a 7 months SAP NetWeaver development window, happening once in the darkest of the “old days”: The release was preluded by “shootouts” with our internal stakeholders mainly debating with us for which of their thousands of “high prio” requirements that we couldn’t commit on we hadn’t understood the meaning of “must have” or “showstopper” priority.


The release then ended up in an 11 months development phase with a 4 months delay beyond plan, only 70% of the initially 30% of committed features were finally delivered (what a surprise?), and quite a significant number of them was not even remembered, or needed or “consumable” by our internal stakeholders any more at that time. That’s when you as an R&D organization get the strong feeling that something is fundamentally screwed up and that there must be better ways of doing things. That’s when we started to turn things systematically around. Going back to square one.

Three years later:

SAP releases SAP NetWeaver 7.3 into ramp-up in November 2010. As planned. A smooth ramp-up follows. NetWeaver 7.30 goes Generally Available (GA) in May 2011. As planned. Only 3 months later already 180 customers have gone live on the new release, 2 more months later it is already 350+ live customers. 

On November 21st, 2011, SAP releases SAP enhancement package 1 for SAP NetWeaver 7.3 in ramp up, the first Enhancement Package to NW 7.31. As planned.


While it is still too early to declare our NetWeaver transformation as completed, I am confident that we have set ourselves up for the challenges to come. We’re meanwhile working on our JPaaS on-demand platform (sometimes referred to as “Neo”), massively built on open standards and open source, running our own agile software development infrastructure and processes on top of JPaaS itself, “eating our own dog food” so to speak (not literally ;-). We’re releasing it in 3 months release cycles. And we’re engaging with our customers and partners on an ongoing basis and also early on during the design phase.


In retrospective, if you would ask me about three key statements regarding our Lean and Agile transformation in SAP NetWeaver, I would settle on those three:

  • First, it requires a sense of urgency with everybody involved to get it started and an enormous energy, will and endurance of the whole organization not to get stuck in between.
  • Second, it works at large scale if you do it right.
  • Third, it leads to better software for your customers.
  • Finally, it is simply more fun doing things this way.
  • Last but not least, it is impossible to explain why you have ever done things differently.
  • To wrap it up, don’t expect miracles overnight.
  • And most importantly, all of the credit and kudos goes to all the people of our organization who made it actually happen. The change would not have been possible without their strong, impressive, creative, pragmatic, idealistic, forgiving and fearless engagement.

“I came to see, in my time at IBM, that culture isn’t just one aspect of the game — it is the game. In the end, an organization is nothing more than the collective capacity of its people to create value.” [Louis V. Gerstner, Who says elephants can’t dance?]


Interestingly, I had the opportunity to talk to Sam Guckenheimer and Brian Harry from Microsoft Development Division a few weeks ago discussing development processes and methodologies. It was enlightening to hear of the many similarities that Microsoft and NetWeaver were sharing back in 2005 from a customer base, product history, organizational setup and product creation process perspective and how both our companies tackled them systematically and often with surprisingly similar approaches. There’s a book from Sam that I would like to recommend – in particular chapter 9: “Agile Software Engineering with Visual Studio” [Sam Guckenheimer, Neno Loje] (also available at your favorite retail bookstore). But that topic is probably worth a posting by its own….


I hope you found making it through this blog worth your time. It turned out a bit longer than I originally planned. Sorry about this one. I would be more than happy to get your feedback on Twitter (@_bgoerke) or as comments directly here whether this blog is valuable to you and if there are topics you would like to get more information on.


Björn Goerke | Technology & Innovation Platform Core

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

    Interesting thoughts and insight into the transformation process at work in SAP R&D. In some ways you are almost outstripping your customers ability to absorb this change.To be able to utilise these new capabilities that are delivered with a sense of endemic urgency across SAP, customers need to transform too. The JPaaS area is of great interest,  keep up the insights and updates on NW EhP updates.


    • Hi Paul,

      thanks for the feedback. Yes, we're aware of the fact that release cycles are something to carefully consider: don't be faster in delivering than your customers can consume your innovations. It turns out that this drives your thinking specifically to the question on how non-disruptive or smooth the step to the new version has to be. Which is a good thing. It makes you think about the different life cycles and innovation cycles of certain software solutions at the customer side which e.g. makes you decouple your innovations in the User Interface area from the backend (why would you want to upgrade an ERP just to get a new UI experience?). So we're turning things around here.
      JPaaS/"Neo" as a Platform-as-a-Service offering of course creates completely new possibilities. A nice example: Gravity, our collaborative, on-demand Business Process Modeling solution running integrated into Streamwork, was 24 hours after a successful Takt review (happening after each Scrum Sprint) pushed through QA and put live on the Cloud. Another 28 hours later we had positive, first customer feedback about the new features. That's the new SAP...
      Will keep you updates in future blog posts...

      Regards, Björn

  • I won't ask about what happened with innovations 2010, but rather how did you adapt Agile methodologies when having teams that do not exist in the same physical locations?

    I think for those us working as part of global teams would like to know how to overcome the Agile dogma that everyone needs to be physically located together. 

    Take care,


    • Hi Stephen,

      As with all dogmas, you better turn them into best practices or basic ground rules that may have exceptions if there's a good reason.

      In my unit, we have 240 teams in 7 main locations of which 13 teams have members being spread across locations. This is typically the case when you need someone in the team to be close to your stakeholders, partners, customers etc.. Sometimes, you value a certain unique skill set of a team member over the disadvantage of communications overhead due to different locations. And sometimes there are even contractual reasons that a certain employee is located in a certain location different from the rest of the team. Not ideal, but this is how reality looks like.

      As long as the co-location is the rule and the distributed setup is the exception, I wouldn't worry about it too much. With 95% of teams being co-located and 5% being distributed, we've been doing pretty well so far.


      P.S.: Regarding Innovations 2010 -- as said, miracles don't happen overnight and Business Suite started the Lean/Agile transformation later than the NetWeaver organization 😉

  • Hi Bjorn,

    great to have a voice on SDN coming directly out of Netweaver management. Since this is Christmas time I'd like to send one wish to you guys: please add CHROME SUPPORT to your next NW release. Some prevailing reasons: Chrome has passed Firefox in adoption (,
    Chrome has been found to be the savest browser ( Many customers demand it, many forum entries here on SDN dealing with it and pointing to the PAM list, which says it's not in place yet. So, it would be a great deal if SAP could bring this to work and hopefully downport it.


    • Hi Ulli,

      I didn't consider myself being Santa Claus yet, but nevertheless: we support Chrome already with our HTML5 technology (SAPUI5/"Phoenix") which is used in some of the products currently in development at SAP. For the rest of our UI technologies, in particular Web Dynpro, Chrome support is high on the ranking list for things to be put into the next NetWeaver release (all the usual disclaimers appy! This is not a feature commitment!).

      Merry Christmas,

  • Hi Bjoern,

    thank you very much for sharing your experiences from deep inside the SAP development organisation! From a customer's perspective, the changed approach is clearly evident.

    For example, we participated in customer validation testing for FEH/ECH and this was of tremendous benefit to us as it informed our direction forward which one project has already implemented.

    Like Ulli, I also have one wish for Santa: Share what you are doing more formally with customers - especially those management types who might not see every blog on SDN.

    The majority of customers still apply waterfall approaches to their SAP projects and adhere to ASAP or other methodologies under which their systems were first implemented, even if other parts of their IT departments already use smarter approaches!

    I was also quite disappointed when I saw the updated ASAP methodology presented at TechEd 2010. It was basically the same old stuff with a thin coating of some agility - a far cry from the "by the book" application of agile methods espoused by you as a key learning.

    SAP could also have an opportunity here: Divert maybe 10% of the attention budget from some of the recent acquisitions and use it to educate customers' IT management about how SAP was able to speed up their development cycles while achieving better quality.

    With a bit of luck, this might help customers to speed up the pace at which they can absorb SAP's innovations, and this might in turn make them buy more from SAP 😉

    Anyways, just a thought. Many thanks for sharing!! I'm looking forward to the next one.


    • Hi Sascha,

      thanks for your feedback. I agree that the application of agile and lean methodologies can definitely go beyond SAP internal R&D. We are one by one looking into the various functions here in the company. What started in R&D, spread into adjacent Solution Management, Quality Assurance and Validation, now finally makes it into functions like HR and Controlling... Slowly progressing...

      We were considering to e.g. externalize our own development tools & processes we use e.g. for JPaaS/Neo development (Jira, Grasshopper, Maven, Hudson, Sonar, Git/Gerrit, etc.etc.) also to partners and customers for their own agile/Lean development. Need to spend some more thinking about this first, but with JPaaS hosting these tools already today for our own dev process, why not turn this "public"? We'll see...

      Best regards, Björn

    • Hi Sascha,

      thanks for your feedback. I agree that the application of agile and lean methodologies can definitely go beyond SAP internal R&D. We are one by one looking into the various functions here in the company. What started in R&D, spread into adjacent Solution Management, Quality Assurance and Validation, now finally makes it into functions like HR and Controlling... Slowly progressing...

      We were considering to e.g. externalize our own development tools & processes we use e.g. for JPaaS/Neo development (Jira, Grasshopper, Maven, Hudson, Sonar, Git/Gerrit, etc.etc.) also to partners and customers for their own agile/Lean development. Need to spend some more thinking about this first, but with JPaaS hosting these tools already today for our own dev process, why not turn this "public"? We'll see...

      Best regards, Björn

      • Hi Bjoern,

        great idea, and something which I would definitely welcome!

        If SAP were to openly share their development methodologies, tools and (at a high level) processes, it would surely help customers be more efficient in their work with SAP software - a win-win for all!