Despite their reputation as laggards, large corporations are as obsessed with innovation as any startup. Blockchain, serverless computing, artificial intelligence, IoT—they want it all. And unlike startups, they can afford to invest the money, time, and people to get it.
But even when you’re blessed with these kinds of corporate resources, hazards can lurk out of sight. It doesn’t just happen with devops (the example I’m using), but agile development and other forms of business transformation as well.
Here’s what to watch out for, and how to avoid the quicksand in the first place when you are introducing devops in the enterprise.
Enter the bean bags
The story often starts with the creation of a corporate innovation center (or incubator hub or disruption lab or similar). The business taps forward-thinking in-house talent and brings in new blood from the outside to experiment with whiz-bang technologies and cutting-edge methods. Sometimes there are bean bags.
And it works! The innovation people form nimble teams and keep their workflows lightweight. They build streamlined devops pipelines using open source software and inexpensive cloud-hosted tools. They create some cool new prototypes, and the C-suite takes notice. “Success,” they think. “We figured it out! Let’s bring that slick devops process back into the mothership and get the whole organization doing it.”
Stuck in old habits
That’s where companies take their first unwitting step toward devops failure. They try to implement devops as a technology, spinning up new devops tools without changing the way they work—like buying a new car for someone who doesn’t know how to drive.
A common mistake is to start mainstreaming devops by spinning up the standard corporate technology evaluation cycle. IT reads a lot of reviews, maybe talks to some analysts, puts together a list of all the stuff it’s going to need or might need next year, gets quotes from a bunch of salivating vendors, and negotiates for the approved solution. After months of wrangling with vendors, finance, and leadership, the budget gets the green light. Now it’s finally time to start the implementation. It will take another six to 12 months to complete.
That months-long implementation assumes you don’t run into internal resistance—but you often will. Devops can improve productivity by orders of magnitude, but it calls for new methods and new ways of operating. Often these disrupt existing business silos, which can make people scared. When you show an ops team that the lead time for provisioning a new server just went from six weeks to six minutes, some people are going to wonder if their jobs and power bases are at risk.
To make things even more uncomfortable, the teams most threatened by the change are often the same people tasked with integrating the technology. Perhaps it’s not a big surprise when they dig in their heels. This is where leadership needs to really step up and not look for opportunities to cut, but for opportunities to grow.
You ain’t gonna need it
At the other end of the spectrum, some organizations try to check every box to create the “perfect” devops solution. They read a couple books and create a list of all the devops things—configuration management, automated build, secrets management, monitoring, etc.—and start evaluating products in each category. They haven’t optimized a single value stream, but they’re already drawing battle lines over which product they want to use for log aggregation.
Investing in this type of all-singing, all-dancing devops solutions without a clear game plan runs counter to a core principle of software development: YAGNI, or “You ain’t gonna need it.” Good developers don’t build functionality just in case. “Just in case” features need to be supported and maintained—draining time, investment, and focus from the ones you really do need.
Maybe what you really needed was that no-frills open-source tool that takes five minutes to configure, and some quick experiments with the best way to use it.
Treat innovation as a process, not a technology
Every time I see a devops project stuck in corporate quicksand—and unfortunately, I’ve seen a lot of them—I think, “Guess what: you just missed the whole point. You made a great investment in figuring out how to innovate and get more agility. Then you took what you learned, ignored it, and spent more money doing the opposite.”
The mistake organizations should worry about isn’t falling short of devops perfection, it’s overinvesting in a “perfect” solution (or underinvesting in how to get value from it).
Remember, you didn’t create that innovation hub outside of the existing organization because you like bean bags. You did it because you wanted to break out of your traditional way of doing things.
Innovation centers can be a smart, reasonably low-cost and low-risk way for companies to explore new approaches to product development. But you have to be careful not to squeeze the life out of innovation when integrating it with the larger organization.
You need to treat innovation as a process, not a technology, and add technology as it makes sense.
The right way to introduce devops to the enterprise
Okay, so where should you start?
Take a deep breath and don’t try to change everything at once. Adopt an incremental strategy instead; you want to “land and expand.”
Find a Goldilocks greenfield initiative that management can commit to, and don’t move forward until you get its buyin.
Step 1: Build a pipeline
Once management is on board, you can begin the first phase of the project: building a devops minimum viable product (MVP) pipeline. Your goal is to automate the process that takes code from the source repository to compilation to testing to deployment and send out an email at the end telling everyone it worked.
Again, don’t go big. Pick a basic too lchain with a low barrier to entry. There are several open source and free options (including Jenkins, Team City, and VSTS) that will allow you to get moving quickly.
But be careful not to make the “M” in MVP too minimal. It’s best to run automated tests and generate code-coverage metrics as part of the pipeline from Day 1. Automated tests are an important step toward realizing devops value and understanding how to include them in your pipeline is a first step toward this maturity.
If your team is unfamiliar with devops, the MVP will probably take one to six weeks to build. The exact amount of time will be a lesson in itself. If you had already started devops, even this basic pipeline would have taken hours rather than weeks to build. One of the benefits of creating an MVP is that it teaches you how much better you can get.
But this incremental approach will give you much more than a quick confidence boost. Going from no devops to even barebones devops makes a huge difference in people’s day-to-day work. Suddenly, everyone sees how fast developers are committing code, and how much less they’re backtracking when things go wrong—partly because so many fewer problems come up, and those that do are easier to correct. Expect to find that morale goes up, productivity soars, and you win friends and allies for the next phase of the project.
And you’ll need them, because the next step is more complicated.
Step 2: Open the floodgates
Now that your pipeline is up and running, it’s time for the second phase: fixing your value stream. To continue the metaphor, once you’ve built your initial devops pipeline, it’s time to make it wider, stronger, and free of obstruction.
This is going to require both technology and organizational change. You’re not just automating what people are already doing. You’re making what they do better, which means doing it differently. You’re adding features. You’re building telemetry for continuous feedback. And ideally, you’re introducing new metrics to track how well the pipeline is performing.
You already know that metrics can make people nervous. That’s another reason you need management support. Devops needs constant incremental improvement, and as they say, you can’t improve what you can’t measure. Support from management can help smooth down any ruffled feathers caused by the new procedures and measures.
Now you can decide what to add to the pipeline. Different organizations will have different priorities, but typical ones include automating versioning, API deployment, performance testing, and security scans.
Tackle your biggest pain points first, always one piece at a time. Get it up, test it, and move on to the next thing. Try to turn everything you can into code. Even performance metrics like response time and throughput should go into a digitally readable format, giving you the data you need to make your pipeline more intelligent.
Automate every manual process you can think of. Anything people in your organization have to do more than once is fair game. For example, how often does your team need to get a new developer up and running in your organization with the right devices, permissions and environment? Automate it. Similarly, why make someone in IT pick up a help-desk ticket when you can write a script to spin up a virtual server with the necessary CPU, storage, and network resources and set the permissions? That way no one can screw up the process by miskeying something into the console.
You can instantly replicate the environment for new projects, and if you ever need to restart one that’s already running, you just blow away what you have and fire up a new one. In theory, the system can even restart itself. No need to pull people away from dinner or, worse, wake them up in a different time zone. (Anyone who has suffered through the Thursday Night of Dread will appreciate how much this can improve a team’s quality of life.)
Step 3: Control the flow
Once you’ve built out your pipeline, the final step is to create gates that control the flow between the different stages. For instance, you might want a new build to fail if it has open defects, or if testing shows a performance decline.
Alternately, you might want a person in the loop. People sometimes think continuous deployment means code has to automagically flow out the door. It really just means that the code flows automatically as far as it should. You might have good reasons to want manual approval from an auditor or a reviewer or someone from upper management before code goes live. That’s fine. The main principle is not to hold up deployment for any decision you can automate—and we’re still a long way from automating human judgment. Try to build gating that’s intelligent as possible and as manual as necessary.
And with that, congratulations are in order. You’ve avoided every pit of quicksand, and you’re truly doing devops. You’ve achieved something great for your team and your business.
There will be more milestones and celebrations ahead, but there’s nothing quite like getting devops up and running for the first time.
This article is published as part of the IDG Contributor Network. Want to Join?
