アーキテクトが回避すべきSOAの8つの間違い
原題 : 8 SOA mistakes architects should avoid
著者 : Bernhard Escherich, SAP Deutschland AG & Co.KG (顔写真は右上)
初出 : Posted on Feb. 22, 2009 02:13 AM 原文はこちら。
SOAの検討において、間違った方向の悲観的なアプローチがなされていることが、いくつかのブログから読み取れる。しかし、そういった意見は私にとっては非常な驚きである。私が仕事をさせてもらっている業界 - 公共分野、健康・保険、国防や警察などでは、SOAは優勢であり、が全体アーキテクチャを貫く原理として強調されてない案件はほとんど無いといってよい。SAPのCTO ヴィシャル・シッカは、すでにこういった議論に非常に有用な洞察をコミュニティに提供している。
ここではアーキテクトの視点から、いくつかのポイントを付け加えたいと思う。
私見では、これはSOAアプローチそのものではなく、我々アーキテクトがSOAでいかに働くべきかを示している。以下の「間違い」のいくつかは、実際のSOAプロジェクトで私が目の当たりにしたものである。その他、SAPのエキスパート、お客様やパートナー各社に所属するアーキテクトや意志決定者等とのディスカッションで発見したものを基にしている。これを記そうと思った私の意図は単純だ。今後これらの間違いを回避して、SOAのアプローチを強化する助けになるだろうと思ったからだ。 - 他の誰のためでもない。自分のために。
アーキテクトのビジネスプロセスノウハウが不十分(知識面でのギャップ)
サービス・オリエンテッド・アーキテクチャ(SOA)は新しいタイプのアーキテクト、すなわちビジネス要件の深い理解と素晴らしい技術スキルを併せ持った人物を要求する。一例を挙げると、大規模災害に対する管理(ディザスターマネジメント）だ。SOAで構築することで大規模災害から回復する操作をどのように改善できるか、の多数のリサーチがここ数年で行われている。現実には、大規模災害管理の統括責任者は無能であるはずが無い。あなたがもし、次に挙げるようなことを明確に知らないとしたら、あなたの提唱するアーキテクチャが採用されることはないだろう。すなわち、大規模災害管理における運用がどのように指揮・統括されるか、それらの中で重要なプロセスはなにか、統括責任者の視点で本当の難しさ・苦しい点はどこだ、などだ。SOKNOS*1チームがどのようにこの課題に立ち向かっているかが好例だ。アーキテクトにとってSOAは過去の導入プロジェクトと比較してもたいへん広範なアプローチを意味しており、多数のSOAプロジェクトは更に広範なビジネスプロセスを対象とするようになってきているといえる。
経営者(Cレベル)に対する最初のプレゼンで、SOAという単語を2度以上使う(プレゼンでのギャップ)
意志決定者にWebサービスとWeb標準について、それも3枚のスライドだけで、プレゼンする機会が必ずあるはずだ。その際、SOAという単語を複数用いるのは避けよう。エグゼクティブは技術的詳細に興味がないか、あるいはすでに知っているかのどちらか(または、相手がCレベルのエグゼクティブでないか)。彼らの興味の対象はビジネス改善であって、これを間違えると、別の方面の改善の話題にミスリードしてしまう。
アーキテクト自身が、提案しているSOAの具体的なビジネス例を説明できない(事例ギャップ)
SOAプロジェクトは、単純な文章で説明可能な明確なビジネスケースを持つべきだ。a)とb)とどちらが優れているか?
a) 人事領域をSOAで構築したいと思う。このやり方で、より変化に対応しやすく、より良いサービスを作りたい。
b) 新しい製品の研修費用を削減したい。これまで別の支社で、別のシステム上で作られた教材を再利用することでそれを達成する。
a)に正当性はあるが、購入動機を喚起することはできない。一方、b)はそれがもっと簡単だ。といっても、後者のアプローチは、前者の手段で達成できる単に具体的なビジネスケースを述べたにすぎない。
アーキテクトがSDNにある “ES Bundles” を知らない
SAPのSOAアプローチは他と異なっている。ESはあらかじめ “ビジネスナレッジ” を含んでいる。上述のケースなら、 ある “ES Bundle” がとても役に立つはずだ。誤解してほしくないのは、ある “ES Bundle” がすべての課題を解決するわけではない。ケースは限定されている。しかし、つぎの文章はあきらかに実証できる。「SAPプラットフォーム上のSOAは単なる技術ではなく、SAPによって提供されたビジネスコンテンツと技術の融合なのだ。ESワークプレイスの深い知識はすべてのアーキテクトに必携である。」
アーキテクト自身にSOAの経験がない
SOAプロジェクトでは、ビジネス知識は技術知識の置き換えにはならない。これまでビジネス知識の必要性を強調してきた。が、一方、アーキテクトにはSOAの実地経験が絶対に必要だ。あなたは今後単純なサービスすら開発をしないかもしれない。しかし、その経験がなければ技術者からそれを受け入れ検収することはできないだろう。そのエンタープライズサービスの粒度は妥当か？どのサービスが連動して動くのか？どう判断したらよいのだろう。
簡単な練習をしてみよう：
最近あなたが手がけた導入プロジェクトを思い出してほしい。いくつかのシステムが連動して動く、SOA化されてないものがよい。その中で小さなビジネスケースを想定して５個サービスを定義してみよう（例えば電子請求のようなもの）。ただし、ESバンドルの考慮はしないこと！
アーキテクトが最初のSOAデザイン時にUIに集中してしまう
ユーザーエクスペリエンス(システムの使い勝手)はシステムがユーザに受け入れられるかどうかの最重要要素だ。これはSAPコミュニティ全員が熟知し、支持している。しかしSOAにおいては、すこしそれから距離をおく必要がある。SOAでサービスを提供すると、あらゆるユーザへのUIを管理することができなくなるばかりか、時にはどのようにUIが提供されているかすらわからなくなってしまう。健康保険のネットワークを考えてみよう。開業医、病院、保険会社、その他たくさんのユーザが接続されている。どのUIがシステムを通して使われているか、特定は不可能だ。
アーキテクトが既存システムにとらわれすぎる
SOA以前のSAPワールドで、私は多数のインタフェースおよび統合に関する問題を解決するために働いた。何度も繰り返された主要な疑問は、そのデータを受けるシステムがどう動くはずなのか、そして実際にどう動くか、ということだった。SOAは抽象概念であり、時にはどのシステムがサービスを消費するのか把握することすらできないことを意味するので、結果を受け取る側のシステムについて考えることは時間の浪費にしかならない。ただし、あなたのサービス定義が正しければという前提はある。しかし古い習慣はなかなか捨てられない - die hard - ものだ。
アーキテクトが業界標準をよく理解していない
業界の標準はSOA世界にますます重要度を増してきている。HL7は、ヘルスケア業界では有名な例だ。よいサービスを使って有用なアーキテクチャをモデル化するために、アーキテクトはそういった標準をよく知らなければならない。ただ、そういった標準規格の専門家の数は限られていることは誰もが同意すると思うが。
私はSOAが、次の数年でこれまで以上に使われるようになることを確信している。そして最初に挙げたようなSOAの未来についての悲観的な見通しは次第に忘れ去られることだろう。SOAへの道はまさに始まったばかりだ。アーキテクトとして、私たちはSOAプロジェクトの成功へのキープレイヤーとなるべきだ。
Bernhard Escherich is a strategic solution architect from SAP.
