How to Modernize Your SDLC – InApps 2022

Leading the way in software delivery, the progressive Global 2000 companies are showing the industry what is possible. You only need to look at the price-to-earnings ratio of a company like Tesla versus a traditional automotive manufacturer, and the facts are staring you in the face: You can modernize your software delivery life cycle (SDLC) and achieve significant software-powered enterprise value without compromising customer trust.

Companies can achieve quality and velocity for their software delivery, but it requires investing in sophistication, overcoming fear of failure by establishing psychological safety and unblocking innovation by moving away from legacy systems that are often a deeply entrenched sunk-cost fallacy.

Most global companies struggle to create value through code. The reality is they are often assembling systems from off-the-shelf software and stringing SAP and other packaged installations together. It may appear contradictory, but moving at speed is safer and should be a company habit, as moving slowly can hold greater risk. When old releases were as infrequent as once a year, that delay between planning and the software delivery held huge business risk. (Aside from the potential for bugs and issues, imagine having to wait a year after an update flops to win back your customers.)

Software Spoilage

Want another shocking reality check? Code that’s already developed and isn’t out in the world is just inventory. It’s not even like canned goods; it’s fresh and spoiling every second. You’re creating spoilage, and it’s getting stale on a shelf. There are dependencies you don’t know about and new features are being added that pile on risk with every commit.

Your fresh “software apple” could be rotten by the time your user bites into it.

Increasing business value gets me out of bed in the morning, and it’s the reason why we started Armory in my garage all those years ago. Armory developed a software delivery platform powered by Spinnaker, an open source project from Netflix, that’s used to deliver software with safety and velocity. We have helped companies such as Autodesk go multi-region and deliver features globally in minutes instead of months.

We tell companies all the time that you can have quality and velocity, but it requires sophistication. There isn’t a playbook for digital transformation. Companies are determining the right process for their business, especially with the advent of the cloud.

The simple fact is that any company can deploy their software, but their process is often very brittle, tied together with spit ‘n polish and tape with scripted paths to production into data centers. The engineers who built these Rube Goldberg machines often have left the company, and nobody knows how they work.

Brittle Processes and Fragmented Infrastructure

We joke about the proverbial Bob in the company who goes on holiday, which means nothing is deployed while he sips margaritas by the pool. It’s not a laughing matter if you’re living with that kind of creaky infrastructure, and it’s not cloud native. Meanwhile, you’re observing new targets emerging — AWS, GCP, Azure, VMware, etc. We all know AWS isn’t just AWS; it’s EC2, ECS and EKS, Lambda and whatever is announced at AWS re:invent.

We need to acknowledge that the fragmentation of the infrastructure layer is just beginning. So while a company may have a build process that points to data centers and isn’t cloud native, it may well have teams that, for example, want to be able to deploy into a GDPR-compliant cloud or the cheapest, fastest or AI-powered cloud. Essentially, these companies are wrestling with how to make the right investments that will enable them to achieve a good structural foundation and obtain that sophistication and ability to improve customer experience, which is where the power lies.

Invest, Protect the Team and Deploy ASAP

But before you can drive the Ferrari fast, you need to have your seatbelt on.

Adding sophistication takes focus and investment. Software delivery has a number of “seat belt” or “guardrail” features that enable more control over when features are experienced by the user, such as automated canary analysis (an early warning system, where a controlled percentage of users experience an update), feature flags (turning specific functionality on and off during runtime, without deploying new code), deployment windows and rollbacks. These are also separated from the software delivery process and give software engineering teams control over the blast radius from issues.

Psychological Safety: Fear Is the Innovation Killer

All these “guardrail” features are about introducing psychological safety inside companies. It’s a terrifying idea for any company to be breaking customer trust continuously; it’s the last thing they want to do. A lot of this is about meeting a company where they are and allowing them to make progress.

Companies need to feel confident in features such as canary analysis so they can flip that cost-benefit analysis in their heads to see that it’s worth deploying software to 1 percent of their users so they can deploy out 10 or 100 times faster.

As an example, we had one company that used mandatory deployment windows for breaking a monolith into microservices, and everything was signed off by a vice president. As the company became more sophisticated with blue-green, canary analysis and rollbacks, over time it was able to safely take out gates that were stifling innovation and not providing as much value.

A Common Challenge

Companies don’t necessarily have an understanding of their systems of record across their SDLC as responsibility is usually spread across many teams. It’s a black box where ideas go into the factory at one end, and features come out the other end; the company doesn’t understand what’s happening inside. You can’t unblock things until you have visibility, understand what’s happening and unlock the silo of data systems of record in the SDLC.

CI/CD is frequently described as one thing. Continuous delivery has not been allowed to be its own category because companies have been delivering into data centers and each data center is different, which required building bespoke systems to deliver code. With the cloud, there’s uniformity and a platform for platforms through AWS. This allows for continuous delivery to be segmented out into its own category. I separate it from continuous integration, which is on the left side of SDLC before value leaves the building, and I view delivery as on the right side of SDLC where value exits the building. I don’t call it continuous delivery, as you have to have safe movement before velocity, so you need to be talking about reliable delivery at scale, which leads to continuous delivery.

These are distinct systems of record and personas that have to assemble together to get software out the door. A lot of this is about unlocking that silo of data, so we’ve taken open source OPA (Open Policy Agent) and built that into Armory’s policy-as-code offering. For us, it’s about giving central automation teams the ability to create “HOV lanes” for developers to move fast. If you’re a pipeline developer and you don’t remove a stage from your pipeline, you can go right to production and it’s an HOV lane for you. If you change that pipeline, that causes it to fall out of certification and devs will need to talk to the ops team.

Again, it’s about sophistication and the ability to give dev and ops both what they need and sit on the same side of the table.

Don’t Sink with the Sunk-Cost Fallacy

Companies that are doing well now have something in common: It’s whether they have a software mindset or not. This mindset comes from a deep cultural belief in the power of software for a business and for the future of that business. The new mindset requires companies to leave behind the sunk-cost fallacy of holding on to a janky system they likely built themselves at great cost and put into data centers.

Quite simply, a company’s ability to innovate is directly tied to that previous investment.

We’re still in the early innings of this game, and companies feel they are already left behind. I would say to them that there’s still time to create a strategy and execute against it. In three to five years, though, there’s going to be a huge delta in enterprise value being unlocked by those companies making that decision to act today.

Featured image by Illus_man on Shutterstock.