Skip to Content

For several years, analysts have urged large companies to adopt continuous change delivery for increased business requested change efficiencies. Managers now agree that projects can be developed and delivered more efficiently in smaller, more frequent chunks.

In recent travels, I confirmed that IT teams are increasingly tasked to devise and implement continuous delivery systems for their companies. This shift to continuous delivery is part of a larger trend. Traditional set-in-stone SAP application support cycles are changing as components become more tightly integrated. The same shift has created a drive toward greater system control, change traceability and production stability.

Several teams mentioned a tension between faster delivery and closer control. One developer described it as “never time to do it right, always time to do it over.” But that’s not really a problem if your change control software has both sufficient flexibility and broad enough enforcement capability. These two attributes are, of course, key goals of Rev-Trac. Increasing volumes of change delivered faster, at higher quality.

Even with a powerful and flexible change control tool, the challenges you’ll face when shifting to continual delivery will not be trivial. But the right software will make the shift much smoother.

Optimum Strategy

Most organizations with large, complex infrastructures have settled on a ‘multi-lane’ or ‘multi-track’ approach that reflects the different priorities assigned to different types of change. That allows IT to follow different development, QA, review and approval policies with different types of change.

One strategy that can work well uses different delivery lanes like this:

  • Lane 1 – Emergency changes – These are assigned the highest priority and the fastest track to promotion. Typically, an emergency change is IT’s fastest possible response to unexpected problems, especially those that have potential to bring down the system or disrupt business processes.
  • Lane 2 – Weekly support releases – These are regular support changes that flow out on a weekly or biweekly basis. They include, for example, small enhancements requested by business and adjustments to data flows to accommodate new requirements.
  • Lane 3 – Monthly scheduled releases – This is the main channel for accelerated delivery of major enhancements and business-requested change orders. Depending upon your organization’s size, complexity and change volume, Lane 3 would deliver its changes in monthly or even quarterly cycles. This is not quite agile development, but in practical terms for a large organization, it is close.
  • Lane 4 – Major projects on 6 or 12 month cycles – These are the unavoidable major SAP projects that bring new modules online, upgrade crucial systems, and so forth. They may also include major in-house projects, such as consolidating different business units or bringing significant third-party applications on line.

The challenge facing the change delivery team is managing concurrent change across all four lanes efficiently whilst occasionally swapping change from one lane to another and, eventually, merging all lanes into the one as delivery into production takes place. I will be getting into more of the detail throughout the series as we go though the challenges each lane presents and the overall challenges presented in managing all four lanes together.

In other field notes, I verified that tight integrations (theme of our last post series) are rapidly gaining importance. Customers increasingly put vendors through their paces to make sure claimed integrations work well and as advertised. If integrations are a factor for your team and you missed our last series, check our four-part Integrations series that begins here.

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply