はじめに

組織はそれぞれ異なるものです。独自の文化や構造、スキルのプール、そして資産を持っています。しかし、どの組織も、似たような問題に直面しています。つまり、

• いかに顧客サービスを改善するか、そして、変化する要求にいかに対応するか
• いかにコスト効率を高めるか
• 顧客やパートナー、競合他社、サプライヤーなどと、いかに協力して行くか

こうした問題を解決するためには、組織には変化が要求されます。そして組織の変化に合わせて、組織を支えるITシステムも変化しなければなりません。

ITシステムでの変化を管理するためのSOA利用の価値については、様々な記事が書かれてきました。SOAでのITアプリケーションは、そのアプリケーションがサポートするビジネス機能を表現するための、よく定義されたインターフェースを持っている必要があります。こうしたインターフェース、つまりサービスはIT機能のカタログを提供し、必要に応じて呼び出されます。この呼び出しは、アプリケーション間で直接行われる場合もあれば、ワークフロー・アプリケーションを介して行われる場合もあり、ESB（Enterprise Service Bus）を介して動的にルーティングされる場合もあります。サービス指向による方法が適切に行われれば、組織はITシステムを、組織の要求に密接にマップされた柔軟な方法で構成、接続することができます。

この記事では、組織がどのようにSOAを採用すべきかを解説します。組織はそれぞれ非常に異なることを考慮して、ここではユーザー・ロール（role）という観点からSOA採用のプロセスを説明します。これらのロールは、組織における典型的な地位を表しています。ユーザー・ロールは、必ずしも個々の人と同一視すべきものではありません。ある1人の人、あるいは1つのチームが、そのユーザー・ロールを実行することもあり、1人の人が、1つ以上のロールを実行することもあります。

ユーザー・ロールを使用すると、組織における責任の分担割合や、コミュニケーションや判断が要求される部分、関係するスキルのタイプなどを表現することができます。組織はこうした情報を基に、その組織の具体的な作業負荷に応じて、こうしたロールを満足するための人の展開を計画することができます。

この記事では、ある組織が新しいITソリューションとしてSOAを使用することに決めた、という単純なシナリオを、順を追って説明します。そしてユーザー・ロールを使いながら、組織がサービス指向ソリューションをいかに構築し、実行するかを説明します。この説明は、次のような話題に分割して行います。

• 単純な統合シナリオでは、このソリューション・シナリオについて説明します。
• ユーザー・ロールの実際では、このソリューションの構築方法と管理方法を説明します。
• まとめと結論では、サービス指向による方法を簡単に要約します。

上に戻る

単純な統合シナリオ

図1は、この記事で使用するシナリオを示しています。このシナリオは非常に単純ですが、SOAの持つ特徴の多くを表現しています。

この組織では歴史的な理由から、顧客データの半分を1つのITシステムに保存し、残りの半分を別のITシステムに保存しています。この2つのシステムのオペレーションは独立しています。計画としては、顧客データに対して単一のサービスを構築することです。このサービスがアプリケーションに呼ばれると、サービスは、リクエストを適当なバックエンド・システムにルーティングします。

顧客データは、時間と共に位置が変更され、あるいは他のシステムによって強化されます。従って、ソリューションは柔軟なものでなければなりません。各バックエンド・システムは、自分が持っているデータを抽出するサービスを提供しています。ESBで実行しているメディエーション（mediation）は、共通サービスから適切なバックエンド用サービスへのルーティングをサポートしています。

次のセクションでは、このソリューションの設計、開発、実行のために、ユーザー・ロール同士がどのように相互動作するかを説明します。

上に戻る

ユーザー・ロールの実際

統合されたサービス・インターフェースを作成するためには、まず適切な方法を選択し、次にそのソリューションを開発、デプロイし、そしてそのソリューションを実行します。この調整は、サービス指向ガバナンス（governance）によって行われます。これらのフェーズは、SOAのライフサイクル、つまりモデル化(Model)、組み立て(Assemble)、実行(Run)と管理(Manage)に対応しています。

下記の幾つかのセクションでは、どのロールが各フェーズに関係するのか、そのロールが何を行うのかについて説明します。

方法を選択する

新しいソリューションに対する要求は、どこからともなく現れるわけではありません。こうした要求を識別し、優先度を定め、プロジェクトの中にグループ分けするロールが、エンタープライズ・アーキテクトやビジネス・アナリスト、システム・アナリストです。

エンタープライズ・アーキテクト

