Ganesh Prasad 氏の新しいブログポスト "これから SOA を始める組織へのアドバイス (Advice To Organizations Embarking On SOA Today)" は，大規模な SOA 構想にアプローチする方法についての，氏自身の長年の経験を元にしたアドバイスである。
... このアプローチに高尚さが欠けていても心配には及びません。初心者は複雑さに好印象を持つものですが，最終的にすべての人々を感動させられるのは結果なのです。
Ganesh 氏のアプローチが扱う主要なポイントは次のものだ。
- 目標から目をそらさないこと。SOA とは，単に既存システムを接続するインテグレーションや，そのための新技術導入をさすのではない。それは，
... 企業のコンポーネントを単純化して，理解が容易で，相互に接続可能なものにすることです ... そのために「シンプルさ」をいつも心がけてください。ただし「シンプルさ」と「一時しのぎ」を混同してはいけません。「一時しのぎ」が抵抗を最小にする道であるのに対し，「シンプルさ」にはいくらかの努力が必要になるものです。
- データを理解すること。サービスの相互運用には，インタラクションのための "意味的(semantic)" データモデルが必要になる。Ganesh 氏は "代表的な" 標準データモデル(canonical data model) について，現場で使用するには高レベルかつ抽象的に過ぎるものだ，と指摘している。その代わりとして氏は，企業データを複数の論理ドメインに分割して，ドメインごとに辞書を定義する手法を提案する。
論理ドメインの外部にエクスポートされるサービスはすべて，これらの定義を使用しなければなりません。それを理解するのはドメイン外部のサービス利用者の責任になります。論理ドメインを越えてサービスを結合するプロセスは，類似したデータ要素同士を独自にマッピングする必要があります。ただしこれは思うほど大変な処理ではありません。サービスインターフェースを通じて公開されるのは，ドメインが管理するデータ要素のサブセットだからです ... 単一の標準データモデルの「構築」に対して期待しないでください。それは無駄な骨折りです。手をつけるべきでもありません。
- 正しいミドルウェアを選択すること。Ganesh 氏の意見によれば，大部分のケースにおいて，HTTP が SOA 実装に最も適したミドルウェアである。またメッセージキューの使用については，それがどうしても必要な場合でない限り避けるように提案している。その上でデータベースでバックアップされた HTTP ベースの通信パターンが，一般的にはよりシンプルなソリューションを提供するものである，と指摘する。
HTTP は SOA.ESB の論理的インフラ要素として使用されている，ごく一般的なプロトコルです。HTTP では，サービスディレクトリやその他の "管理" コンポーネントは多くの場合，自分自身の役割を行うための複雑性の管理だけを必要とされます。シンプルな Web サーバとデータベースのファームで実現できる内容と，なおもシンプルさと分かりやすさを維持できるという点について，この方法には驚くべきものがあります。
- 正しいサービス実装アプローチを採用すること。 Genesh 氏は SOAP ベースの Web サービスのほとんどが "ベンダーの提供する" 宣伝であると考えていて，可能な限り利用を避けるように勧めている。その代わりの手段として氏は，REST の使用を提唱する。
REST は実際，SOA を行うための有効な手段です。多くの場合，非常に低いコストと複雑性でソリューションを提供する手段として役に立ちます。REST を実行する上での難点は，この方法で物事を考えられるような優れた人々を見つけるのが難しいことです。
- 正しいデータ規約定義を選択すること。ドメインモデルの形式を定義する上で Ganesh 氏は，"標準" XMLアプローチを大げさすぎて厄介なものとして，JSON スキーマを用いる方法 を検討するように提唱する。
Java など高レベル言語で記述された JSON スキーマライブラリがすでに多数あります。XML の落とし穴に落ち込まないためにも，まずは JSON から取り掛かって，徐々に JSON スキーマに取り組んでいく，という手法を試してください ... XML に劣らないくらい厳密で，しかしはるかに複雑性の低いデータ規約を定義することができるはずです。この手法が，REST との組み合わせで特にうまく動作する点にも気付くことでしょう。
- SOA のシンプル性のパラドックスを解決すること。SOA を採用する主な動機は，エンタープライズアーキテクチャの簡素化にある。しかし Ganash 氏によると典型的な SOA 実装では，重量級アプローチの採用によるインテグレーションの複雑化が発生しているのが現実である。そしてその複雑化したシステムを管理するためにツールを導入する，と言う結果になっている。
あなたが政治指向の大きな方であれば，多額の予算と巨大なチームへの名声を手に入れることも可能でしょう。提供するサービス数やプロセス数を基準とした勝利宣言ができるかも知れません。しかし SOA 提供に本当の意味(ビジネスの迅速化，継続的に低コストでの運用実現，など) での成功を望み，なおかつその過程でに資金回転率を低く抑えたいのならば，前記リストのような退屈でぱっとしない，ある意味期待はずれのようなアプローチと技術を選択するべきです。大手ベンダには大きな寝床でも与えておきましょう。(すでに所有している Web サーバやデータベースを越えるような) 新たな技術を購入する理由はありません。ベンダ側が売りたがっている複雑な技術のために出費する必要はまったくないのです。
Prasad 氏のポストは，典型的な SOA 実装作業で突き当たる多くの問題への対処方法である。ある意味では問題に対して，頻繁に用いられる既存のソリューションを否定しているようにも見える。ここから新たな疑問が生じる。すなわち，既存のソリューションを理解して改良する方法がよいのはどのような場合だろうか。既存のソリューションを破棄して新しいアプローチを取り入れるべきなのはいつなのだろうか。新しいものが常によいものなのだろうか？