現代の企業のソフトウェアデリバリにおいて，ソフトウェアのリリースを問題なく行うために必要なのは自律性(autonomy)だ。Niek Bartholomeus氏はDevOps Summit in Amsterdamで，"Orchestration in Meatspace"と題したプレゼンテーションを行った。
従来の企業のほとんどが，ソフトウェアのデプロイを組織的調整(orchestration)に依存しています。これがプロセス全体を遅く，エラーを発生させやすくしているのです。もっと自律的なアプローチに移行して，アイデアから製造までのフィードバックサイクルをスピードアップするには，どうすればよいのでしょうか？
氏のプレゼンテーションは，このような問題空間の検討から始まった。従来の組織では，意思決定は組織階層のトップに集中している。技術的な判断を行うには，これは組織の中に知識が存在するチームの構造から遠く離れたものだ。階層間の意思伝達による決断の遅れもまた，開発やデリバリを遅れさせる。さらにワークフローの標準化や作業の分化が生み出す機能的特化によって，デリバリはますます遅れる。そして最後に，緊密に結合されたアプリケーションが，アプリケーション変更時にリスクの連鎖反応を引き起こすのだ。従来の企業で行われているような計画と全社リリースのマネジメント依存が，結果としてシステムのリリースサイクルを長くしているのである。
氏の個人的な見解は次のようなものだ。
ビジネスプロセスの自動化は複雑で創造的，かつダイナミックです。従って私たちには，アイデアから製造までの迅速なフィードバックが必要なのです。それが可能になるのは，ソフトウェアのリリースが問題なく実施される場合に限られます。ここから自律性が必要になるのです。
氏の言う自律性とは，開発チームが過度に外部に依存することなく，新たな機能を開発できるという意味だ。これはつまり，これらのチームが，開発に必要なすべてのサービスあるいはテクノロジを可能な限り自己充足できなければならない，ということになる。クロスファンクショナルなチームを作り上げれば，チームをより自律的にすることが可能になる。自律的なチームは決断することができる。技術的な決定は自ら権限を持ったチームによって，チームの中で行われるべきなのだ。
この問題に対して科学的根拠に基づくソリューションを構築するため，氏はHenry Mintzberg氏の組織構造に関する書籍を引用した。Mintzberg氏はコーディネーションのための３つのメカニズムを定義している - 相互調整，直接管理，そして標準化だ。アイデアから製造までのフィードバックサイクルを短縮化しようとする場合，従来の企業では後者の２つに依存することが多い。しかし相互調整を行うことで，さらによいメカニズムにすることが可能なのだ。
Mintzberg氏の著書には，組織の一般的な構造についての説明がある。それらのいくつかは行政官僚的な組織であり，あるいは専門官僚的な組織であり，そして非構造組織である。ビジネスプロセスの自動化のように複雑で創造的，かつダイナミックな作業をするには，自律性こそがもっとも適した構造だ，と氏は言う。従来的な企業の大部分は，しかしながら行政官僚的な組織構造を持っているのが実情だ。
DevOps Summitで氏は，企業が官僚的組織から非構造組織に変わるためのステップを披露した。
- シンプルで一貫性のあるソフトウェアデリバリプロセスを定義し，可能な部分を自動化することによって，既存のコミュニケーションフローを拡張する。これを(自律的ではなく)組織調整的に行おうとすれば，開発要求の管理やデプロイのグループ化，バージョンとビルドリリースの管理などを行うためのツールが必要になってくる。
- 開発チーム間の自律性を向上する。例えばアプリケーションに後方互換性を持たせることで，アプリケーション間の依存性を削減することができる。氏のプレゼンテーションでは，拡大/縮小(expand/contract)パターンに従ってこれを実行する方法を示していた。
- アプリケーションのコンポーネント間の自律性を向上する。機能フラグを使用すれば，フィードバックサイクルを劇的に増加させることができる。ただしデプロイメント中のダウンタイムを回避するために，アプリケーション内の個々のコンポーネントが後方互換性を持つことも必要だ。
氏は次のような結論で講演を終えている。
私たちは開発(dev)と運用(opt)が分離した従来の形から，創造と自動化(あるいは標準化)の分離へと移行しなければなりません。
アプリケーションの機能と運用の進化を実現するのは，その"創造"の側です。反復的な作業(すなわち，従来的な日々の業務)は"自動化"側で自動化されるのです。