エンタープライズ・アーキテクトは組織の技術戦略に責任を持ち、SOAビジョン（つまり、『戦略的に考え、戦術的に行動する』）を示す人でもあります。エンタープライズ・アーキテクトは、目標とする構成に移行するための手段として、既存システムを壊して置き換えるような巨大なプロジェクトを持ち込むよりも、小さな改善を継続的にロールアウトする方を好みます。

ビジネス・アナリスト

ビジネス・アナリストは、ビジネスのパフォーマンスを改善するための方法を探します。この中には、組織人員の協力方法に関する変更や、彼らが使用するツールや手順の変更、彼らをサポートするITシステムなどの変更が含まれます。このシナリオでは、ビジネス・アナリストは、顧客に対する新しいサービスを提供できる機会を見つけました。これを実現するためにはITシステムに変更が必要なため、ビジネス・アナリストはシステム・アナリストと協力し、この新しいサービスをサポートすることの現実性を調べます。

システム・アナリスト

システム・アナリストは、ビジネス要求を、ITシステムに対する要求に変換します。

システム・アナリストはビジネス・アナリストと話し合った結果、この新サービスを実現するためには、顧客データにアクセスするために一貫した方法が必要であることに気が付きました。現在は、このデータは2つのシステムの中にあり、それぞれのシステムは、別々のインターフェースとデータ・フォーマットを持っています。既存システムに与える影響を考えると、新しい顧客データ・リポジトリーを作成することは高価な選択肢です。そこでシステム・アナリストはエンタープライズ・アーキテクトと議論し合った後、顧客データに対する共通サービス・インターフェースを提案します。この共通インターフェースの背後では、リクエストは既存システムにルーティングされます。

この、「共通顧客データ・サービス」を利用すれば、呼び出し側アプリケーションと実装の詳細とを分離することができます。そのため将来も、新しい顧客サービス・アプリケーションを変更することなく、2つの顧客データ・システムを柔軟に融合させることができます。

システム・アナリストが作成する、新しいサービスのITソリューション仕様には、組織が新しいITソリューションに投資すべきかのビジネス判断を行う上での充分な詳細が含まれています。もし肯定的な判断が下された場合には、ソリューションを開発するためのプロジェクト・チームが結成されます。

ソリューションを開発する

ITソリューションには、様々な組み合わせのハードウェアやソフトウェア、アプリケーションとコンフィギュレーションなどが要求されます。この記事では、ソリューションのソフトウェア面に焦点を当てます。

ソフトウェア・アーキテクト

ソフトウェア・アーキテクトは、要求される機能を、ソフトウェア・ソリューションを構成するコンポーネント間に分割することに責任を持ちます。ソフトウェア・アーキテクトは既存のITシステムで使用されている仕様や標準を調べ、どこに機能改善が必要か、あるいはどの部分に対して新しいコンポーネントを書くべきかを判定します。

ソフトウェア・アーキテクトはエンタープライズ・アーキテクトからの指導を受け、プロジェクトのアーキテクチャーがIT戦略全体の方向性と一致することを確認します。ソリューションに対する要求はシステム・アナリストが出します。

このシナリオでは、「共通顧客データ・サービス」があることによって、新しいソリューションは次のような2つに分かれます。

1. 顧客からの「共通顧客データ・サービス」呼び出しに新しい機能を提供する、アプリケーション・コード
2. 「共通顧客データ・サービス」リクエストを適切なバックエンド・システムにルーティングする、ロジック

ソフトウェア・アーキテクトは、新しいアプリケーション・コードの実装にJ2EE（Java 2 Platform, Enterprise Edition）アプリケーションを使うことを選択します。ソフトウェア・アーキテクトは「共通顧客データ・サービス」の背後で、（2つのバックエンド・システムの呼び出し方を明確に定義するために）各バックエンド・システムに対するサービス・インターフェースを定義します。またESBメディエーションが2つのレベルのサービス・インターフェース間にリクエストをマッピングし、応答が行われるように規定します。

開発者

開発者はソリューションの一部分のみを設計、実装する人であり、ある特定な開発プラットフォームやプログラミング言語、ビジネス領域などに特化したスキルを持っている場合が多いものです。通常、サービス指向ソリューションの構築には、下記のようなタイプの開発者が関係します。

