sap release orchestration - delivering change at pace

basistechnologies.com

A Basis Technologies white paper

SAP Release Orchestration


If you’re an IT leader or manager, you’ll be familiar with the concept of doing more with less.

But what strategies exist to help you cope?

Read more >If you run SAP – there are eight things you can do to dramatically improve your Requirement-to-Release process and improve your competitive advantage.


4 important things that benchmark SAP customers know about SAP release management

http://basistechnologies.com/




Despite technological advances in the last 10 years resulting in better, faster and prettier IT solutions, technology is still notoriously hard to deliver on time and within budget.

But IT departments have been plagued by a decade of challenge to deliver change at pace at the same time as radically challenging their delivery models to reduce costs and maintain quality.

In this whitepaper, we deal with the complex challenges associated with delivering change to SAP solutions at pace, on time and on budget alongside a backdrop of outsourcing, offshore delivery, cost constraints and increased complexity.

A good CIO will tell you that a well- managed ERP solution such as SAP is fundamental to the competitive advantage of their business. The business processes that it delivers are not only core to the way the business runs but also core to the delivery of new business models, pricing strategies, strategic analysis of information and so on.

So, if you want to keep your business at the cutting edge of your industry, you need to work out how to deliver change to your SAP solution at pace.

Delivering SAP change at pace




The way in which SAP changes are made and migrated between environments – whether code or configuration – is notoriously complex. SAP’s Transport & Correction concept wraps up each change in its own container and enables that change to be migrated from Development through Test into Production. If there were one change at a time, this would be a simple process but most SAP customers have hundreds of concurrent, discrete changes to migrate through their landscape at any one time – with dependencies on each other, the risk of code overtakes, the need

to approve each change and little offered in the way of ‘out of the box’ management tools.

When SAP was plain old R/3 in the 90s, this was workable. But since the addition of ‘new dimensions’ products such as BW and APO, followed by the move to non- ABAP languages such as Java and the proliferation of middleware platforms, the standard tools available to manage SAP change have fallen behind the curve.

SAP is complex and isn’t getting any simpler




Managing development for a single project or a greenfield implementation is relatively ‘tame’. The reality that most SAP customers find themselves in is one of managing multiple, parallel development and test tracks into their SAP production systems. This enables business as usual change and larger projects to run independently at different speeds to each other without compromising integrity.

At some point though, configuration and code does have to be re- combined into a single definitive library and all development systems need to fall back into sync. Managing this process rigorously and in real- time (e.g. identifying when developers across multiple projects are working on common objects) is critical.

The net result is that many SAP customers often need to manage code and configuration consistency across 30- 50 different environments and in complex implementations, well over 100 SAP environments.

Development at pace requires parallel development




Working with these challenges is difficult even if you can look your developers in the eyes in a single building – moving to outsourced or offshore development adds another layer of administrative, management and cultural complexity.

Executed well, outsourcing brings with it rigor and clarity of remits between you and your outsourcing partner. But how many stories do you hear of well- executed outsourcing?

In reality, outsourcing introduces management overhead, complexity and often confusion during the early bedding down phase.

Add offshore delivery to the mix with language barriers, time-zone hurdles, cultural differences and staff retention problems - and the likelihood of a slick development operation for most organizations is far from a reality.

Outsourcing & offshoring makes development harder

Many organizations offshore expecting a 1:5

labor arbitrage benefit also suffer a 4:1 rework ratio –

meaning that the number of times that developments

iterate through the development lifecycle effectively cancels the benefit in outsourcing.

Labour cost benefit

vs. Re-work costpenalty

4:11:5




SAP development is an expensive business

Even at offshore rates, SAP development is in the top cost quartile of IT skills and has been for two decades. Demand continues to be strong – with the largest market share for large enterprises and a product development and acquisition strategy that is continuing to drive license sales.

Running SAP therefore comes at a price and CIOs of SAP customers are more likely than anyone to be under pressure to reduce costs, increase efficiency and deliver to budget. The solution to these challenges lies in a highly orchestrated Release Management process – designed specifically to balance visibility and control with pace and agility.

According to Gartner, 66% of the cost of running

an SAP system relates to staff costs.

10%Hardware

24%Software

66%Staff




Best practice implies that somebody knows best – that one party has decided what’s best for everybody. The default position is usually SAP Best Practice – leading most SAP customers to look at SAP’s recommendations and tools to solve this challenge. But SAP doesn’t really run SAP.

Rather than look at Best Practice, it makes much more sense to look at what is Practically Best – what do experienced organizations who run complex SAP systems do?

