レベル: 中級 Jeremy Caine (jeremy_caine@uk.ibm.com), Senior IT Architect, IBM
Joe Hardman (joe_hardman@uk.ibm.com), Senior IT Architect, IBM
2007年 4月 19日 サービス指向アーキテクチャー (SOA) は多くのビジネス変換作業の中核となっていますが、貴重なレガシー IT システムをサービス・プロバイダーとして加えるために、多くの企業では、段階的に SOA 変換を行うという方法を採用しています。その場合、ソリューション・アーキテクトの課題となるのは、変換を支援する手段として SOA インフラストラクチャーを提供するだけでなく、企業全体でビジネス・オペレーションの堅牢性と適合性が保たれるようにすることです。また企業側では、SOA の一部となりうるエンタープライズ情報管理戦略を開発し、すべてのビジネス・オペレーションでデータとコンテンツ全体の整合性を維持できるようにしなければなりません。この記事では、そのような変換の課題を説明し、検討すべき設計戦略のいくつかを取り上げます。
はじめに
ほとんどのビジネスでは、ビジネス戦略とコア・コンピテンシー分析によって、ビジネスの再設計と IT 近代化で重点を置くべき箇所が特定されています。それは一般的には (少なくとも、企業の中核的要素の一部については)、サービス指向ビジネスへの変換とその変換における SOA への依存の部分になります。ビジネス・オペレーションの設計は、現行の IT システムをサービス・プロバイダーとして再設計して統合することを要求する、一連のサービスを中心に行われます。サービス指向ビジネスへの変換によって、新しいサービス・プロバイダーが導入されることも考えられます。その目標は、内部ワークプレース用のポータル・アプリケーションやインターネット・コマース・アプリケーションといった新しい複合アプリケーションを、特定ビジネスのニーズに合わせて効率的に作成できるようになることです。
このような手ごわい変換の一環として、企業は通常、多数の重要な事業計画や IT 計画に携わることになります。この変換によってもたらされる主要な成果としては、以下のものが挙げられます。
- ビジネス・サービス・モデルを中心としたエンタープライズ・アーキテクチャーの調整
- ビジネス・サービス・モデルの関連部分を実現可能な、サービス・ベースの IT インフラストラクチャーの導入
- レガシー IT システムの変換および拡張、あるいはレガシー IT システムへのラッパーの適用 (これにより、レガシー IT システムをこのサービス・ベースの IT インフラストラクチャーに統合することが可能になります)
- サポートする IT アプリケーションを効率的かつ柔軟に実装できるようにする堅牢な設計開発環境とデリバリー・プロセス
変換による上記の主要な成果から、さらに対処しなければならない二次的な一連の課題が派生して作成されます。これらの課題に対処することで、企業は確実にその変換の意図を実現し、変化を監視してその変化に柔軟に適応できるようになります。このような変換の課題は通常、以下の原則に従うことを目標としたものです。
- 企業が引き続き、一連の堅牢で適合性のあるビジネス・オペレーションを提供すること。
- 全体のビジネス・サービス・モデルと IT システムの実装が包括的な変換原則に従うことを確実にするためには、ガバナンス・プロセスおよび設計を扱う専門部門が必要であること。
- 企業はビジネスと IT サービス管理の総合的な見解を持ち、対策と迅速な変更を行えるようにすること。
一部の企業は幸運にも組織全体で SOA へのビジネス変換を行うことができます。この手法では変換の主要な成果を実現するのは困難ですが、それが達成されれば、変換の二次的な成果の拡張や開発を行いやすい環境になります。このようなシナリオになるのは一般的に、企業全体でビジネスと IT の変更を推進したいと考える C レベルの経営幹部が積極的に資金提供して戦略アジェンダを支援する場合です。
その一方、ほとんどのエンタープライズ変換は段階的に行われます。大規模で戦略的な変換であったとしても、やはり段階的であることには変わりありません。段階的な変換とは通常、レガシー IT システムを新しいビジネス・オペレーションのサポートに加われるように設計し直すことを意味します。例えば、レガシー IT システムを他の IT システムと組み合わせて、シームレスな顧客オーダー処理を促進するなどです。レガシー IT システムは、すべてではないにしても大部分の現行の機能を引き続き実行します。また、SOA 変換の適用範囲に含まれないビジネス・オペレーションはそのまま続行されます。
この変換シナリオでは、SOA の IT インフラストラクチャーに適した実装設計を慎重に検討することが不可欠となります。SOA に含まれる一連の IT システム内でのデータ処理と、SOA の範囲外でのデータ処理が互いに影響し合うからです。データ処理環境全体が、ビジネス・オペレーション全体で堅牢さと適合性を持つ必要があります。
図 1 の例には、サービス・プロバイダーとして設計された 3 つのレガシー・システムがあります。
図 1. 新たな SOA 全体像のなかでのレガシー IT
図 1 では、ビジネス変換プログラムによって SOA インフラストラクチャーが構築され、このインフラストラクチャーによってビジネス・サービスが公開され、そしてこのビジネス・サービスが新規アプリケーションに利用されるようになっています。SOAインフラストラクチャーには通常、ソフトウェア間の複数プロトコル接続、非同期および同期メッセージ・フロー管理、メッセージの変換、ルールの履行、プロセス・コレオグラフィーといったことを可能にするミドルウェアが含まれます。上記の図ではこれらのサービスを使用する複合アプリケーションが作成され、レガシー・システム自体も新規サービスの呼び出しを利用することによって拡張されています。
SOA におけるプロセス・アーキテクチャーと情報アーキテクチャー
SOA インフラストラクチャーを実装するために作成、維持、そして拡張される重要な資産は、ビジネス・サービス・モデルです。このモデルを開発するには、IBM® サービス指向モデリングとアーキテクチャー (「参考文献」を参照) といった汎用的な手法を使用します。一般的な企業におけるビジネス・サービス・モデルに含まれるのは、トップダウン分析とボトムアップ分析、そして目標サービス・モデリングの混合です。変換のビジネス目標は結果としてプロセス・アーキテクチャーと情報アーキテクチャーという形になり、このアーキテクチャーが新規ビジネス・オペレーションと IT アプリケーションのサポートの実装を推進するために使用されます。
-
プロセス・アーキテクチャーとはアクションの機能階層のことで、これらのアクションを組み合わせて、土台となるエンタープライズ・オペレーションである、一連のビジネス・プロセスを形作ることができます。プロセス・アーキテクチャーが関与するのは、システムに対する人間のフロー制御と、システムに対するシステムのフロー制御です。このアーキテクチャーには例えば、顧客が製品を注文できるようにするためのアクション、そしてその製品の配送を顧客が安心して待機できる状態にするために必要なアクションが含まれます。
-
情報アーキテクチャーとは、エンタープライズ・オペレーションに状態と意味を与えるためにアクセス、操作、そして保管される一連の関連データおよびコンテンツのことです。このアーキテクチャーは、コンテキストが単純なアクセス・イベントであろうと、プロセス・フローであろうと関係なく、データおよびコンテンツの情報管理を行います。その一例は、製品の開発ライフ・サイクル(コンセプトから製造までなど) の期間中に使用および生成されるデータとコンテンツです。
プロセス・アーキテクチャーと情報アーキテクチャーのビューポイントが併せて作られ、データ処理 (CRUD) マトリックスなどによって示されることもよくあります。この 2 つのアーキテクチャーがまとまって、サービス・アーキテクチャーを構成する数多くのサービスを定義します。サービスとは、メッセージ・データが渡されると呼び出される一連の操作のことです。サービス実装は、一般的に永続的ストレージやアクセスなどを使用してデータやコンテンツを操作する処理を実行し、結果を返します。サービスは同期でも非同期でも使用することが可能で、呼び出しは通常、統合インフラストラクチャーが仲介します。完全に分離されたシステムでは、一部のサービスがプロセス状態を変更し (例えば、情報が要求に応じて、顧客 X の新規アドレスが検証済みであることを示すなど)、他のサービスが情報の状態を変更します。これにより、データとコンテンツが操作されて望ましい状態になっていることを確実にし、その後のサービス・イベントがその状態に依存できるようにします (例えば、顧客 X の新しい配送先アドレスが有効であるなど)。
レガシーなデータ処理の課題
レガシー IT システムが企業のサービス・プロバイダー実装の一部となり、SOA インフラストラクチャーに統合されるようになることは間違いありませんが、レガシー・システムには従来のメインフレーム処理だけでなく、エンタープライズ・リソース・プランニング (ERP) アプリケーション、内部および外部 Web アプリケーション、ワークフロー・アプリケーション、スキャン・システムやプリント・システムなども含まれます。これらのレガシー・システムを使用したり、サービス・プロバイダー実装に組み込んだりすることを可能にすると、以下のようなさまざまな事態が発生する可能性があります。
- 処理関数を公開してアクセス可能にし、サービス・プロバイダー実装に組み込めるようにします。これはたいてい、CICS® トランザクションでの SOAP ラッパーなど、新規プロトコルと呼び出しメカニズムによってトランザクションを公開することを意味します。
- トランザクションを公開する際に処理の完全性を維持するため、関数を設計し直さなければならない場合があります。トランザクションは既存のものであることも、1 つまたは複数の別の既存のトランザクションを呼び出すために作成されたもの (ファサード) であることもあります。この項目とその上の項目の場合、サービスの粒度に関する戦略によって、公開されたサービスを起動する呼び出しの設計が左右されます。
- 特定の処理関数はオフに「切り替える」必要があります。データ処理は、サービス・プロバイダー実装によって呼び出される新しい関数が実行するようになるからです。
- 既存のアクセス権とセキュリティーおよび監査の要件が、新しいアクセス・メカニズムに対して施行されなければなりません。
- 既存のシステムに関するサービス品質 (QoS) 基準を拡張するか、あるいは補足しなければならない場合があります。例えば、オフライン・バッチ処理ウィンドウに代替処理ソリューションを適用するなどです。
- SOA が既存のシステムに予想外の新たな負荷をもたらし、それによって既存のプロセスに悪影響が及ぶ場合があります。
SOA への関与の一環としてレガシー IT システムが公開されても、変換の範囲外にあるビジネス・オペレーションをサポートする特定の関数はそのままデータ処理を続けます。そのため通常は、データの現行性と同期の問題を理解して対処する必要があります。
ユーザーはレガシー IT システムを起動する際に、ユーザー・インターフェース (例えば、メインフレームのダム端末やパッケージ化されたアプリケーションの UI ) など、元のアプリケーションの手段を引き続き使用します。SOA が依存するのは、SOA エコシステムを中心として送信されるメッセージを記述するために使用する一連のデータ・スキーマです。これらのデータ・スキーマが物理データ・メッセージとなり、連携する一連のサービス・オペレーションに統合されます。サービス・オペレーションには、ランタイム・データ変換やセマンティック・マッピング、あるいはメッセージ・データの増強などが含まれることがあります。このデータが、基礎となるレガシー IT システムによって使用され、処理されることになります。
SOA で実行可能な一連のプロセスが依存するデータとコンテンツの集合は特定の状態でなければなりませんが、SOA 関数とレガシー IT システムの並行処理によって、該当する状態モデルが不安定になる場合があります。
図 1 の例では、シームレスな処理機能で顧客の保険証券を設定して管理する、新しいインターネット・アプリケーションが、変換によって実現されました。この新規アプリケーションでは、保険証券が更新時期に近づくと、顧客に連絡して保険契約の更新を提案できますが、SOA の範囲外にある既存のビジネス・オペレーションによって問題が生じる可能性があります。顧客が会社に引っ越したことを通知する手段には何通りものルートがあるからです。つまり、最初に新規インターネット・アプリケーションで保険を購入したとしても、顧客が SOA アプリケーションを使って会社に住所変更を通知してくるとは限りません。例えば、代わりに手紙を送るという場合もあります。事務処理では、顧客の新しい住所はカスタマー・リレーションシップ・マネージメント (CRM) システムにしか適用されません。既存の CRM システムが顧客の新しいデータで保険契約管理システムを更新するのは、夜間のバッチ処理によってです。そこで、データを同期するタイミングが問題となります。新しい SOA ベースのシステムは、ほぼリアル・タイムのトランザクションを中心に設計されているからです。データが同期されるまで、新規アプリケーションは古い住所を使って顧客に契約更新の連絡をしようとしますが、本来は、即応性の高いコンテキスト対応の SOA アプリケーションが新しい住所でその顧客に連絡し、古い保険契約を取りやめて新しい保険に加入するかどうかを問い合わせなければなりません。
サービス・プロバイダーについて
理論的には、SOA アーキテクトの役割が関与するのはサービス対応インフラストラクチャーの設計と実装です。SOA のモデリング手法に従えば、プロセス・アーキテクチャーと情報アーキテクチャーが使用するサービスを決定し、サービス・プロバイダーと契約を結び、プロセス実行とデータ処理の一環としてサービス・オペレーションを起動するアプリケーションを作成できます。サービス・コンシューマーは、合意された一連の契約 (サービス操作および関連する QoS) に従ってデータが処理および管理されることが規定されている限り、サービス・プロバイダーがどうサービスを実装しようと関与しません。
このモデルは、特にサービス・プロバイダーの実行を企業の外部に委託している場合など、特定のシナリオでは上手く機能する可能性があります。この記事では、今日 SOA を採用する多くの企業が実施している具体的だが一般的なシナリオに焦点を絞ります。
段階的変換を行っている企業ではとくにそうですが、SOA 変換ではソリューション全体のアーキテクトに多くの責任が課せられるのが現実です。これらの責任は、エンタープライズ・ガバナンス・プロセス (詳細は、「A case for SOA governance」(developerWorks、2005年8月) を参照) の枠内で遂行されます。
ソリューション・アーキテクトがまず第一に関心を持つのは、SOA インフラストラクチャーの設計と実装です。これには、サービス・プロバイダー実装の構成要素となり、ソフトウェア・システムとして機能することになるレガシー IT システムの特定も含まれます。第二に、ソリューション・アーキテクトはサービスを使用するアプリケーションをアセンブルするための開発プロセスと環境を指定します。これに含まれるのは、設計パターンと標準、そしてツール環境です。ただし第三の点として、ソリューション・アーキテクトは全体的なビジネスおよび IT アーキテクチャーの役割に精通していなければなりません。ビジネス・アーキテクチャーによってビジネス戦略にふさわしい内容とそこから派生する機能と契約が規定され、IT アーキテクチャーによってビジネス・オペレーション全体をサポートするのに必要な IT システムが実現されるからです。かなり大規模な企業内では、今説明した事柄が適切な戦略的アプリケーションの大半を占めるポートフォリオとなります。
検討すべき設計戦略
企業全体での準拠を可能にする確固たる情報管理アーキテクチャーを構築するには、数々の設計戦略と原則を検討して問題に対処します。
ビジネス・プロセス分析での適用範囲変更の計画
変換プログラムの最中によくあるシナリオは、システムの分析と設計によって、望ましくないデータ処理シナリオが見つかるというものです。その場合、以前は適用範囲外だったビジネス・オペレーションを適用範囲に入れ、新しい一連のシステムに合わせて変更する必要が出てくることが考えられます。さらに、変更したビジネス・オペレーションが使用できるように、新しい SOA ベースのシステムが内部アプリケーション (顧客の詳細情報を更新するための追加処理ステップなど) を提供しなければならないことも考えられます。
レガシー・エンティティーの変更のパブリッシュとサブスクライブ
合意されたエンティティーと属性データがサービス・プロバイダーとして加わっているレガシー IT システムで変更された場合、SOA に通知するための追加処理を開発しなければなりません。この追加処理は、たいていは定期バッチ・アクティビティーという形をとるのではなく、リアル・タイムで行われるのが理想的です。古い構造化されていないアプリケーション・コードのレガシー IT システムにデータ・レコードが変更されたことを検出するインスツルメンテーション・コードを適用するのは、ほとんど不可能に近いというわけでなくても、コストがかかることになるのは明らかだからです。
企業が行うべきことは、レガシー・システムが所有するデータと、変更を関係者に通知するシステムの機能を評価することです。SOA にとって重要なデータがとても頻繁に変更され、しかもレガシー・システムがレコード単位のイベント・トリガーを生成できない場合 (つまり実行できるのは、せいぜい毎日のバッチ抽出くらいという場合)、レガシー・システムを再設計するか、あるいは置き換えるという決断に至る可能性があります。ここで確認しなければならないのは、ビジネス・サービスの QoS が予定される設計効果に見合ったものであることです。重要なサービス・データの日次バッチ処理がメッセージ駆動型のリアルタイム処理に移行するなど、計画された設計の段階的改善に従って、QoS がどれだけ改善されことになるかを示してください。
情報サービスのクエリー・ファサード
情報管理サービスの操作は、データやコンテンツに適用できる単純なアクションとなっていなければなりません。クエリーによるファサードは、情報がどれだけの数の物理 IT システムでどのようにアクセスされ、操作されるかを隠します。基本的に、クエリーによるファサードがデータ統合を実現するために実装できるのは、以下の 2 つのパターンです。企業内には多彩なシナリオとレガシー・システムがあるため、たいていの場合は、この 2 つのパターンを使用してサービスを実装することになります。
-
データをクエリーに移動。徐々に変更される情報を保留データ・ストア (ウェアハウスなど) に配置し、そこでデータを操作します。このデータ・ストアではETL (Extract, Transform, and Load) 技術を使用できます。
-
クエリーをデータに移動。迅速に変更されるトランザクション・データの場合、アクションが物理ソースにアクセスしてデータを操作する必要があります。このようなアクセス(読み取りおよび更新など) を行うには、コネクター技術とアダプター技術を使用できます
SOA 内で実際のクエリーによるファサードを実装するには、フェデレーションやデータ追加などのさまざまなパターン (詳細は、「参考文献」の Data Integration application patterns を参照)、そして Service Data Objects や Data Access Services などの技術 (「参考文献」を参照) を使用できます。何を使用するかは、各種サービス実装の全体的なデザイン・パターン(詳細は、「Toward a pattern language for Service-Oriented Architecture and Integration, Part 1」(developerWorks、2005年7月) を参照) によって左右されますが、この問題空間では、実装設計を拡張して一層インテリジェントなサービスを実現しなければなりません。レガシー・システムがエンティティー・データの変更をパブリッシュするためのソリューションが(同意された QoS のレベルで) 用意されているという前提の下、情報サービスはその変更(内容と頻度) に同意し、該当する基本の物理システム (データ同期を実行するシステムなど)に変更を適用する必要があります。
アーキテクチャー内ではここが、マスター・エンティティーを決定する場となります。つまり、どのレガシーIT システムをマスターと見なし、どのトランザクション・シナリオでそのように見なすのかを決定するのです。この場合に活躍するのはマスター・データ管理技術ですが、もちろんアーキテクチャーの定義で重要な部分を占めるのは、レガシー・システムの統合機能と釣り合ったオプションと決定です。
ここがマスター・データ管理技術が、実装する上で役に立つところですが、もちろんアーキテクチャーの定義で重要な部分を占めるのは、レガシー・システムの統合機能と釣り合ったオプションと決定です。
ビジネス・ルールの配置
SOA への変換によって、他のエンティティーに混ざって、統合ミドルウェアと新しい複合アプリケーションが含まれる新規 IT インフラストラクチャーが導入されます。ビジネス・ルールはもはや、単一のアプリケーションの枠には収まりません。状態の管理は、ビジネス・ルールを履行することによって効果的に行われます。そのため、情報管理設計を開発する一環としてビジネス・ルール・ロジックのタイプと場所を理解することは必須です。
SOA 内のビジネス・ルールには、以下のタイプがあります。
- 基準整合性ルール
- アプリケーション動作のルール
- アプリケーション間の統合ルール
- トランザクション処理のビジネス・ロジック・ルール
- データ・エンティティーの処理ルール (ストアード・プロシージャーなど)
戦略は、ビジネス・ルールを複製するのではなく再使用するものでなければなりません。SOA の導入では、既存のビジネス・ルールと新規ビジネス・ルールの履行を慎重に検討する必要があります (サービスの確実な実行をサポートするため)。ルールのロジック自体を (コンテキスト内のどこに位置していようが) サービスとして公開し、特定の処理シナリオの整合性を維持するために呼び出せるようにしなければならないという場合も考えられます。
考えられる設計戦略の影響
設計の決定段階に達したら、ソリューションへの考えられる影響として以下のことを検討してください。
-
二重の入力処理。SOA の導入によって特定のビジネス分野で得られる効率性は、追加のデータ入力タスク(そしてその結果として増加するデータ入力エラーのリスク) とのバランスをとらなければなりません。しかし、データ同期タイミングのシナリオに対処するには、二重の入力処理が唯一のオプションである場合もあります。このようなシナリオが軽視されることは通常ありません。企業は、夜間に行われるバッチ更新の遅れを防ぐため、イベント駆動型の二重入力を実行する作業員数を確保する必要があります。このコストは、データ同期を支援するシステムでの自動インターフェースの開発と対比します。この循環分析によって、自動インターフェースを実装(特にテスト) するのに必要な時間がデリバリー時間枠全体を危うくするかどうかを評価できるはずです。
-
不要なフィードバック・ループ。CRM システムの顧客レコード更新に続いて、手動で、または自動的に SOA が呼び出され、他のアプリケーションにこの対象外の顧客データ変更が通知されます。顧客を更新するためにSOA は固有の情報サービスを呼び出し、この情報サービス自体が元の CRM システムを呼び出して顧客データを更新します。情報サービス・アーキテクチャーは、使用モデルに応じて異なるスタイルの顧客更新を実装する必要があります。
-
適用範囲の変更。SOA の適用範囲の規定を定義するときに、レガシー IT システムに関する知識とそのプロセス内容と情報管理機能に関する知識がなければ、間違いなく適用範囲の変更という結末になります。サービス・モデルの派生は従来の分析を無効にし、さらに大幅なSOA インフラストラクチャー実装が必要であることがわかるのがおちです。ビジネス・サービスの全体的な適用範囲を定義して変換プログラムを設計する前に、発見フェーズのための予算と計画方法を検討してください。
まとめ
この記事では、SOA を組み込んだビジネス変換プログラムを成功に導くために重視しなければならない分野について概説しました。SOA へのビジネス変換には大きな課題があります。たいていの企業は段階的な変換方法として、新しい複合アプリケーションを作成するための SOA インフラストラクチャーを導入し、サービス・プロバイダーの実装にはレガシー IT システムを使用します。
企業がオペレーション全体でその堅牢性と適合性を維持するには、変換プログラムによって、SOA が組み込まれた (ただし、SOA の適用範囲を超えた) エンタープライズ情報管理ソリューションを開発する必要があります。このソリューションは、SOA 内のレガシー IT システムのデータとコンテンツの整合性および同期という問題に対処し、情報サービスを安全に公開して使用できるようにするものでなければなりません。
SOA 変換の実現に責任を持つソリューション・アーキテクトは、管理対象のエンラープライズ・アーキテクチャーと予算をすべて含めたコンテキストで、レガシー IT システムの機能と SOA のニーズとのバランスをとる必要もあります。情報管理ソリューションの実装戦略では、データ統合とマスター・データ管理の技術が重要な要素となります。
謝辞
この記事を検討し、指導してくれた Rick Robinson、Patrick Dantressangle、Bob Lojek、そして Claudio Cozzi に感謝します。
参考文献 学ぶために
製品や技術を入手するために
議論するために
著者について  | 
| | Jeremy Caine は、IBM Global Business Services のシニア IT アーキテクト兼技術ストラテジー・コンサルタントです。大規模なビジネス変換およびシステム統合計画に取り組む彼は、とくに金融サービス業と政府の顧客を対象として、複合 IT システム、Web 技術ソリューション、エンタープライズ・アプリケーション統合ストラテジーを実現しています。また、世界規模の IBM テクニカル・コミュニティーの積極的メンバーとして、思想におけるリーダーシップを発揮し、SOA などの分野を対象としたオファリングの作成をサポートしています。経験豊富なメソッド・リーダーであり、IBM アーキテクチャー教育チームの一員でもあります。
|
| 
| | Joe Hardman は、IBM Global Business Services のシニア IT アーキテクトで、SOA および Web アプリケーションのアーキテクチャーとセキュリティーを専門分野としています。最近取り組んだプロジェクトには、共謀インターネット・バンクと Polaris i-マーケット、英国営利保険業の Web サービス対応 e-マーケットプレイスがあります。現在は、世界屈指の石油会社での SOA 計画を支援しています。
|
記事の評価
| 