• アプリケーション開発者: アプリケーション開発者は、ソリューションに関するビジネス領域を理解しており、ビジネス関連の機能を実行するアプリケーション・コード（この場合は共通顧客データ・サービスを呼ぶ新しいJ2EEアプリケーション）を実装します。アプリケーション開発者は、自分のアプリケーション開発環境（J2EEなど）や、こうした環境の内部からサービスを呼ぶための方法などを理解している必要があります。彼らは、ソフトウェア・アーキテクト、あるいは別のアプリケーション開発者が提供するサービス・インターフェースの仕様を基に作業を行います。
• コンポーネント開発者: コンポーネント開発者は、単独に閉じたコードの塊（『コンポーネント』と呼ばれます）をコード化します。こうしたコンポーネントは、複数のアプリケーションで使われるように設計されています。このシナリオでは、コンポーネント開発者は「共通顧客データ・サービス」用のメディエーションをコード化します。
• インテグレーション開発者: インテグレーション開発者は、コンポーネントをコンフィギュレーションし、リンクさせることによって、サービスを構築することに責任を持ちます。こうしたコンポーネントは、コンポーネント開発者が書くか、あるいはESB製品の一部として提供されます。一般的に言ってインテグレーション開発者は、統合のための手法やパターンはよく理解していますが、プログラミング・スキルは限定されています。統合シナリオが複雑なプログラミング・ロジックを要求する場合には、インテグレーション開発者はコンポーネント開発者と協力しながら、統合用の新しいコンポーネントを作成します。

テスト・エンジニア

SOAベースのソリューションでは、様々なレベルでテストが発生します。各ソリューション・コンポーネントは、それぞれの正しい振る舞いを保証するために、独立してテストしておく必要があります。次に焦点は、これらのコンポーネントが正しく統合できるかのテストに移ります。大がかりな、あるいは複雑なソリューションを円滑に実稼働に移行するためには、特にテストに注意する必要があります。

• テスト・アーキテクト: テスト・アーキテクトは、ソリューションのテスト方法を規定し、またソリューションの一部を独立してテストするために必要な追加コードを特定します。テスト・アーキテクトは、テスト・コードを挿入するための場所として、サービス・インターフェースを利用します。このテスト・コードで下記をチェックします。
  • サービス・インターフェースを呼ぶコンポーネントが、全タイプのデータに応答できるかどうか
  • サービス・インターフェースを実装するコンポーネントが、全タイプのリクエストを処理できるかどうか

このシナリオでは、テスト・アーキテクトは、「共通顧客データ・サービス」を利用して、新しいJ2EEアプリケーションをテストするために必要なランタイム環境を単純化します。顧客データのテスト管理にJ2EEベースの「共通顧客データ・サービス」実装を規定することによって、新しいアプリケーションを、完全にJ2EEテスト環境の中で機能テストすることができます。これによって、これに対する開発サイクル（新しいコードの最大部分）を短縮することができます。

• テスト・インプリメンター: テスト・インプリメンターは追加テスト・コードを書き、ソリューションを検証するためのテストを実行し、適当な開発者にエラーを報告し、また修正に関するテストを行います。テスト・インプリメンターはプロジェクトの複数ステージに関係します。まず個々のコンポーネントの機能的な正しさをチェックし、次にコンポーネント群の統合テストを実行し、そしてデプロイ期間中には、ソリューションが実稼働に耐えうるかどうかをテストします。例えば、そのソリューションが、起動し、停止し、バックアップされ、システム・フェールから回復し、維持管理できるかどうか、などをテストするのです。

ソリューションをデプロイする

開発という観点から見てソリューションが完成し、動作するようになったら、組織はそのソリューションを採用しサポートするために、変化しなければなりません。そのためには、ビジネス・レベルとITレベルの両面から、準備と計画が必要です。

ビジネス・オペレーション・マネージャー

ビジネス・オペレーション・マネージャーは、組織が新しいソリューションを利用する上での自分たちの役割を設定することを含めて、新しいサービスを採用しようとするビジネスのすべて、あるいは一部を管理します。通常、サービス指向プロジェクトはビジネスの一部分同士をつなぎ合わせるものであるため、ビジネス・オペレーション・マネージャーは他のビジネス・オペレーション・マネージャーと協力しながら、自分たち手続きが補完し合うようにします。このプロジェクトでのビジネス・オペレーション・マネージャーは、既存の顧客との間で結ばれているプライバシー合意に誤って違反しないように、顧客データの収集や使用に関して自分たちが同じポリシーを持っていることをチェックします。

レジリアンス（resilience）エンジニア

