SOAコミュニティで長い間静かだった、SOAへのトップダウン対ボトムアップのアプローチについての議論が、最近再び始まった。それは、オープンソースのESB開発会社であるMuleSoftが 管理コンソールのリリースを公表した 際に、SOAの管理哲学にボトムアップなアプローチをサポートする、と言ってから始まった。
SearchSOAのRob Barry氏は、トップダウン対ボトムアップのアプローチについて、いくつか意見を集めた :
SOAを作り上げる時、ボトムアップな管理アプローチは、即座に組み立てられる、個々のESBに関わるサービスを統合することに焦点が集まる。このアプローチは、後で過度のアップデートとリワークが必要になる、と批判されてきた。一方、反対の「トップダウン」な管理アプローチは、広範囲な計画と厳しいポリシーの強制が必要である。このアプローチは、結果を出すまでに、ずっと時間がかかるので、失敗してきた。
投稿に集まった意見が一致している点は：ボトムアップは、基本的に主たる目的が統合することであるなら、始めるには良いアプローチである。トップダウン アプローチは、もっとずっとビジネスを巻き込む必要がある、ということでも皆一致している。彼らの結論は、どちらの戦略を使うか決めるのは、ビジネスとITの関係による、ということである。
Barry氏の投稿を基に、ebizQで 質問を行った ら少ないが面白い回答があった。 ebizQの質問に答えて、 Avi Rosenthal氏は、何を作るかによって、両方のアプローチを区別している:
SOAは、アーキテクチャ上のスタイルであり、アーキテクチャを作るには、トップダウンで、ボトムアップなどない。webサービスは、時々間違ってSOAだと定義されるが、技術的なことである。webサービスは、ボトムアップで作られる。SOAをボトムアップで作るのは、間違ったアプローチで、時々 ABOS (A Bunch Of Services、山のようなサービス)と呼ばれる。もしSOAをボトムアップで作ったら、おそらく、ものすごく冗長なものができ、アーキテクチャなどないだろう。しかし、SOAをトップダウンだけで作ったら、知覚的なアーキテクチャとなり、動く成果物とはならないだろう。なのでSOAの工程の一部は、ボトムアップであるべきである。まとめると：SOAの始めは、トップダウン アプローチだが、実践的なアプローチは、トップダウンとボトムアップが混じったアプローチなる。
この質問への別の回答で、 Michael Poulin氏は、SOAのコンシューマ中心の性質がトップダウンのアプローチを強制する、と言っている:
もしサービスの構築を、今持っているものから始める－ボトムアップ－と結局、持っているもので終り、コンシューマが必要とするものを作らないで終わってしまう、リスクが非常に高い。SOAは、コンシューマ中心、ビジネス指向のアーキテクチャである。コンシューマのニーズから始めれば、トップダウンを避ける可能性など無い。いつも、これが出発点だ。しかし、次の段階では、自分の能力を評価すべきである、すなわち、開発基盤を形成しているリソースの観点から、コンシューマのニーズを見るべきである。
この議論は、新しいものではない。2005年に遡って、John Crupi 氏は、投稿で、SOAは、 ビジネス駆動なアーキテクチャ スタイルであり、そうであるなら、成功するには、トップダウンでなけばならない、と言っていた:
そしてトップダウン、の意味するのは、アーキテクチャとソリューションの問題に取り組む、ということである。今持っているものから開発して、自分たちにできる新しい技術で、それを覆い隠す、ことではない。このボトムアップなアプローチは、極めて自然で、簡単だが、SOAが失敗するための完璧なレシピである。
その頃の他の意見には、Bill de hOra氏のそれに対する投稿 は、「トップダウンか失敗の原則か」の考えに反対している:
トップダウンだけのアプローチが難しいのは、トップがないことである。実際には、SOAシステムは、分散化する傾向がある － アーキテクチャ上の力や統治の中心点は無い。「10分で決めたり、次のは無料だ」と言って、実行できる人は、一人もいない。
この論争は、何年もされてきた。結局、あるツールベンダーは、ボトムアップ戦略を選んだようだ。