Introducing DevOps to Traditional Enterprises

by Aslan Brooke on Jun 23, 2013 |

Niek Bartholomeus recently finished composing a four post DevOps focused blog series about leading the implementation of configuration management and release management in a traditional enterprise. Niek covers the theory of DevOps, then an analysis of the problems with software delivery  within a traditional enterprise, and finally the application of specific DevOps practices to solve the problems. Niek created the series after reading The Phoenix Project by Gene Kim, he expressed his motivation as follows:

an attempt to fill the hole between's Gene's fairy tale and the IT Skeptic's reality.

Niek explains the theory of DevOps as the introduction of efficient processes that are supported by tooling built for automation while building a culture of collaboration and end-to-end understanding. Niek analyzed the forces opposing the introduction of DevOps: teams protecting opposing interests, the seemingly inherent conflict between change vs. stability, and just plain old human resistance to change. In spite of these challenges the DevOps practices in his story are specifically targeted at overcoming the complexity of software delivery, which in its worst state is a non-scalable, manual, and labor intensive process.

Niek documents the introduction of configuration management in his third blog post. He discusses the necessity to accurately manage the relationships between business applications, change requests, software components, deployment requests, and releases. In his final post, Niek documents the introduction of release management and the integration with the previously introduced configuration management tooling. Leading to a final conceptual diagram from his post:

Niek acknowledged that the more advanced DevOps practices of continuous delivery and zero downtime deployments require a progressive conversion of an enterprise and that the traditional enterprise in his story was not prepared yet. However, the initial steps he took lead in that direction. He stated it as follows:

if we can gradually bring our conventional software delivery process under control, automating where possible and gradually increasing the release frequency, maybe one day the leap towards continuous deployment may be less daunting

Niek concluded by saying that the work done to introduce DevOps practices contributed to solving multiple real world problems. He noted that the resulting environment was automated, consistent, controlled, and properly regulated. However he acknowledge there was more to be done and specifically in the area of testing.

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

General Feedback
Marketing and all content copyright © 2006-2016 C4Media Inc. hosted at Contegix, the best ISP we've ever worked with.
Privacy policy

We notice you're using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.