Cap GeminiのSteve Jones氏には，何年も前から，SOAについて言いたいことがたくさんあった。その氏が最近のDevOpsについて，“DevOpsをスケールアップしようとして問題に突き当たっている企業をよく見かけるのだが，DevOpsチームにとって適切な限界線は，本当はどこにあるのだろう？”と，疑問を呈している。DevOpsは正確には(まったく)新しいものではないが，長年使われてきた慣行の進化形ではある，と言う氏は，次のような指摘をする。
2007年の事になりますが，SOAがビジネス上の問題である理由について私がプレゼンテーションした中に，サービスについての認識を変える必要を示す図が２つありました。
最初の図は，“ライフサイクル全体を考慮する必要があること”を示している。
そして第２の図は，“アーキテクトとオーナ，そしてデリバリマネージャ(プログラムマネージャ)の必要性”に関わるものだ。
DevOpsが標準的なプラクティスとなったことを氏が嬉しく思うのは，2007年に自らが指摘したように，これがまさに，さまざまなSOA実践者が行ってきたことであり，アーキテクトと開発担当者がライフサイクル全体に対して責任を負うものだったからだ。その結果として氏は，過去何年間の優れたプラクティスや教訓からも，今日学ぶべきものは数多くある，と考えている。その一方で，“DevOpsとは何なのか，そのようなチームを数多く管理するにはどうすればよいのか”，という疑問に対しては，いまだ答を見出すことができていない。
ここはビジネスアーキテクチャに関わる部分です。DevOpsチームの数が単に多いだけでは十分ではありません。それらチームがビジネスオーナのために一致団結し，管理運営する組織の構造に従うことが必要なのです。
そしてもちろん，適切なサービスを適切な時に利用できるような，プロセスや組織構造も必要だ。
このように，DevOpsの世界で私たちは，ビジネスサービスにおけるライフサイクルのすべてを現実化することによって，ビジネスと同じように振る舞い，ビジネスとともに進化して，提供する価値を最大化するためのコストに集中可能な構造をビジネスに提供する，そのようなサービスを自動化し，管理するための技術的アプローチを提供しようとしているのです。
結論として氏は，今日のDevOpsにおいても，特にチームの編成と管理の方法，ビジネスとの整合性確保といった分野では，ビジネスアーキテクチャから学ぶ余地が多々あると考えている。さらに，これらの教訓から学ぶことで，DevOpsは“従来型の複雑な組織にも，よりシンプルな(ビジネスモデルの観点から)インターネット企業にも”スケールアップ可能になるだろう，というのが氏の見解だ。