最良の結果を得るために、「私たちは何を学んだのか?」と振り返って問いかけをすることには価値があります。赤の女王仮説の時代、パラドックス（逆説）は効果的学習であり、過去の種まきから収穫するために時々時間をとることが、オンタイムの品質結果を得るためにますます必要になっています。今日の難問は長い間変わっておらず、今日の答えは、サービスです。そのため、私はサービスに矢を向けます。
モデルとシステム
モデルは日常的現実の単純化した表現です。システムは、ユニバースまたはその一部が要素および要素間の関係の形式でモデル化された、特殊なモデルです。システム内では、サブシステム、特定の特性を共有する要素のサブセット、およびアスペクトシステム、特定の特性を共有する関係のサブセットを定義できます。さらに、すべてが再帰的です。一連のシステムはそれ自体で1つのシステムです。1940年代に発見されたシステム理論は、21世紀問題のアナリストと解決者が研究中の複雑さを理解しようとする努力を支援できる状態の、大量の概念的基盤を提供します[1]、[2]、[3]。
モデルおよびシステムを構築する理由は、私たちの周りのユニバースまたは私たちの内部の、一部あるいは特定の側面をより良く理解するためです。その理解というのは、私たちが省略し、抽出した部分と側面の洞察と理解を犠牲にして得られます。モデルの範囲は、私たちの目的や、学習したいこと、または通じていたいことに応じて選択されます。モデルの作成は目的のある取り組みです。数学的モデルは、重要な一面で他のモデルとは異なります。数学は、公理を定義することによって、独自のユニバースを作成します。数学的モデルの中では、ファジー論理を使用する場合でさえ、物事ははっきりしています。自然数の集合において、すべての数は奇数か偶数のいずれかであり、他の偶数と多少でも同等の偶数は存在しません。私たちが知っているようなユニバースとは、なんて異なるのでしょう!
すべてのものがあいまいである
現実世界では、すべてのものがある程度あいまいです。そして、明確にしようと試みるまで、そのことに気付かないものです。明確なものはすべて、私たちが通常考えていることとは非常にかけ離れています。人が考えを述べているときに、それが本当に意味していることを想像することなどできません[4]。
私たちは数学的抽象化に非常に精通し、扱いに慣れているため、このことを忘れがちです。そして、これを忘れたときに、モデルを現実世界と取り違えます。数学は素晴らしいです。数学のおかげで、現実世界の多くの問題は解決されます。しかし、現実世界の数学的モデルを積極的に使用するすべての技術者が、モデルは単にモデルであるということを知っています。現実のものには多義性があるため、そこからの逸脱は、モデルにおいては、当たり前のことです。このモデルの二面性は、私の教師の1人を「モデルを信じるな。モデルを無視するな。」という格言に導きました。モデルを現実のものと取り違えないでください。物事はモデルから疎外されていることを認識してください: 前もって驚かせておきます。とは言っても、できる限りモデルを使用してください。モデルは、人間の脳には複雑過ぎる世界で生き残るための助けとなるでしょう。
モデルは複雑さを増大させるか?
モデルは、いったん記述されると、ユニバースの一部になります。それはある種、直観に反し歓迎されません。複雑さを理解することを意図してモデルを作成し始めると、ユニバースをさらに複雑な状態にしてしまいます。これについて言うべき3つのことがあります。1つ目: 複雑さはすべて、あなたの観点によるものです。大局的観点から、その複雑さが増していることは事実です。しかし、局所的観点からは、よく形成されているモデルは、複雑さを理解するのに確実に役立ちます。その法則の例は、無料のランチなどないということです: よく言われるように、局所的な利益のコストは大域的な損失です。2つ目: モデルをユニバースに追加すると、あいまいさが生まれます。carクラスからインスタンスを作成したcarオブジェクトは、GMの生産ラインから生み出される車とは確実に異なります。ですから、現実世界とモデルの両方が会話の範囲にあるときは、慎重に言葉を選ぶ必要があります。3つ目: 専門家は、自身が働いている会社と、社会全体に対しての責任があります。専門家は、非常に健全な理由なしに、複雑さに加えるべきではありません。
サービス
サービス、サービス指向、サービス指向アーキテクチャ。古いもの、新しいもの、人から借りたもの、青い物（花嫁が身に付けると幸せになるといわれるもの）。古いワインでしょうか、それとも真の革新でしょうか? 私の意見では、両方です。サービスの領域において二者択一の誤った考えから離れていれば、得られるものは多くあります。CORBAの再訪であるという主張を探すのではなく、もっと広く考えてください。古くて、よく理解され、実際に適用された理論は多く存在するため、それはサービス世界の革新部分の利益を得る助けとなります。この記事のみの目的で、「サービス」という概念をより確実に理解するためにモデルを作成しましょう。この記事の最後にはモデルを元に戻すので、全体的な複雑さへの害はありません。
私が提案するモデルは次の4つのコンポーネントで構成されます: メモリ、プロセッサ、メモリとプロセッサ間の接続、およびアクチュエータです。メモリとは、宇宙におけるすべての内部メモリとマシン可読メモリを表します。これと同じことが、プロセッサ、接続、そして最後の項目であるアクチュエータ（インターネットなど）にも言えます。アクチュエータは、そのユニバースにおけるすべてのマシンと人間を表します。これは便宜上、メモリに直接作用できる、すなわちメモリの読み書きができるマシンと人間です。プロセッサ、接続、およびメモリの組み合わせがマシンであるため、再帰的プロセスを記述するためにモデルを使用できます。
モデルから洞察を得る
このモデルの詳細設計は読者の方に任せます。たとえば、実行プロセスの記述における特定の結果に伴って、メモリ内またはプロセッサ内に実行可能プログラムを置くことが可能です。しかし、緩く記述されたモデルでさえ、1950年代のアセンブラ時代のサブルーチンへの呼び出しは、息の長いCobolのPERFORMおよび2008年のWeb 2.0+時代のWebサービスと同じであることは、明確です。
何が起きるでしょうか? どんなプロセスでしようか? 任意に、収集されるデータがあります。次に、ユニバースの異なる部分に対して何かするようにリクエストがあり、多くの場合はパラメータとして収集データが提供されます。この後、直接またはしばらく経過してから、コードの実行が続きます。その一部としてリクエストはユニバースのさらに別の部分に送信されるなどの可能性があります。実行が完了すると、メッセージはその作業が実行されるリクエスタに送信されます。これには何らかのデータが伴うことがあります。
したがって、どうなったでしょうか? 私の最初の見解は、このすべてにおいて、サービスを指し示すことはできないということです。シンプルなモデルに流れるすべての電流において、サービスが実際に何であるかを指し示すことは困難です。それはかなり、私たちが知っている名前です。残りに関して、次のプロセスステップがあります: 呼び出し、コードの実行、特定のメモリに保存された値の変更、特定のメモリの値が特定の値を得るか超えた場合のアクションなどです。私たちは、サービスは具象化であり、それに名前を付けることで存在のようなものを抽象化したと結論を下してもよいでしょうか? それとも、サービスは、これらのアクティビティが起こるために出現する、創発特性、付帯現象でしようか? 私は、言葉遊びには多くの価値があるとは思わないため、サービスに名前を付ける能力に満足であるべきであり、これ以上質問の余地はありません。
サブルーチン時代の分岐以来、何が変化していますか? ダーウィン以来、私たちは現実世界に本質（essentials）が存在しないことを知っていますが、ITシステムは数学的モデルに近接しており、特定の制約の中で質問することはフェアです: レガシーアプリケーションと比べて現代のアプリケーションには、サービス概念を価値あるものにする、どのような本質の違いがありますか? この質問の答えは簡単です: 複雑さです。アセンブラ時代、相互参照表が、自身のサービスと、それらがどこで誰に使用されるかの概観を得るために必要なすべてでした。この話の2008年Webサービスバージョンでは、サービスの開発と使用を導くためのモデルとシステムが本当に必要です。サービスはすべてのレベルで複雑です。細部に隠れている悪魔の例が必要なら、実用化されているサービス指向を調べてください。サービスを、それを使用してビジネスプロセスを作成するためにビジネスで使用できる形で利用可能にすることは複雑です。それには、ビジネス用語でサービスの目標を述べるサービスディレクトリが必要です。技術レベルでは、サービス環境においてシームレスに連動する必要があるさまざまなプラットフォームおよびネットワーク技術による複雑さが多くあります。設計および構築レベルでは、これらのビジネス指向およびテクノロジー指向の要素は一緒に組み入れられます。配備されたら、サービスレベルを満たさなければなりません。そして、世界のすべてが、すべての領域で、日々の変化の投与を非常に好んでいます。そのため、持続するように構築することには何の価値もなく、サービスは変化するように構築する必要があります。そして、私は情報セキュリティについてあえて言及もしませんでした!
もしサービスが興味深いものでなかったら、これはすべてまったく無関係だったでしょう。実際は、正反対です。アジリティ（俊敏性）の約束が伴うため、ビジネスはそれらを非常に好みます!
素早く行動するためには、私たちは巨人の肩の上に立つ必要があります。結合と結束、構造化された分析と設計、カプセル化の概念、パターンの使用、手に取りさえすればすべてが盛り込まれています [5]、 [6]、 [7]。
単語
サービス指向と組み合わせて特に用いられる単語は、アーキテクチャ、成熟度モデル、ロードマップ、およびガバナンスです。この領域で行うべき複雑さの低減はありますか? 私はあると思います。
成熟度モデルはベストプラクティスについてです。つまり、成熟度モデルは、一定の条件の下で高品質の結果をもたらす実際の既存のプロセスについてです。成熟度モデルの使用により、重要性があると判明したプロセス領域に注意を向けることでより高いパフォーマンスレベルを達成するよう組織を導くことができます。このように使用される成熟度モデルはロードマップの役割を果たします: 旅行中、出発地から目的地までを案内します。しかし別の種類のロードマップが存在します。そのロードマップでは、目的地は、私たちがいわゆる目的地の実在を指し示すことができるという意味で、不明です。その代わり、目的地は、知覚可能な、宣言された望ましい状況です。そのような状況における次のステップは、中間ステップで手元の状況と天国（Nirvana）の間のギャップを埋めることです。それどころか、この種の移行には少しも悪いところはありません。しかし、してはいけないことは、結果のモデルを成熟度モデルと呼ぶことです。それをすると、概念の成熟度モデルの意味を無意味にするほどに拡大することになります。これが行われると、相殺する局所的な複雑さの低減なしで、大域的な複雑さのみが追加されます。
サービス指向は全く異なるものでしょうか? ある見解からは、そのとおりです。サービス指向は、単にその違いに基づいて独自の成熟度モデル、ガバナンスなどが必要でしょうか? それは時と場合によります。ビジネスプロセスからXMLおよびセマンティックインターフェイスの範囲に及ぶ可能性がある、サービス指向と同じくらい広範なものの包括的な成熟モデルの開発は、些細なタスクではありません。できるだけ、私たちはすぐに入手できる要素を使用して、計画した利用に間に合うようにそのような成熟度モデルを用意するべきです。PhotoshopとEclipseと同じくらいかけ離れているアプリケーションには、まさにそれを行うための同じメカニズムがあります: それはプラグインです。特にサービス指向のコンテキストでは、再利用のために既存のモデルを評価することが、最初のステップです。プラグインの観点でとらえると、CMMI、ITIL、COBITのような多くのモデルが、サービス指向の実装スピードとビジネスの成功に貢献できます。
ここでもまた、「シンプルに保て」という格言があります。「物事は可能な限り単純化されるべきである。ただし、それ以上単純にしてはいけない」というアインシュタインの格言を固く守って、モデルを追加しなければ悪くなるというのでない限り、モデルを追加しないでください。単語の確立された意味に固執してください: 成熟度モデルはベストプラクティスについてであり、ロードマップはRand McNally（アメリカで最も伝統ある地図出版社）形式で既知の目的地にたどり着くために使用され、移行計画は天国（Nirvana）に到達するためのものです。そして、最後に大切なことを言いますが、再利用、再利用、再利用です。
単語についての最後の単語: ABC
ABC（academics, business and consultants; アカデミック、ビジネス、コンサルタント）として知られている、悪名高いトリオが存在します。アカデミックは新しい理論を作り出します。コンサルタントは、これらの理論をビジネスにとって受け入れやすい個別の独自の言葉で言い換えます。そして、ビジネスは、コンサルタントに金を払い、アカデミックには組織内をうろついて新しい理論を根付かせる材料を集める機会を与えます。この領域で金を得るためには、明確な特定の意味がある単語を使用してはならないことが明らかです。その代わりに、再定義ゲームをします。マーケティングの言葉で言うと、「差別化」するのです。ただし、同じ作用で、単語ゲームが多いと、仕事は少なくなります。このようなプロセスは、なぜ新しいモデルが非常に多くあり、モデルを変化に適応させるためのイニシアチブ、または用途に適用させるためのイニシアチブ、そして最新の状態に保つためのイニシアチブが非常に少ないのかを説明できるでしょうか?
ファイルの最後
モデルは、あなた自身やあなたの目標にとってあまり関心のない側面や部分から抽出すべく存在するということを覚えておいてください。コンサルタントの話を伝えるために作成されたモデルは、あなたの問題を解決するために必ずしも役立つというわけではありません。Mark Anthony Luhrmann氏は次のように言っています: 「誰の助言を受け入れるかを慎重に考えなさい。ただし、助言してくれる人の話は辛抱強く聞きなさい。助言は懐古のひとつの形です。助言することは、ゴミの山から過去を拾ってきて丁寧に汚れを拭ってやり、汚い部分はペンキを塗りなおし、本来の価値以上に使うことに似ています。」
この記事がサービスであったなら、要求は「どのようにサービス指向を収穫できるのか」ということかもしれません。そして、送り返されるデータには「新しいものを明らかにしなさい。新しいものを習得するために投資しなさい。あなた自身、そしてあなたより前に他の人が、それに多少なりとも似ていることをたくさん学んだということを忘れてはなりません。それを再利用しなさい。新しい部分は複雑です。再利用は困難です。神のご加護がありますように。」と示されているでしょう。
[1] Kenneth E. Boulding、1956年、General Systems Theory, The Skeleton of Science、In: Management Science, 2, 3 (Apr. 1956) pp.197-208; General Systems, Yearbook of the Society for General Systems Research, vol. 1, 1956復刻版
[2] W. Ross Ashby、1956年、An Introduction to Cybernetics, London, Chapman & Hall (PDF)
[3] Ludwig von Bertalanffy、1968年、General System Theory: Foundations, Development, Applications, New York: George Braziller、1976年改訂版: ISBN-13: 978-0807604533
[4] Bertrand Russell、1918年。レクチャー: The Philosophy of Logical Atomism。Bertrand Russell、David Peers（編集）、1985年、The Philosophy of Logical Atomism、Open Court Classics、ISBN-13: 978-0875484433、Amazon Online Reader（電子書籍ビューワー）でも閲覧可能
[5] Edward Yourdon、Larry L. Constantine、1979年、Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design、Prentice Hall、ISBN-13: 978-0138544713（1986年復刻版）
[6] Glenford Myers、1979年、Reliable Software Through Composite Design、Van Nostrand Reinhold、ISBN-13: 978-0442256203
[7] Erich Gamma、Richard Helm、Ralph Johnson、John Vlissides、別名Gang of Four（4人組）、1995年、Design Patterns: Elements of Reusable Object-Oriented Software、Addison-Wesley、ISBN-13: 978-0201633610
サービスの概念は、ビジネスおよび一般社会にとって重要です。つまり、境界のない情報の流れという、The Open Groupのビジョン、そしてBrewster Kahle氏のInternet Archiveによって構想されているような地球上のすべての人々が全人類の知識にアクセスできるようにするといったことへの第一歩を意味しています。どちらのビジョンも刺激的です!
原文はこちらです：http://www.infoq.com/articles/leeuwis-harvesting-soa
（このArticleは2008年11月22日に原文が掲載されました）