8 Steps to Safe Daily SAP Releases

[jamesroberts]

How can organizations running SAP achieve the seemingly impossible - Safe, daily releases into production?

I’ve talked in the past about how businesses need to better respond to the demands of the digital economy and how embracing DevOps for SAP can be instrumental in achieving this.

Here I’m going to explore in more detail how organizations running SAP can actually implement the cultural, organizational and process changes required to implement DevOps for application delivery.

Those who’ve worked with SAP as long as I have will no doubt remember the chaos that was generated many years ago when changes went into production every day.  It was carnage.  So Application Lifecycle Management (ALM) processes and tools were put into place to control, govern and audit changes as well as to protect production systems.

We can’t have stability and agility

The bad experiences of the past have made people fearful of change to the point that few can deliver anything at pace.  Overly stringent approval processes kill agility and this is commonplace in many of the organizations I talk to today.

Well we’ve come full circle now and the effect of consumer demand on businesses is driving us to do it fast all over again.

This is going to be a nightmare right?

Actually no because this time we’re prepared.  Processes and tools are here and available to support what we need to do.  The solution is DevOps.  The outcome is fast AND safe.

The business case is far too strong to stay with traditional ALM and long release cycles.  Of course, I’m not saying that everyone should be looking to move to daily releases but I’ve witnessed many great examples of customers moving from 6-12 month cycles to monthly and weekly releases.  They could release daily if they wanted to and the fact that they don’t is largely down to culture.

Where do we start?

I’ve spoken to a dozen or so organizations over the last few weeks who want to start working at pace but don’t really know how to start.  The words agile and DevOps come up a lot but they’re unsure where to begin.

So if you run SAP today what can be done to move to a faster, better, safer way? 

Here are 8 steps that can be taken to implement DevOps and massively improve IT delivery.

1. Increase deployment frequency

Switch to smaller and more frequent release cycles first.

Delaying releases to 6-12 month cycles causes huge delays in the delivery of new functionality.

Focus on moving towards weekly drops of fixes and small changes and monthly drops of larger changes rather than bundling things up into big projects.

2. Organize teams around projects and products focussing on business outcomes

Make business process owners into product owners and start small.

Giving them ownership of products and projects promotes a deeper involvement in the full development lifecycle and allows input into design, QA and delivery.

But don’t try to do this for everything.  Get exec and management buy in and start small with a specific project.  Learn from mistakes and continuously evolve the process.

3. Evolve to Agile

Focus developments on business outcomes and working solutions.

A switch to agile involves the creation of cross functional teams where collaboration and communication is fundamental.

Create a planned and prioritized backlog where requirements are described as stories that produce business outcomes for specific personas.

When requirements are broken down into smaller manageable chunks they can be delivered in short development cycles.  These aim to deliver working software quickly but also support scope changes.

4. Shift Left QA and operations

Engage QA and Basis from the beginning.  No silos = No surprises.

Traditionally QA and Basis teams operate as distinct functions with responsibility across many projects and products.  Including QA and Basis into project and product teams ensures that every function in involved in the development lifecycle.

Shifting left QA and operational involvement to start as early as possible in the process ensures that there are few surprises later.

5. Streamline approvals

Make approvals slick and informed so they don’t kill the process.

Most people would agree that they want a robust approval process to control and audit the changes being made to SAP systems.  The issue is that the process often adds unnecessary delays and the approver doesn’t understand the risk and impact.

Having a slick process where approvers and testers are informed as soon as they need to take action means less waiting and a slicker development process.

Shifting left and automating quality, risk and impact checks into the process provides the approver with contextual information about the item being approved and its dependency on other changes.  The approver can then make a conscious and informed decision as to what to do.

6. Automate everything you can

Manual processes always introduce delays and errors so replacing these with automation is a no brainer when speed and quality are a key factor.  So automate as much as possible.

Continuous integration involves the automation of unit testing and the build pipeline.

Continuous deployment involves the automation of change deployments into downstream systems.

Both processes require SAP specific tools that support the required components but also require a shift in mindset and development methodology.  What it does is create a streamlined development process where problems are identified early and where human error is massively reduced.

7. Create the right QA environment

Continuously refresh QA with production data and config.

To allow the DevOps processes of continuous integration and deployment and the automation of testing activity it’s vital to have the correct SAP environments available at all times.

Everyone would agree that they want to put live exactly what they built and tested.  That only works if the environments made available for build and test reflect what production looks like.

8. Integrate change management

Understand the implications of changes across applications and at an organizational level.

The pace of SAP change is often disconnected from the pace of change of other applications. Changes to Systems of Engagement need to happen quickly and frequently to respond to consumer demand but related changes to SAP are disconnected and slow.

Release cycles across pace layers need to be synchronized so SAP changes can be connected and delivered in-line with other non-SAP applications.

It’s not a threat, it’s an opportunity

Any transformation is a journey and these steps will take time and an open mind to come to terms with.  Whether you choose some or all and how fast you go will depend on individual circumstances, but the results and benefits that can be realized are clear.

It’s about making continuous marginal gains that add up to substantial improvements over time.

Yes, DevOps for SAP is different.  Common tools used in the non-SAP world don’t work with SAP so you need tools that both understand SAP but also to allow you to be agile.

But along with speed comes protection of the crown jewels.  As I said at the top you need to be both fast and safe to make your systems into an active enabler for your business goals.

And this is where I see DevOps processes transforming SAP change delivery.

I’ve also published a white paper on this subject so to find out more about the background and the 8 steps to success please download it here:

http://www.basistechnologies.com/DevOps-8-key-steps-to-daily-SAP-releases-accelerate-pace-of-changes...