レジリアンス・エンジニアは、新しいソリューションが、必要な時にはいつでも使用可能となっていることに責任を持ちます。この中には、可用性の保証が含まれます。例えばビジネス要求の変化に対応するピーク負荷時の可用性保証や、フェール（部分的なものであれ、大きなものであれ、あるいは完全なフェールであれ）の後の可用性保証などが含まれます。

サービス指向環境でのソリューションは、エンド・ツー・エンドでの弾力性（resilience）を持っている必要があります。例えば、新しいサービスが「共通顧客データ・サービス」を呼び出すことによって増大する負荷を、バックエンド・システムが処理できるように保証する必要があります。また、こうした既存システムは、新しいサービスが必要とする時には必ず使用可能でなければなりません。従ってレジリアンス・エンジニアは、既存システムの能力を増加し、それに合わせてオペレーション手順も変更する必要があるかも知れません。

ITアドミニストレーター

ITアドミニストレーターは、ソフトウェア・ソリューションをサポートするITインフラをコンフィギュレーションします。このシナリオでのITアドミニストレーターは、新しいJ2EEアプリケーションをサポートするために、IBM WebSphere® Application Serverクラスターをコンフィギュレーションします。彼らは、このアプリケーションに対してIBM DB2®データベース・サーバーを設定し、また「共通顧客データ・サービス」のインターフェースとメディエーションをサポートするためのSI（Service Integration）バスを設定します。そして最後に、既存バックエンド・システムの一方への接続を行うアダプターに対して、サーバー環境をコンフィギュレーションします。これによって、リリース・デプロイヤーがソリューション・コンポーネントを追加するためのプラットフォームが提供されます。

リリース・デプロイヤー

リリース・デプロイヤーは、ソリューション用のコンポーネントを実稼働環境でコンフィギュレーションします。この中には、ソリューション・コンポーネントのインストールや、オペレーションに必要なリソース（データベース・テーブルやキューなど）に合わせてのコンフィギュレーションなどが含まれます。状況によると、リリース・デプロイヤーには、既存システムの中で定義されている追加リソース（ユーザーIDなど）が必要となる場合があります。それらがシステム用に定義できるよう、リリース・デプロイヤーはITアドミニストレーターと協力し合いながら作業を行います。

すべてのソリューションの展開が終わると、テスト・インプリメンターが、すべて正しく動作していることを確認します。これでソリューションの実稼働準備が整いました。

ソリューションを実稼働として実行する

ほとんどのIT部門では、部門スタッフに対して、ある特定な技術やアプリケーションに精通するように推奨するものです。しかしサービス指向ソリューションは、様々な技術を統合しています。

実稼働での成功は、エンド・ツー・エンドでのソリューションの可用性によって判断されます。従って、オペレーション上の手続きも、そうした点から適切に考慮する必要があります。サービス指向ソリューションでは、技術ベースのスキルを持った人同士が協力することが要求され、また様々な技術にまたがる知識を持った人が尊重されます。さらに、ビジネスとの連係が、より一層重要になります。これを示すものとして、次のような3つのロールがあります。

サービス・レベル・マネージャー

サービス・レベル・マネージャーは、ビジネス・オペレーション・マネージャーと協力しながら、新しいソリューションのサービス・レベルに同意します。サービス・レベル・マネージャーの知識は、「共通顧客データ・サービス」をサポートする既存システムを含めて、ソリューションで使用される技術全般を網羅している必要があります。

ITオペレーター

ITオペレーターはシステムを監視し、ハウスキーピング・オペレーション（バックアップなど）を行います。「共通顧客データ・サービス」が展開された後は、システム・フェールが起きた後に顧客データが一貫性を持って回復できるように、既存システムそれぞれの中にある顧客データベースのバックアップは同期している必要があります。

インシデント・アナリスト

インシデント・アナリストは、ITシステムから発生する、予期せぬエラーや警告を調査します。例えば顧客データの更新失敗が起きたとすると、インシデント・アナリストは、J2EEサーバーや既存のバックエンド・システムに対する診断結果をチェックする必要があるかも知れません。

サービス指向ガバナンス

最後に、（既存のオペレーションを妨害することなく）可能な限りIT資産の再利用を図るためのコントロールが必要です。これに関してはエンタープライズ・アーキテクトが全体的な責任を持ち、作業の一部は、その作業に特化したロールに権限委譲されます。

チェンジ・コントロール・マネージャー

