BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ アーティクル SOAガバナンスの役割

SOAガバナンスの役割

ブックマーク

ほとんどの大きな組織のITは数年から数十年の間隔で成長してきました。IMSやCICSを使ったメインフレーム上のアプリケーション、UNIXプラットフォーム上で動くコマンドラインアプリケーション、一部では成功して残っているクライアント/サーバ型や、4GLの試み、即ち、初期のオブジェクト指向の考えによって不運なユーザがさらされたUI、・・・。これら全ては、ダクトテープによって一緒に保持されています。言い換えれば、多数の異なる統合技術であるということです。それは、ファイルベースのインターフェースからデータベースのレプリケーションであり、APIアクセスからスクリーンスクラップ、RPCやCORBA、そして少なくとも2つのEAIプラットフォームが良い手段として導入されました。さらに言い換えれば、それを全体として見ると、ほとんどの大企業のITはひどい状態にあります。

エンタープライズアーキテクチャという分野があります。それは、論理的に問題を解決し、モデリングや保守を大局的に行います。つまり、アプリケーション一式を管理、その関連を文書化、継続的な改善計画、段階的なアプリケーション構成の最新化といったことを行います。しかし、私の経験では、このアプローチは時間のほとんどを記述的なもの(ドキュメントなど)に費やし、そもそも変化に対して一貫性のある考え方のアーキテクチャを実行することを意図していません。これがSOAが登場する理由なのです。

SOAは、ITニーズではなくビジネスの要求に照らして設計された機能的な領域の間に、はっきりとした境界線を引くことを保証します(これに関する素晴らしいアプローチに関しては、InfoQのSteve Jones’s book (source)を参照してください)。サービスは、管理、導入、開発における主要な概念上の要素となり、それに対して予算や所有者が割り当てられます。サービスはアウトソーシング、リプレイス、最新化の候補となります。次第に、会社のITは統合に依存したアプリケーション指向のアーキテクチャから、自律したサービス間の相互運用性を作るためのサービスアーキテクチャへと変わっていきます。

SOAの成功を確かなものとするために、多くのベンダ、アナリスト、コンサルタント、そしてSOAを実践する人たちは皆、SOAのイニシアチブを成功させるために、ガバナンスが重要な要素であると口をそろえて言っています。これは、会社のSOAへの移行の間だけガバナンスが必要であるかのように聞こえます。少なくとも、私が知っているほとんどの組織においては、この移行自体はおそらく10年かかるでしょう。企業の資産の大部分が既にサービス指向になっているなら、SOAガバナンスを継続的に実践するものとしてみるということは、今なお意味のあることです。

この記事では、成功するSOAガバナンスのための役割のセットの将来性について説明します。具体的には、「SOA ドメインアーキテクト」、「SOAプラットホームアーキテクト」、「サービスデザイナー」、「ビジネスサービスオーナー」、および「テクニカルサービスオーナー」の役割についてです。これらの名称を採用するか、現在のアプローチに沿ってより専門的な用語を選択するかはあまり重要なことではありませんが、私は、SOAが保証するものを享受できるようにするためにも、これらの役割に記述されたタスクが、ともかく公式に割り当てられる必要があると思っています。

以下では、それぞれの役割についてより詳細に見ていくことにしましょう。

サービスデザイナー

サービスを設計するにはテクニカルスキルとビジネススキルの両方を必要とする職務です。サービスデザイナーの技術プロファイルは、より技術的なビジネスアナリスト、若しくは技術的な専門知識よりドメインの知識をもっているハイレベルな開発者のそれと比較することができます。サービスデザイナーのタスクは、「良い」サービスを見つけ出すことです。それはつまり、サービスデザイナーが特定の問題に対する適合性と、異なる若しくはより一般的なシナリオにある再利用の可能性の間の適切な均衡点を見つけなければならないということです。

「良い」サービスの設計を可能にするために、(もしあなたがSOAの「伝統的な」スタイルを採用するなら)グループのオペレーションをインターフェースにする方法を決める必要があります。単一のサービスが多くの協調の中で表現されたものなのか、若しくは独立したサービスなのかを決めるということです。また、オペレーションやサービスの命名方法、サービスの粒度はどうすべきか、既存のサービスに依存すべきかどうか、エラーケースのハンドリング方法といった、サービス全体像だけでなく身近にある特定のサービスの品質への影響といったより多くの側面も決めなければなりません。

