This One Thing Is Killing Your Digital Transformation

Digital transformations don’t work.

At least that’s what some people say. Maybe you’re one of them. If so, you’re not alone in your skepticism. Despite the huge financial commitment, many organizations are finding that the promise of a digital transformation is falling flat. New applications are still not getting to market fast enough, and those that are released contain far too many problems, distracting developers from turning out high-value software.

And a huge financial outlay it is. According to a 2017 report by the International Data Corporation (IDC), organizations around the world are expected to spend around $1.7 trillion USD on their digital transformations by 2019—a 42% increase from 2017 levels. That’s a lot of money being invested to reap the benefits of a digital transformation: happier customers, increased innovation, higher employee satisfaction, and faster time to value of products and services.  

It’s not that your IT staff isn’t working hard or that you haven’t invested enough time and money to make your transformation work. You’ve put the latest and greatest practices such as Agile and DevOps at the center of your transformation, closely following their guidelines for improving culture and processes. You’ve given your teams the best tools on the market, yet, you’re not seeing the gains you should.

While I generally avoid simple answers to complex issues, I’ve seen this problem enough to say that there is one main thing that’s killing your digital transformation:

Scripting.

Specifically, scripting how software is delivered throughout your DevOps toolchain, from code integration to testing to configuration management to deployment of every application to all sorts of environments, from development to production. And to be clear, scripting includes writing hundreds, or in many cases thousands, of CI jobs. If you’re like most organizations, highly-paid developers end up writing scripts and/or jobs—by hand—to deliver instructions for every activity required to release your software. Each time anything changes, they have to make edits, so in essence, they end up scripting the entire DevOps toolchain and software delivery pipeline over and over again, instead of writing code for business applications. Developers don’t like doing this kind of maintenance work because it’s not conducive to delivering great software at high velocity.

3 Ways Scripting May Be Costing You

Below are a few signs that scripting is negatively affecting your software delivery process and undermining your digital transformation.

You’re Not Meeting Your Delivery Goals

You started with a DevOps pilot on some small projects involving one or two teams. Your teams wrote a lot of scripts to make your pilot projects work, but the more you scaled, the slower things got. Deployments started to fall off, releases began to slip, post-production fixes increased, and on and on. Does this sound familiar?

The thing is, as you scale from simple projects, scripting the DevOps pipeline will rapidly consume your teams if it hasn’t already, sucking them into black holes of perpetual maintenance and locking them into “hacks” made to hold the pipeline together. All of this maintaining of scripts will leave them little time to deliver software at the frequency and velocity, or with the quality, you need.

One other danger—missed compliance requirements. If developers are busy stringing together the delivery chain, they may skip the security checks that must be built into the software to comply with audit requirements. If that happens, you’ll spend time and money to fix problems later.

It’s Expensive

Your developers are some of your highest-paid people, and they were hired to build applications that solve business problems. If they’re spending time writing scripts to deploy applications onto infrastructure instead of building applications, you’ll never reach your digital transformation goals. Your developers simply cannot be as productive as you need them to be.

In my experience, most companies are leaving at least 8% on the table. For example, for a 1000-person IT organization with 100 development teams and 8 fulltime developers per team, each at about $125K USD per year, the annual cost of scripting the activities for your release pipelines comes out to $8 million dollars. And that’s not counting lost opportunity costs because developers don’t have enough time to write code for new features, and deployments to production are significantly slowed.

Your Developers Are Unhappy

Loss of developer productivity doesn’t just negatively affect the organization, it also hurts developer satisfaction. According to Stack Overflow in a 2017 Developer Survey, they see “a relationship between job satisfaction and pushing code into production frequently…A happy developer is a developer who can ship.”

If your developers are expressing dissatisfaction, it may be because they don’t have enough time to do the interesting and creative work of writing new features and frequently releasing them. And if word gets around, you might start having trouble attracting the best new development talent, which is hard enough even under good circumstances. At the same time, no matter how good you are at keeping and hiring good people, you can never have enough people to scale your DevOps implementation across the enterprise as it continues to grow, unless you change your manual approach.

Escaping the Scripting Rut

If you’re trapped in a scripting rut, you should know that a lot of companies are, not because they’re failing at DevOps (or DevOps is failing them), but because it’s part of a normal progression towards a full-scale transformation.

A key reason that many companies fall into a scripting trap is because they see DevOps as being primarily about buying the right tools. While certain DevOps tools may be great at automating discrete parts of the pipeline (like code integration, unit testing, and infrastructure provisioning), they can’t automate the delivery cycle from start to finish. And using any one of them in an attempt to do so is to put a square peg in a round hole. They simply weren’t built to do end-to-end automation precisely because they rely on customized scripting.

As organizations experience the growing pains of their digital transformations, many are learning that DevOps requires thinking about software delivery holistically. It’s not about getting rid of their existing tools but about finding enterprise-specific solutions that can integrate those tools, as well as automating and standardizing release pipelines across the whole organization. As that happens, companies will see DevOps obstacles like perpetual script maintenance dissolve organically, clearing the path for their digital transformations.