In the past few weeks, I have been considering for a few customers, when is there a genuine need for a DevOps model to support your business?  Based on Agile concepts, DevOps models have been in place for a few years, and surprisingly, not that difficult to design, migrate and then adopt.

But does every customer need one?

Based on my experience, DevOps models are often best suited for large enterprise customers with a heavy traditional programme delivery focus or product /software-based companies that are delivering rapid (Agile) changes of product features to the market.

For example, large customers that have a strong demand for technology change and heavily leveraging from cloud and digital investments.  The exciting bit for many CFOs and CIOs is often the financial and agility benefits that cloud and digital change brings quickly to a business.  The hard bit is how do you sustain this once delivered.  The key issue is that all customers want to ensure that ‘as a service’ products do not become orphaned in your business and then replaced with something else.  Technology debt risk will quickly become evident.

The best time to consider a DevOps model is when your business has multiple change programmes delivering simultaneously and especially, if the products are cloud or digital based.  All change programmes need an end date and a DevOps model assures leadership functions that the fantastic products that have been delivered, can continue to be well maintained and upgraded, in a DevOps ‘release focused’ function.

To move to a DevOps model, a customer requires:

  • A cloud or digital focused service vision
  • Strong leadership and a function / capability responsible for DevOps
  • Processes, tools, capability and an operating model that is largely based on Agile with strong service links into the rest of the business and dependent vendors/agencies

Companies with a DevOps model often see the following benefits:

  • More frequent deployments, feature sets and product roadmaps, upgrades delivered consistently
  • Less project by project go-live dates to juggle in the change calendar
  • Faster recovery times and better alignment to outstanding customer service principles
  • Lower change failure rate