Managing the SAP Enterprise and Digital IT – Closing the Gap on Two-Speed IT

[Former Member]

Two-Speed IT

In 2012, along with the advent of the digital revolution, the idea of two-speed IT was coined by the Agile team at the Boston Consulting Group (BCG). In 2014 Gartner devised a similar term, Bimodal IT. Both terms +- describe a conceptional method of balancing digital agility with enterprise stability, whereby digital user facing applications are let run with high speed agility whilst allowing the enterprise back end to continue to run at a much slower speed due to the controls and governance traditionally required.

However, if recent customer conversations are anything to go on, then time is almost up for the two-speed bimodal solution. We are hearing it is no longer reasonable that business innovation available through digital initiatives must wait because legacy enterprise systems cannot deliver supportive innovation within similar time frames. Although it is highly unlikely that digital and enterprise IT will ever run at the same speed, the speed differential between the digital systems and the legacy enterprise applications must significantly reduce.

Closing the Gap

This is where DevOps and the creation of a single speed Agile development environment across both the digital and the enterprise IT infrastructure come into play. By implementing a rapid delivery Agile development process within enterprise IT, the slow back end can speed up. There is a growing momentum among large SAP using organizations to go down this path, particularly by those in fast moving, competitive environments such as retail, finance and retail energy.

But it’s not as simple as throwing a ‘DevOps’ switch and then suddenly all things are Agile. When making the change from a traditional waterfall development approach to an SAP DevOps approach, organizations may need to consider several structural and process strategies to support the change.

• Release strategy: The quickest way to accelerate and increase change velocity is through multi-delivery tracks and so a consideration as to how change will be categorized and what release frequency (e.g. weekly, monthly, quarterly) will be employed is an important starting point


• Technical environment: How are the systems going to be architected? Flat or N, N+1? There are a range of considerations for each


• Organizational structure: How will the development group be organized? By teams based on module? How will Business and IT interact?


• Development process: What development process will be implemented? For example, a Water-Scrum-Fall process or a Pureplay Agile. What team will be responsible for what portion of the Build-Test-Deploy process?

Once decisions have been made around these and similar strategic areas, then three key implementation facilitation steps follow, change control process design, automation and orchestration.

• Change control process: Allowing the categorization of change based on predetermined criteria to allow for acceleration of some change and appropriate due diligence of others. Balancing good governance and velocity of change delivery


• Automation: Change control automation, work flow automation, testing automation, impact analysis automation and code review automation to eliminate or minimize human speed limits


• Orchestration: Utilizing automation of the change process to orchestrate and automate the end-to-end development (build, test and deployment) process

SAP Change Control Automation and DevOps

Once change control processes have been defined, the most important next step is SAP change control automation. The enterprise IT does not operate as flexibly as the digital and so a range of SAP Agile development challenges will arise. The challenges will depend on the type of Agile architecture used but will typically include the following:

• Ensuring all changes are funnelled into the correct delivery tracks if a multi-track strategy is deployed


• Managing and facilitating parallel development to minimize overwriting potential in production


• Managing dependencies between objects within packages, between packages within sprints and between packages across applications


• Keeping all systems in sync with the same object versions

Implementing an SAP-centric change control automation tool will not only simplify the complexity that comes with a DevOps implementation but also enable the very important next step, the orchestration of the end to end process.

A final word. If an SAP change control automation tool is implemented, ensure the one selected is flexible enough (i.e. development methodology agnostic) to manage and automate whatever DevOps development strategy is employed or envisioned from basic change deployment automation to sophisticated dependency analysis and management or full end to end application lifecycle automation.