Within organisations sailing under the SAP flag IT is often bound to a rigorous release schedule. Typically such waves or release cycles are long, not seldom three months or even longer. To hold and improve market position enterprises target to build the right product, accelerate time to market and improve overall customer satisfaction. The software engineering methodology Continuous Delivery (CD) targets on building valuable software, using short cycles, ensuring stable software can be packed and shipped at practically any given time.
We release our software once a week, and when needed immediately.
Ivan Mans, ABAP-Experts.com
Head of Software Development
Continous delivery may still sound like an odd marketing statement in the area of SAP while it became the defacto standard for i.e. app development. Looking at developments executed on a pure SAP© ABAP system, many organisations seem to be stuck in dinosaur age.
Developed in the 1980s, the Advanced Business and Application Programming language has evolved a lot and so did we. Using our experience we have developed methodologies and tools to enable enterprises of all size to continuously deliver quality stamped SAP© software.
A short story that tells you why.
Why do organisations decide to shift towards continuous delivery? This fictitious story may tell the answer to that question:
The marketing department of an organization has realized that the count of visitors on their website has been growing enormously. A new registration process should attract potential customers to submit their name and contact details and directly interface with SAP CRM©. The intent is to gain more customers and increase the revenue.
Shortly after the change request has been submitted to the development department the realization completed. After deployment into the acceptance environment the renewed registration process has to be tested. During the first test cycle, an error was identified. Meanwhile, the original developer was working on a different requirement which caused some lead time for the error to be resolved. Due to a manual testing process not all errors could easily be reproduced whilst others even revealed shortcomings in the applied testing procedures. Now it was time to promote the delivery into production. The production deployment was a complicated procedure. All changes that have been tested and signed-off successfully will be moved in a specific sequence during night/weekend.
During production deployment an error occurred which had to be analysed by the expert team on an emergency callout. The team had a hard time fixing the problem due to complexity originating from a high number of dependencies. The next business day the environment was still not released for productive usage. At that time the team felt stressed - every minute of downtime translates into loss of revenue, not even counting the negative perception any downtime creates.
The point of no return has been passed already - rollback to the previous stable version was no longer possible given the time needed to restore. During the day, a special task-force could finally identify and eliminate the root cause of the problem. Shortly after both the website and its SAP CRM© integration were brought to live.
The root cause analysis summarized that a configuration transport was missed for production deployment which was directly responsible for bringing CRM usage down. During the downtime of the website not a single client could register. Summarized, the envisioned process improvement painfully resulted in the opposite, sales opportunities where missed instead of created.
Measures that help
- Deploy at a higher frequency, when needed multiple times a day. A new feature can be promoted into production shortly after it was successfully tested.
- Timely testing Coding errors will be identified earlier and the developer is still available to fix the problem.
- Deployment becomes a habit. More frequent deployment quickly translates into a habit. Tasks can be automated. The release process becomes stable and solid.
- High deployment frequency reduces complexity. The release is executed across smaller portions and, therefore complexity benefits. The smaller the stack of hay the easier it becomes to find a needle.