Share this news

Lessons Learned on the Journey to DevOps Transformation

—January 31, 2017
Lessons Learned on the Journey to DevOps Transformation

By Erez Nir, Executive Vice President and Chief Technology Officer, Mitchell

A few years back, I invited Gene Kim, DevOps evangelist and author of the book, The Phoenix Project: A Novel about IT, DevOps and Helping Your Business Win, to speak at Mitchell’s annual developer conference, DevCon. At the time, I had been reading up on and researching DevOps, and I wanted our developers at Mitchell to hear directly from Gene about it. But I was also trying to wrap my head around how to bring DevOps to an established enterprise software company with legacy software and existing development processes in place. When I asked Gene for his take on it—he answered candidly that he didn’t know—yet. As I’ve spent more time trying to figure this out, I’ve learned some things along the way.

Agile Is Awesome, But It’s Not the Endgame

Like many companies, Mitchell’s journey toward DevOps actually began several years ago with the adoption of Agile. Mitchell prides itself on listening to and collaborating with our customers, so we had that going for us. Agile enabled us to respond to their feedback even faster. It took some time to work out the kinks, but now it’s very much a part of our culture—so much so that we host teams from different companies and even different industries, and share our experiences and learnings with them. The challenge with Agile is that it’s product development focused—it helped us overcome barriers to building software, but it didn’t help us deliver it any faster.

Like many companies, Mitchell’s journey toward DevOps actually began several years ago with the adoption of Agile. Mitchell prides itself on listening to and collaborating with our customers—Agile enabled us to respond to their feedback even faster.

And here’s the thing: a line of code written and not tested carries no value. A line of code tested and not deployed is just the same. For an enterprise software company, that code only realizes its full potential when it has been deployed and customers are successfully using it. So when you take the next step, moving to a continuous flow of develop-test-deploy (continuous delivery), you have even more to gain in terms of efficiency.

Tech Transformation Is Powered by People

The next step in our journey has been focused on enabling continuous aspects of our software delivery value stream, Continuous Integration and Continuous Deployment (CICD). This is not an easy task in a world where development and operations are separated. Development’s job, especially in an Agile environment, is to get code out the door and move on to the next story, task or work item. Operations’ mind set is to do whatever it takes to deploy and operate that code reliably and with minimal disruption to business. So breaking down these silos was our first hurdle. To get started, we gathered people from both the development and operations sides of the house that we anticipated had the collaborative mindset and technical skills necessary to create and manage a highly dynamic pipeline, and we put them to work.

As with Agile, through trial and error, we’re working out the kinks, and our pilot program has achieved notable results: in some cases, code that used to take 60 minutes to build and 60 minutes to deploy, may now take only 10 minutes to build and two minutes to deploy.

It’s been said by many that DevOps is more than a set of processes—it’s a cultural movement and everyone needs to be bought in. At Mitchell, our culture supports cooperative work which puts us ahead of the game, but I’ll admit there’s still much to do. A couple of the questions that are top of mind for me are: how do we scale this pilot across all of our business lines, and how do we bring people along who do not come by this mindset naturally?

Automation Is Essential

While we’re addressing the collaboration part of the equation, the automation variable is another critical factor. While DevOps does not prescribe specific standards and processes, it is clear that it will require automation in as many steps in the delivery process as possible—testing, integration and deployment to name a few. This may be a much simpler problem to solve for born-in-the-cloud unicorns that are built from the ground up with this notion in mind. For many enterprise software companies, things are not nearly as straightforward. In addition, our solutions support incredibly complex, highly configurable workflows for high-touch end users, so even simple changes, at times, require downstream training.

What’s Next?

There’s no questioning the value that DevOps has the potential to bring, both in terms of an engaged workforce and the bottom line. In fact, the 2016 State of DevOps Report indicates that high-performing IT organizations that employ DevOps deploy 200 times more frequently, recover 24 times faster and spend 22 percent less time on rework relative to low-performing organizations. In addition, employees on high-performing teams are more than twice as likely to recommend their organization as a great place to work.

I wholeheartedly believe that there is currently no better approach than DevOps to solve for speed, quality, security and customer satisfaction. And while established enterprise software companies like Mitchell—companies with legacy software and existing development processes in place—have many hurdles to overcome on the way to total DevOps transformation, it’s well-worth the effort. I look forward to continuing on this journey—and continuing to learn from it.

 

Posted in: Blogs, Corporate

Terms of Use | Privacy Practices | Copyright & Usage | [+} Report a Problem
© 2017 Mitchell International, Inc. All Rights Reserved.
By accessing Mitchell.com, each user agrees that they have read and agreed to be bound by the
Terms and Conditions governing Mitchell.com and Privacy Policies governing Mitchell.com.