Shouldn’t we have put the Science of DevOps before we put the Art? In many cases, yes, but not when you are dealing with large SAP programs.

Why? Join us in this fascinating journey through creating and executing a DevOps roadmap for a multi -million $ SAP program, and find out why.

The program is currently structured in a traditional Development and Support model. The driver for DevOps is a need to be able to fluidly manage the demand funnel without the current rigid boundaries, increasing responsiveness and flow.

The authors partnered in applying a DevOps maturity model to the program, and came with against this:

  • “This stuff may work else where, but this is SAP”
  • “SAP already does what you want”
  • “Branching in SAP? Haha! How can you do DevOps?”

This session will cover the model, the analysis approach, its application in a SAP specific program. And you know what? It is indeed true that SAP DevOps needs some changes to account for how the SAP product is structured, and its ways of work.

To those wondering how SAP DevOps isn't just regular DevOps, here are just some examples that make SAP DevOps more interesting:

1. Continuous Integration is hard to achieve, as there is no separate build process, activation is the build.

2. No access to binaries.

3. Rollback of transport requires significant effort.

4. Concurrent development hard to achieve as the SAP version control system uses locks.

5. Manual retrofit of the changes to the same object.

6. Difficult to achieve on demand infrastructure.The costs and lead times to provision and manage SAP environments are relatively high.

7. Tight coupling of multiple modules.

8. Missing strict enforcement on the workbench for the errors, only guidelines available.

But the real Art is in being able to demonstrate to a skeptical group of SAP specialists that DevOps provides value, not matter the platform.

Join us to find out how.

 
1 favorite thumb_down thumb_up 2 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist
 

Outline/structure of the Session

  • Current state of the SAP program
  • Drivers for change
  • Resistance to change
  • Model applied for analysis
  • Resistance to change (redux)
  • “You can’t do that in SAP”
  • Phased Roadmapping, quick wins.

Learning Outcome

Participants will come out of the session with a clear understanding of how DevOps differs in an SAP environment, and how DevOps can be introduced in a phased manner in a SAP program.

Target Audience

Attend if you are interested in DevOps, especially in the Packaged Solutions space. If you want ideas on overcoming resistance, come join us!

Prerequisite

We just need a keen interest in DevOps, and how DevOps is being applied in various situations. SAP knowledge not necessary - the challenges are universal.

schedule Submitted 1 week ago

Comments Subscribe to Comments

comment Comment on this Proposal
  • Leena S N
    By Leena S N  ~  1 week ago
    reply Reply

    Hi Avinash,

    Can you emphasise more on why this is different than any DevOps adoption or implementation? I think that will be the question that audience also will have.

    What might be easier for the audience to connect will be to convert to an experience report highlighting your learnings. If you agree, can you change the proposal outline to reflect more as an experience report? Also, provide the slides for the talk.

    Thanks,

     

    • Avinash Rao
      By Avinash Rao  ~  1 week ago
      reply Reply

      Hi Leena, 

      We have updated the Abstract section to address the 'isn't SAP DevOps the same as any DevOps?' question. Also, as suggested, converted it to a experience report.

      Thanks!