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.