たかがSOAされどSOA

　３文字略語にするのがいけないんですよ。
　うまい日本語で表現したほうが理解してもらえると思うのですけれどね。
（マーケッター的には煙に巻ける３文字略語のほうが都合がいいでしょうけれど）

> 実は自分で書いた

あります、あります :-)
昔、あるテクノロジについて取材側と受け手（当時の社長）の両方がよくわかっていなくて、明後日の方向に進んでしまったのをレビュー時に全面修正したこともあります :-)
取材者にきちんと理解してもらえる受け答えでないとしたら、それは問題かもしれませんが、取材者が介在することでかえって難しくなったりしますからね^_^;

> SOAとはアプリケーションまたがって共用できるサブルーチンを作りましょうというだけ

意図はわかりますが、単純さを強調しすぎると「Webサービスやっとけば、SOA」という誤解を招きかねない気もしますね。
たとえば、かつてのオブジェクト指向プログラミング（OOP）も、「クラスやっとけば、OOP」というわけではありませんでした。というより、OOPではクラスをうまく作らないと、それがアプリケーション全体の品質に影響してしまうので、アプリケーション全体の構成を考えられる人が、基盤部分を作る必要がありました（あるいは、できあいのフレームワークを使う）。
SOAも同じで、システム全体を見渡せない人が共用ルーチン（サービス）を作ろうとすると「使えないサービス」が乱造されてしまう気がします。そして、OOPと違って「全体を見渡す人」は開発者ではないかもしれません。そこにある種の難しさがあるのは、しかたがないと思います。
このあたりをうまく説明しないと、いつぞやのCognos/CPMの話みたいに、短絡的に「なんか、SOAって使えねー」とか烙印を押されかねないと危惧します。

うーむ。ただ、概念が単純であるということと、実現が単純であることは分けた方がよい気がします。
SOAについて言えば、（リンク先の広告記事にも書いたように）確かに（正しい形での）実現は大変ですが、概念としては単純だと思います。
OOPについては概念の方もちょっと複雑ですよね。汎化階層の考え方は理解に時間がかかりました。

OOPなんて生物を分類する階層と同じようなもんですから・・とよく説明していた気がします :-)　これが「単純」といえるかどうかは微妙かもしれませんが、ここから実際のアプリケーションにうまく適用してもらうのは大変でしたね。
「アプリケーションにまたがって共用できるサブルーチン」というレベルだと、COM+やCORBAの時代からあった分散化の話とかぶるかなという気もします^_^;

CORBAとSOAは結構かぶってると思いますよ。CORBAベースのSOAの構築事例もありますし。
結局、CORBAやCOM+でできなかった目標を、Webサービスという業界のコンセンサスが（一応）得られた仕組みで実現しようと言うのが今のSOAの姿だと思います。

もともとプロトコルが本質でないという点では同意です。CORBAはそれなりに普及したので、（SOAと意識せずとも）SOAを実現していた例はけっこうあるかなと思います。たぶん、そういう実績のあるところはWebサービスも、すんなり取り入れている気はしますが。元の記事の調査で、「分散」とか「CORBA」がテーマだったら、どれくらい数字が違ったのか気になりますね。
「尾ひれ」がついて、遠いところに感じられてしまうとしたら、残念なことです。