Niek Bartholomeus氏は昔ながらの企業における構成管理とリリース管理の実行について、DevOpsにフォーカスした4本のブログ記事を書き上げた。Niek氏はまずDevOpsの理論を紹介し、それから昔ながらの企業におけるソフトウェアデリバリー問題を分析し、最終的に、問題を解決するための具体的なDevOpsプラクティスについて説明している。Niek氏はGene Kim著『The Phoenix Project』を読んでこのブログ記事を書いた。その動機について、彼はこう説明する。
これはGene氏のお伽話とIT懐疑論者の現実との間にある穴を埋めようとするものです。
Niek氏はDevOpsの理論について、協調作業というカルチャーとエンドツーエンドの理解を築きながら、自動化のための支援ツールを使うことで効率のよいプロセスを導入することだと説明した。彼はDevOps導入に対する抵抗勢力（対立する関心を守るチーム、変化と安定との間にある競合、よく見られる変化に対する抵抗運動）について分析した。こうした課題があるにも関わらず、彼の話のDevOpsプラクティスは特に、ソフトウェアデリバリーの複雑さ（最悪の場合、拡張性がなく、手作業の労働力を要するプロセスになる）を克服することをターゲットとしている。
Niek氏は3番目のブログ投稿で、構成管理の導入について書いた。彼はそこで、ビジネス応用、変更要求、ソフトウェアコンポーネント、デプロイメント要求、リリースの間にある関係を正確に管理することの必要性について述べた。最後の投稿でNiek氏は、リリース管理の導入と前に紹介した構成管理ツールとの統合について述べた。彼の最終的な概念図は次のようになる。
継続的デリバリーやゼロダウンタイムなどのさらに進んだDevOpsプラクティスには漸近的な変化が必要であり、昔ながらの企業にはまだ準備ができていないことを認めた。しかし、彼による最初のステップは企業をそう方向付けるものだ。彼は次のように述べた。
従来のソフトウェアデリバリープロセスを徐々にコントロールし、可能なところを自動化して徐々にリリース頻度を高めることができれば、おそらくいつか、継続的デプロイメントへの跳躍は恐れるものではなくなるかもしれません。
DevOpsプラクティスを導入するための作業は、複数の現実世界の問題を解決するのに貢献すると言って、話を締めくくった。そうして得られた環境は、自動化され、首尾一貫し、コントロールされ、適切に調整されたものになる。だが、特にテストの領域にはやるべきことがまだまだあると彼は考えている。