私は、賛否両論のある発言をしたいと思います。XMLは、組織のサービスコンシューマとサービスプロバイダの間のドキュメント交換を基本としているため、XML及びそれに関連する技術、特にXMLスキーマ(XSD)、名前空間、一般的なXML設計の原則に関する扱いが非常に優れているとまではいかないまでも、サービスデザイナーがそれらをきちんと扱えるのは必須となります。多くの場合、サービスデザイナーは何らかのサポートツールを利用するでしょう。しかし、ツールがどんなに良くても、ツールに隠蔽されている技術を理解することは重要です。

サービスは、それらが自律的であることが目的であるとしても、固有に設計されることはありません。インプットとアウトプットのドキュメントに関しては特にそうで、既に設計されたXMLスキーマの一部を一般的には利用します。サービスは既存のサービスを再利用することもできます(かつ、そうすべきです)。したがって、サービスデザイナーはこの情報を含んだインフォメーションストアへのアクセスができなければなりません。実際、より一般的に言えば、サービスデザイナーの役割にとってはこの情報ストアが共有サーバのディレクトリであるか、単純なデータベースアクセスなのか、あるいは商用もしくは自作でフル装備のレジストリ/リポジトリソリューションであるかということは全く重要ではありません。

ガバナンスを始めるために必要なことは何でしょうか?サービスデザイナーは作業のルールとガイドラインに従います。例えば、サービス設計さえ始まる前に、あるいは、サービスアーティファクトがサービスライフサイクルのある段階から次まで移行するとき、ガバナンスに必要な特定のルールがあるのかもしれません。適切なサービスの粒度やサービスの(グループ、ドメイン、などへの)クラスタリングのためのルールがあるかもしれません。企業のSOAポリシーによるガバナンスを実践するというサービスデザイナーの日々の作業の中には、その他のも多くのことがあります。従って、おそらくサービスデザイナーが企業ガバナンスのフレームワークの最初のユーザーでありコンシューマであると言ってもよいでしょう。

SOAドメインアーキテクト

大抵の組織には、個別のビジネスユニットか会社全体をサポートする任務の包括的なサービスデザイナーグループがいると思います。従って、一人のサービスデザイナーで会社のサービスすべてをデザインできると思い込むのは非現実的なことです。SOAドメインアーキテクトは、首尾一貫とした、高品質で全社的なSOAになるように作られたものになっていることを保証することに責任を持っています。いろいろな意味で、SOAドメインアーキテクトがサービスデザイナーをリードする存在となります。実際、サービスデザイナーの一人に割り当てられた追加作業が順調に開始するかもしれませんが、もしそうでならなかった場合には、ドメインアーキテクトが少なくともサービスデザイナーの作業を行える力を持っていることが重要になります。SOAドメインアーキテクトは少なくともサービスデザイナーとしての仕事ができる能力が必要です。サービスデザイナーのひとりをSOAドメインアーキテクトに割り当てることは良い出発点になるかもしれません(非常に優れたアーキテクトがプログラマーの作業をするのと同じです。)

SOAドメインアーキテクトの責務は、もし新たなサービスを追加に、サービスの追加に際し、変更すべきか、置き換えるべきか、増補すべきかどうかの判断でサービスデザインに関する対立がおきたとき、最終決定者という役割を担っています。SOAドメインアーキテクトはサービス間の依存関係について設計する権限をリードする役割を努め、全てのコンシューマ/プロバイダの関係が設計書の中で正しいだけでなく、企業全体のサービスモデルとしてあっていることを保証する必要があります。

ビジネスサイドは、(該当する場合は、エンタープライズアーキテクチャグループも)SOAドメインアーキテクトの仕事は最終的にSOAのビジネス的価値を見出すことです。(技術的な価値とは対象的です。それに関しては以降を参照して下さい)

SOAプラットフォームアーキテクト