チェンジ・コントロール・マネージャーは、実稼働システムに対する、あらゆる変更への承認に責任を持ちます。この中には、何らかのサービスについての新しい使い方も含まれます。（たとえ実装への変更は要求されなくても、そうした使い方がサービスに対する負荷に影響するため）。

チェンジ・コントロール・マネージャーは、IT部門内の他のエキスパートと協力しながら、変更が成功しているかどうかを検証します。例えばチェンジ・コントロール・マネージャーは、レジリエンス・マネージャーと協力しながら、新しいソリューションが既存のバックエンド・システムに影響していないことをチェックします。またチェンジ・コントロール・マネージャーは、ITオペレーターが新しいソリューションを監視できること、ソリューションに必要なハウスキーピング手続きが展開されていることを確認します。

アセット・マネージャー

アセット・マネージャーは、再利用可能なIT資産を維持管理することに責任を持ちます。この中には、IT資産の開発や維持管理、適切なプロジェクトがIT資産を利用できるようにすること、などが含まれます。

「共通顧客データ・サービス」によるIT資産に含まれるものには、サービス・インターフェース定義や、このインターフェースに使われるデータ型定義、メディエーション・コンポーネントなどがあります。アセット・マネージャーは、こうした資産が、（ドキュメンテーションを含めて）適切な標準に従って開発され、そしてアセット・リポジトリーに保存されることを確認します。

今後のプロジェクトでは、アセット・マネージャーはプロジェクト設計をリビューし、再利用の機会が見逃されていないことを確認します。

上に戻る

まとめと結論

サービス指向の方法によって、組織は既存のIT資産を統合し、再利用することができます。これによって組織人員の協力形態が変化し、組織全体に渡って、より一貫した方法が推奨されるようになります。この記事では、ユーザー・ロールの記述を通して、組織内でITシステムをサポートし、使用する上で必要となる、様々なスキルや責任の特徴を明らかにしました。そして、こうしたロール同士が、サービス指向環境の中でどのように協力し合うかについて説明しました。

謝辞

ワークグループ（IBM SWG Architecture Board workgroup on SWG User Roles（現在はCommon Customer Roles））のメンバーに対して深く感謝します。SOAにおける一連のユーザー・ロールを記述するための基本は、彼らの素晴らしい協力なしには得られませんでした。また、こうしたユーザー・ロールに関する作業を精力的に継続しているMarcia Stocktonにも感謝致します。

参考文献

学ぶために

• developerWorks の SOA and web services ゾーンを利用して、皆さんのSOAスキルを向上させてください。
  
  
• developerWorks Architecture zoneを利用して、アーキテクチャー関係の問題を学んでください。
  
  
• IBMの最先端技術エキスパートによるdeveloperWorks podcastsを利用して、最新技術を学んでください。
  
  

製品や技術を入手するために

• WebSphere Application Serverの無料試用版をダウンロードしてください。
  
  
• IBM Rational Application Developer for WebSphere Softwareの無料試用版をダウンロードしてください。
  
  
• IBM Rational Software Architectの無料試用版をダウンロードしてください。
  
  
• 設計や開発のあらゆる側面を統合するために考えられた、様々な資料の集成である、IBM Software Architect Kitを入手してください。
  
  

議論するために

• ディスカッション・フォーラムに参加してください。
  
  
• developerWorks ブログに参加して、developerWorksに加わってください。
  
  

著者について

Mandy Chessellは、イギリスのSenior Technical Staff Memberです。ミドルウェアの分野で18年間の経験があり、イギリスのUniversity of Brightonにてソフトウェア・エンジニアリングの修士を取得しています。専門領域は、分散トランザクション処理やオブジェクト指向設計、使いやすさ（usability）、UMLモデリングなどです。

Birgit Schmidt-WescheはSenior Usability Engineerです。1985年にIBMのScientific Center in Heidelbergに入社し、自然言語処理プロジェクトに加わりました。ドイツのUniversity of Duesseldorfにて言語学の博士を取得しています。過去12年間は、ドイツのBoeblingenとイギリスのHursleyにあるIBM開発研究所、そしてアメリカのIBM Watson Researchにおいて、数多くのユーザー体験チームを指導してきました。2002からは、顧客ユーザー・ロールの標準化を中心とした業務を行っています。現在はイギリスに勤務しています。

この記事を評価する

コメント

上に戻る

目次

• はじめに
• 単純な統合シナリオ
• ユーザー・ロールの実際
• まとめと結論
• 参考文献
• 著者について
• コメント