ThoughtWorksのアーキテクトNeal Ford氏が自身のブログで3回にわたる記事を書いた。そこで氏はベンダがSOAを今日のように認知させてしまったことを批判している。
最初の回(リンク)は、SOAの必要性がどのように生じたかを書いた「戦術 vs 戦略」という記事だ。
氏によると、企業が小さい時はITの必要性もまた小さいという。ビジネスがソフトウェアをより必要とするようになって、企業はさまざまな要求やコーディングをディベロッパに求めるようになる。しかし、アプリケーションの相互運用性について包括的な戦略を考えなくてもいいようなアプリケーションは限られており、そのようなことを考える時間もない。この段階では、ソフトウェアを作る理由は詰まるところビジネスを継続するためだ。そして企業がそれなりの規模になってから自社のITシステムがとんでもないものであることに気付く。あまりに多すぎるコードの重複やデータベース内のデータの重複、などなど。このようなことが起きるよくある理由について氏はこう述べている。
･･･それには2つの理由があります。一つは、包括的な戦略を構築するための時間があった時、（それなりの規模になる前の）会社であればなるべく抵抗のない方法を採ろうとするためです。まだ会社として生き残れるか分からないからです。二つめは、もっと重要なのですが、ビジネス上の戦略はITにとって戦術としかならないためです。
ここでの問題は、ITがビジネスほど敏速でないことだ。ビジネス側の決定と主導に対してITは常に戦術的に対応するしかないのだ。
どんなに包括的で美しく優れた設計のエンタープライズアーキテクチャを構築したとしても、ビジネスの決定が以前にされたものと変わってしまえば吹き飛んでしまいます。大手のベンダによるSOAの売り文句は、堅固なエンタープライズアーキテクチャを作れるというものです。しかしその戦略的な大伽藍も、現実世界でCOO（最高執行責任者）やCEO（最高経営責任者）によってCIO（最高情報責任者）やCTO（最高技術責任者）の決定が覆されれば崩壊してしまうのです。ビジネスを長期的に行うにはITにどれだけの性能・機能がないといけないかという戦略について組織を説得できる立場にあるのであれば、それはすべきことです。しかし組織がそのようなITの大伽藍を準備している間に、もっと身軽な競合他社がそのビジネスを食べあさり出すでしょう。
第2回目(リンク)の記事は「標準ベースのSOA vs SOAのための標準化したアプローチ」だ。
ソフトウェアベンダによって唱えられる主なマーケティング文句のひとつは、標準ベースのESB実装によって全てのSOA問題に対するソリューションが得られるというものだ。ここでの問題は次の点だ。
これらESBは標準ベースではありますが、標準化はされていません。この違いは重要です。既存のESBではあらゆる所で標準を利用していますが、それら全てをまとめられるのはプロプライエタリ（独占的）な結び付きがあるからです。そのような結び付きは管理ツールやBPEL（Business Process Execution Language：ビジネスプロセスモデリング言語のひとつ）デザイナの動き、設定の仕方、ルーティングの使い方などを見てみると分かります。そういったものは枚挙にいとまがありません。ESBのベンダはSunがJ2EEで押し通そうとする標準化の類を決して許そうとはしません。ベンダが望むものは結局のところ自分たちの（お金を異常なまでに生み出す）ソフトウェアの子孫も欠かせないソフトウェアへすることなのです。ベンダは真の標準を作ろうという仕草を見せるでしょうが、実際にそんなことは起きえません。ESBベンダがなりたいのはアプリケーションサーバのベンダのようにではなく、データベースベンダのようになりたいのです。
このことは商用製品についてだけでなく、オープンソース製品についてもいえる。そのような製品のベンダはコンサルティングやトレーニングやサポートを売っている（たとえばJBoss、Mule、Fuseなどがそうだ）。どのベンダも自分たちのプロプライエタリな結び付けとツールの利用にユーザを固定したいという考えているのだ。
最後の第3回(リンク)は「SOAのツールとその束縛」だ。
氏は、見た目のいい単純なSOAのデモ版製品に感心してしまうことの危険についても触れている。このようなデモ版は全てのSOA問題を解決するソリューションとしてベンダがよく出しているものだ。
ベンダのお気に入りのデモウェアは自社のBPELデザイナです。そのデザイナで四角と四角の間を線で結べばサービスをつなぎあわせることができます。その線は変換やその他の魅力的なこともこなせます。そしてこのデモがまた素敵なのです。「いいですか、ここに線をいくつか描いて実行ボタンを押せば、ほら! 即席SOAのできあがりです!」
よく経営者はこのようなデモに興奮して、この新しいツールを使ってSOAを導入するようディベロッパに指示を出す。この時によくある問題は、物事の間の全てのつながりが明らかに分かる時であれば、この小さな「おもちゃ」デモ版がうまく機能することだ。しかし物事が複雑になるにつれて面倒は雪だるま式に増えていく。たとえば全ての線を同時に実行したり、複雑すぎて意味のある図が作れなくなったり。このようになってしまう理由を氏はグラフィカル言語（および自動生成）のせいだと考える。一般的に言って、グラフィカル言語は複雑なシステムの構築、特にビジネスプロセスの定義にはむいていない。そのような言語の問題について氏は次のことを指摘している。
- 再利用：ワークフローの一部分を再利用しようにも、そのための方法やサブルーチン機能がないためにできません（もしサブワークフローがあれば可能性はなきにしもあらずです）。多くの場合「再利用」は図のコピー・アンド・ペーストでおこなわれ、コードの再利用にはなりません。
- リファクタリング：共通のワークフローの集まりを再利用するのに欠かせないリファクタリングができません。リファクタリングができないということは、リファクタリングを見越した作業ができないということでもあります。
- 限られたプログラミング性：BPELにif文やforループはなく、個々のBPELデザイナがそのような機能をサポートしているかどうかにかかっています。フローチャート風の図を代わりに使えるとしても、それはモダンな言語の持つ機能に比べればずっと脆弱なものにすぎません。
- テスト：ワークフローについての単体テスト、機能テスト、総合テストをおこなうことができません。事実上ユーザ受け入れが唯一の選択肢となりますが、そのためには全てが出来上がって実行可能になっていないといけません。単体テストができないと、コードでは一般的なモックオブジェクトなどのテスト技法も使えません。
- 差分抽出：仮にややこしい問題があって、そのためにややこしいワークフローを作り動かしたとして、それでも全てがうまくいったとしましょう。そしてその半年後、ややこしい方法でややこしいワークフローを変えたとして、それもうまくいったとします。しかし今度は最初との違いを知らなければならなくなりました。BPEL ツールには差分抽出機能はないので、目視で全ての図の違いを見つけるか（ひどい！）、2つの1万行XML文書の差分を取る（もっとひどい！）かしかありません。BPELの拠り所は重量級の描画ツールあるいは重量級の生XMLのどちらかで、その中間には存在するものはありません。
これらのツールは「doodleware」、つまり感じの良い絵を描くことには長けているがその絵を実現するには役立たないものだと氏は考えている。この問題に対する氏の解決策は「コードでできることをする」というものだ。
これら一連の記事、はSOA/BPMとそのベンダの現状についての興味深い視点を与えてくれる。大手ベンダは自社製品を売ろうと表に出てきて、その結果として製品の性能が誇張されることがしばしばあると多くの人が言っている。またSOAテクノロジが多くの既存ビジネスの問題を解決する手段としてよく用いられるということもしばしば言われる。また一方では、ディベロッパの生産性を向上させるにはより高度な（ドメイン特有の）ツールや言語が不可欠であると多くの実践者が考えている。ある人たちはソフトウェア工学史を、利用の容易なソフトウェアシステムをデザインすること（実際アセンブラを使った開発はもうないも同然だ）という観点で見て、多くの場合そのことが大手ソフトウェアベンダの製品のメリットであると考えている。みなさんはどう考えられるだろう？Neal Ford氏の批判が正しいと思われる、あるいはSOA導入において適切なアプローチやツール/ミドルウェアを決定に関することは純粋にソフトウェアアーキテクトやSOAアーキテクトの責任だと思われるだろうか？ソフトウェアベンダ（や経営層）の間違った決定をソフトウェアベンダたち自身のせいにしようとするのは単なる言い訳にすぎないだろうか？
原文はこちらです：http://www.infoq.com/news/2009/02/TarpitofIrrelevancy