DevOps in 2019: What’s Next for Enterprise Digital Transformation?

In the nearly 10 years since the now-famous “10+ Deploys Per Day: Dev and Ops Cooperation at Flickr” presentation was given, we’ve seen an industry shift towards DevOps that is so significant, it’s perhaps the most influential movement in IT since the jump from mainframes to distributed computing.

So, what’s next? As more and more companies optimize their software delivery environments, where will the true competitive differentiators lie?

Charles Betz, Forrester Principal Analyst and DevOps Lead, offered up his predictions for the coming year in the DevOps space in our recent webinar, DevOps Hits Adolescence – What’s Next?

Following the webinar, we received a bunch of questions for Betz, touching on everything from talent shortage concerns to how the marriage of DevOps and Enterprise Service Management actually works. You can watch the webinar here and read our interview with him below.

Someone asks you, ‘we’ve done a proof of concept, we’ve done a pilot, how do we scale this out?’––what’s your best advice? There are two ways the conversation goes––’we’re ready to scale out, what should we do?’ Or ‘we tried to scale it out to everybody and it didn’t work.’ In the latter case, you really have a failure of organizational change management. We’ve beaten people over the head with decades of focus on execution and these cultural dynamics make people scared and very cautious. They duck their heads low, hoping the problem goes away. But with DevOps and digital transformation they can’t duck for cover. I tell people who want to scale out a successful pilot to look at what’s next on their roadmap. While we want to teach the lesson that this kind of work is iterative and that you need to learn from it, there has to be some kind of general direction. And you have to make some decisions. Are you going to push this out to 500 product teams simultaneously? Or are you going to prioritize and on-board teams one or two at a time? You can probably tell that I favor the latter. What about training? The first team you successfully piloted with is likely staffed with people that you want actually writing production code. Do you want to turn them into trainers? I’m a big fan of the dojo concept––training the team instead of training individuals. Training individuals in DevOps is not going to give you as much lift as training whole teams. But you’ve got to figure out the staffing. People have to get paid, space needs to be acquired, programs have to be in place, and guidance needs to be put together. How can you prove DevOps is having a positive impact on business outcomes? Are you mapping out your entire value stream from ideation to production? You need to determine how long it takes to make a change to your systems involving merely one line of code. You can measure an increase in that tempo as a proof point, or at the very least, demonstrate that the tempo is no longer constrained by your technical capabilities. It should only be constrained by your business goals. If you don’t want to release code to your customers five times a day that’s a reasonable decision, but it should be made as a business decision. The other thing you want to measure is system stability. An increase of throughput in terms of functionality moving to production, coupled with an increase in system stability—if both of these metrics are moving in a positive direction, that is an excellent proof point to bring to an executive in any given enterprise.

DevOps Hits Adolescence – What’s Next? Forrester’s Charles Betz offers up his predictions and trends to watch out for in the DevOps space. Check it out.

How do you increase systems stability while at the same time upping the release tempo? A founding principal of DevOps is that systems stability and increasing release tempo are not opposed. In terms of making changes more frequently, we’ve known for a long time that when you change systems more often you get better at it. But there is a more structural concern that is starting to emerge. When we get better at fixing problems, it has some interesting impacts on the overall operating model assumptions for digital organizations. In particular, when you look at service management. In a classic IT Service Management situation, you have repeated incidents leading to a problem. The problem has a known error, there’s likely an associated knowledge article with it, and there is a service desk trained on the article so that when someone calls them, they know what to say. This is called “first call resolution.” Fast forward to the current era, where problems to a system are squashed with DevOps. If we write a knowledge article for an incident now, it’s likely to only be relevant for the next week or two. So, as we start moving into a world where any given problem may be “Zero-Day,” the basis for a having a large tier-1 support organization starts to turn on its head. Tier-1 support is typically staffed with entry-level workers who are unable to provide first call resolution for an issue they’ve never seen before. Ultimately, this is an indicator of automation paradox. Once you’ve automated all of the easier, less variable work, all that’s left for people to do are the hard things. This is shifting the whole structure of the talent pipeline and there are even implications for the educational system. So, where does that leave the relationship between DevOps and Enterprise Service Management (ESM)? ESM is really the expansion of ITSM into broader business workloads, such as HR, legal, and marketing. Enterprises will typically have a unified workflow portal––supported by a powerful low code/no code engine––that exposes different classes of services to users. DevOps falls into the enterprise services class––strategic digital services and mission critical systems that provide competitive advantages. Another class is services that can be fulfilled entirely in the ESM system, such as simple service requests like ‘get me a new cellphone.’ And then you have the class of services you’re getting from someone else, curating, and proxying to your internal customers––’what Amazon EC2 services am I allowed to have?’ Organizations can use a DevOps pipeline to build and provision access to those strategic digital services, then apply ESM capabilities to track TCO and the overall consumption of digital resources. You mentioned pipeline as code in the webinar, can you expand on that? Pipeline as code is the third major piece of the as code movement. We have application code as code, which we’ve been putting in source control going back decades. Then we have infrastructure as code. And when you combine the application and the infrastructure code, you then have a functioning digital product. So, the question becomes what is the product process by which you created this functioning digital system? Those kinds of installation processes have traditionally been painfully and poorly documented in 80-page Word documents. While we’ve been automating the necessary steps for deploying a release for a while now, we previously hadn’t had the ability to baseline and version those automations. By defining the entire pipeline as code, we can now understand the process by which all of these resources were turned into a functioning service. The ability to present that as code, baseline and maintain that code, address variables, and have all of the configuration management capabilities in place, is very powerful.

Learn More

• DevOps Hits Adolescence – what’s next?
• 2019 DevOps Predictions: Gene Kim Places His Bets for Next Year
• Build a Bridge between CI/CD and ITSM and Make the Promise of DevOps Come to Life
• Try XebiaLabs today for free!