What best practice is available?




The most prominent aspect of orchestrated SAP release management strategies is that they are designed to deliver a business outcome. It is easy to design a change management process with the necessary checks and approvals that address quality control and compliance objectives. But often, processes designed to cope with the approval of single ‘transactions’ (e.g. changes) become log-jammed when faced with a real-world volume of transactions.

Orchestrated SAP release management often focuses on agility or pace of change first and foremost – leading to an SAP environment strategy and release model aimed to deliver changes and projects in a flexible way. The necessary approvals and compliance are then built in on-top of a sound underlying strategy.

Creating a structured Release Model – with a number of fixed releases per year – is the goal of efficient release management. This enables build and test cycles to be run as discrete, repeatable

events. But sometimes, forcing this model is not what is best for the business – especially if release cycles mean that urgent requirements are slowed to the pace of the longest release cycle.

Whereas SAP best practice often recommends no more than two development environments (one for business as usual and one for projects), Practically Best typically means three or even four development paths to enable different projects to move independently at different speeds.

SAP best practice locks changes and prevents developers from working on them concurrently; leading to situations where critical production fixes cannot be introduced because objects are locked in a project that won’t go live for months. Practically Best allows developers to work on common objects but dynamically monitors where this is happening so that changes can be combined later in the test cycle or even after the release of the first change has reached production.

Practically best #1Design a release strategy to support your business objectives




Moving SAP changes through development and test environments typically involves requesting a technical (SAP Basis) person to migrate the change manually. Often, this involves a hand-off to a third party outsource provider or somebody in a different department. Whilst there are valid reasons for having an independent party move changes into a production system, for the majority of changes in development this process simply adds delay.

The efficiency of SAP developers can be transformed by simply automating transport deployment.

Further delay is added by the need to gain approvals, complete checklists, submit documentation and update spreadsheets.

Practically Best SAP development teams completely automate the movement of SAP changes and integrate workflow functions meaning that approval drives the movement of change. They also empower the business teams and environment owners (e.g. the Test Manager) to decide which changes should be migrated to their environments and when – placing control in their hands. This is a major factor in controlling test quality and reducing rework.

Plus, by controlling change workflow in a structured manner, it is possible to ensure that compliance is properly managed – auditing who approved change at each stage in the process and routing different types of change (e.g. SoX relevant) to different approvers.

Practically best #2Automate manual steps to reduce development lag




The biggest difference between ordinary and orchestrated SAP Release Management is based on this subtle distinction.

Organizations who run truly orchestrated Release Management do not simply look at changes to assess their description and timing, they look inside changes at their technical content to enable more sophisticated decisions to be made.

When you look at an SAP change, it is possible to understand who the developer is, how they have described the change and which project it relates to.

When you look inside a change, you understand which objects have been changed, in what way and crucially, how the contents of this change relate to all of the other changes moving through your landscape. Workflows ensure the correct treatment.

Practically best #3Look inside SAP changes and not just at them




a that it is possible to develop on multiple, parallel development tracks and know in real-time when two developers on different projects are working on the same object in different parts of the world.

b that it is possible to understand when an new developer in your offshore delivery center breaches one of your naming conventions or coding standards – again in real-time.

c that potential security breaches and performance issues can be detected at the point of change, thereby reducing rework and preventing serious issues further down the process.

d that you always understand the interdependencies between changes in your environments so that your can make informed decisions on the impact of unbundling individual changes from your releases without causing regression issues. This means that you can move to a more Agile development model for SAP.

e that you can classify certain objects based on their risk to business processes, flagging high-risk objects for more stringent approval and testing than lower risk objects that should pass through the development lifecycle at a faster pace. For example, identifying any object that is critical to your order taking process as high risk so that when a developer includes such an object in a change, alerts and workflows ensure the correct treatment.

Practically best #4Practically Best release management means…

a

b

cd

e




Organizations who apply these Practically Best principles to their SAP release management process gain an important competitive edge.

Their SAP changes and projects move more quickly and are in greater control. They deliver higher quality code and configuration to testing and production – reducing rework and production incidents.

Most importantly, because of greater visibility, control and confidence in what developers are actually doing, they reduce the cost of delivery and deliver projects to deadlines consistently.

Ultimately, their SAP changes move at the right pace to ensure that IT projects underpin competitive advantage for the business.

The bottom line: faster, safer SAP release management


basistechnologies.combasistechnologies.com

Find out more >

Find out more > Find out more >

Find out more >


http://go.basistechnologies.com/SAPReleaseOrchestration