ここInfoQやその他の所で、SOAのための「正しい」技術に関する多くの議論が行われます。しかし、どんな技術を選択をするとしても、技術の選択に一貫性があればSOAの潜在能力を引き出すことができます。言い換えれば、Web サービスをベースとしたSOAだろうが、RESTベースだろうが、CORBAだろうが、或いは、JavaとJMS、C#とMQであろうが問題はありません。実際のところ、どんな組み合わせでも良いのです。しかし、どのような技術を選択したとしても、今挙げた(若しくは幅広い)リストから一つを選ぶか、少ない数の組み合わせで選択するよう制限する必要があります。

SOAプラットフォームアーキテクトの最初の仕事はSOAの基盤とする技術を選択することです。一度標準として技術を選択したら(以降の議論のために、WS-Addressing、WS-ReliableMessaging、UDDI v3との組み合わせたWS-I Basic Profile 1.2準拠のWEBサービスと仮定)、SOAプラットフォームアーキテクトは継続的に技術リストをメンテナンスする責任があります。例えば、採用する価値のある新たな標準があるかもしれませんし、RESTなHTTPなどの代替技術が導入されるかもしれません。製品は、全体的なSOAアーキテクチャのための基礎として形成すべきではなく、それを実装するものとして利用すべきものです。そして、それを評価する必要があり、場合によっては導入されます。会社全体のSOAはビジネスサービスから成り立つだけではなく、認可、変換、ユーザプロビジョニングといった技術的なサービスからも形成されています。技術的なサービスがあるからこそ、SOAドメインアーキテクトと同じようにSOAプラットフォームアーキテクトの役割があるのです。(つまり、そのドメインはプラットフォームなのです)

ビジネスサービスオーナー

SOA全体がビジネスとIT間でよりいっそうの連携をするならば、サービスが技術的な(IT)コンセプトだけではなく、企業が認識しているビジネスの側面も重要となります。これを確実にするために、オーナーを持つべきそれぞれのサービスが、ビジネス的観点からのサービスとしての責任を果たす必要があります。それは、ビジネスサービスオーナーの仕事であり、サービスの存在意義やステークホルダーのための継続的なサービス運用について妥当であるかを判断することです。そして、この役割を実行しようとする誰かを見つけることができなければ、サービスそのものが疑問視されます。(しかし、下記に例外を記します)

ビジネスサービスオーナーはサービスが何の機能を提供するかを決めます。それがどんな実装方法でもかまいません。ビジネスサービスオーナーは、ビジネスサイドにおけるサービスデザイナーの「プロキシ」です。ビジネスサービスオーナーはアウトソーシングを選択するときにも重要な役割を果たすべきです。すなわち、最も有効な実現方法が彼自身の一番の関心事にあるので、彼の関心と動機はきちんと調整されるべきなのです。

テクニカルサービスオーナー

さらに技術的な役割を実行するサービスがあることは明らかです。例えば、ユーザ認証を提供するサービスは重要です。しかし、直接会社のビジネス機能に関連していません。このようなサービスのために、先に述べたビジネスサービスオーナーと同様の役割がテクニカルサービスオーナーにもあります。それは、より技術的な関心事にフォーカスします。

他方で、ビジネスサービスはテクニカルオーナーも必要でします。つまり、サービスの実現方法、技術的方針、バージョン管理など技術的側面に責任をもつ必要があります。これはテクニカルサービスオーナーの役割のもう一つの側面です。

結論

この記事で簡単に紹介した役割のコンセプトは、単なるSOAの出発点であるにすぎないかもしれません。しかし、私たちの経験から言えば、タスクにおける素晴らしいチェックリストとなり、組織に存在している役割にマッピングすることができる潜在的な役割であります。そして、新たな人を紹介する機会であることを示しています。これ以外の新しい役割を導入する必要がどこにあるでしょうか。うまくいけば、それはあなたにとっても役に立つことでしょう。そして、私はあなたがSOAイニシアティブとして定義することをより深く学ぶことに関して、大変興味をもっています。

Stefan Tilkov氏(source)はInfoQの編集者の一人で、(同じように名をつけられたが、独立した)innoQ(サイト・英語)における共同開発者であり、第一線のコンサルタントです。ドイツとスイスにコンサルタント業のオフィスがあります。

原文はこちらです:http://www.infoq.com/articles/tilkov-soa-roles
(このArticleは2007年7月18日にリリースされました)

この記事に星をつける

おすすめ度
スタイル

BT