Introducing DevOps to Traditional Enterprises

| by Aslan Brooke Follow 0 Followers on Jun 23, 2013. Estimated reading time: 1 minute |

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

Adoption Stage

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


Login to InfoQ to interact with what matters most to you.

Recover your password...


Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.


More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.


Stay up-to-date

Set up your notifications and don't miss out on content that matters to you