レベル: 中級 Prabhakar Mynampati, Advisory Architect, IBM
2008年 11月 06日 サービス指向アーキテクチャー (SOA) 開発ライフサイクルのアクティビティーによるメリットを効果的にもたらすには、適切なガバナンス・プロセス・モデルが準備されていなければなりません。この記事では、SOA 開発ライフサイクルのなかで一般的な企業に当てはまるシナリオに基づいた SOA ガバナンス・プロセスについて説明します。さらにサービスの識別、サービスの作成と再利用、サービスのテスト、サービスのバージョン管理と変更管理、サービス・レベルの管理 (サービス品質)、そしてサービス・セキュリティーなど、重要なライフサイクルのアクティビティーをつぶさに検討しながら、企業が一般的な SOA 開発ライフサイクルで直面する可能性のある難題を把握し、これらの難題に対処する方法を学びます。その方法としては、それぞれのシナリオに応じたガバナンスのサブプロセスを実装し、特定の役割と責任をガバナンス組織の対応する層に委任する方法を説明します。
SOA ガバナンスとは何か
SOA ガバナンスはビジネス・ガバナンスと IT ガバナンスが交差する部分で、ここでは SOA のビジネス価値を確実にするためにサービスのライフサイクルに重点が置かれます。SOA ガバナンスの重要なゴールとなるのは、SOA ライフサイクルを効果的に管理することです。
図 1. SOA ガバナンスの定義
IBM の手法: SGMM
IBM のガバナンス手法では、成功を異なる 2 つの側面、つまり定義と実施という点からとらえています。SGMM (SOA Governance and Management Method) は、定義のためのエンド・ツー・エンドの手法で、SOA ガバナンスの設計、実装、改善を通じて行われます。SGMM は適切なガバナンスを確実に行うために必要なすべての要素を特定する規範的な方法となります。必要な要素には、新しい役割と責任の識別、ポリシーとメトリックの定義、そして IBM が従っているプロセス内でのチェックポイントの設定も含まれます。ガバナンスの実施中、IBM ではこれらのポリシーをさまざまな実施ポイントに配布し、関連するメトリックを監視および測定してガバナンス・モデルを改善します。
SOA 開発ライフサイクルでのガバナンス・シナリオ
上記で説明した SOA 開発ライフサイクルの他、IBM では SOA の基盤ライフサイクルの使用も促しています。SOA の基盤ライフサイクルは、ビジネスのモデル化から始まり、モデルから情報システムへの変換、その情報システムのデプロイメントへと続き、最後にデプロイメントの管理という流れとなります。SOA 開発ライフサイクルの流れは IBM の SOA 基盤ライフサイクルの流れとほとんど同じで、一般的なサービス開発はモデル、アセンブル、展開、管理のフェーズで行われます。以下で、それぞれのフェーズについて詳しく説明します。
モデル
モデル・フェーズはビジネス要件をベースとします。このフェーズでは、ビジネス・プロセス・モデルが設計され、ビジネス・サービスが識別され、プロセスが what-if (仮の) ビジネス条件でシミュレートされて、その結果がビジネス目標に照らし合わせて分析されます。目標を達成できない場合には、ビジネス・サービスを変更してプロセスが再定義されます。このようなモデル化という観点からすると、IT サービスの実現に対して 1 対 1 の関係でマッピングされるビジネス・サービスの識別は重要なアクティビティーです。
アセンブル
IT サービスの定義が完了すると、次は設計、仕様、作成、そしてテストをアセンブルするフェーズに移ります。構成されたサービスは個別にテストされるとともに、ビジネス・プロセスの構成とも併せてテストされます。テストで承認されたサービスは、ランタイム・リポジトリーに組み込まれ、サービス・コンシューマーに公開されます。これらのサービスは、さまざまなサービス・クライアントが機能についてはほとんど変更を加えずに使用するため、変更プロセスが承認された上で、機能の異なるさまざまなサービス・バージョンが作成されます。
展開
展開フェーズでは、統合ビジネス・プロセスにより、サービスのさまざまなバージョンがリポジトリーで公開され、サービス・コンテナーにデプロイされます。サービス・リクエスターの選択基準に応じてデプロイ済みサービスを実行時に動的に選択し、複合アプリケーションを組み立てることも可能です。
管理
管理フェーズでは、デプロイされたサービスが、さまざまなサービス要求に適時に対応しているかどうかを監視し、サービス・レベルでの障害を検出してシステムの運用状態を回復させます。このフェーズの間に、サービスと運用環境全体がビジネス目標を満たすように調整されます。サービスは、適切なサービス・レベルのセキュリティー設計およびセキュリティー実装によって、サービス要求に対する同一性および準拠性が管理されます。
この SOA 開発ライフサイクルでは、SOA ガバナンス・プロセスが明確に定義されて実施されていないと、以下の問題が発生する可能性があります。
- 新しいサービスを識別し、優先順位を付けるのが難しいという問題。
- 重複した非効率なサービスを作成してしまうなど、サービスの作成と再利用に関する重大な問題。
- テストのストラテジーおよび標準が無計画に採り入れられるという問題。
- サービスに対する変更とバージョン管理のガバナンスが大雑把で洗練されていないという問題。
- サービス管理、サービス品質 (QoS)、サービス・セキュリティーのガバナンス・ポリシーを実施する体系的な方法がないという問題。
このような問題があることから、以下のプロセスを SOA ガバナンス・モデルの一部として定義し、実施する必要性が生まれる結果となりました。
- 新しいサービスを識別し、優先順位を設定する方法の規定 (サービス識別)。
- 新しいサービスを作成し、再利用する方法の規定 (サービス作成)。
- サービスを最適に実現するためのテスト手順およびストラテジーの実施 (サービス・テスト)。
- サービス・レベル管理 (SLM) に対するガバナンス・ポリシーの実施 (サービス・レベル管理)。
- サービスの変更管理およびバージョン管理の規定 (サービス・バージョン管理および変更管理)
- サービス実行時のセキュリティー標準およびセキュリティー・ポリシーの実施 (サービス・セキュリティー)。
サービス識別の例
どの組織でも、要件の変更に応じて新しいサービスを継続的に増やしていくものです。SOA 開発ライフサイクルではサービスを識別することが最初のステップとなりますが、このステップには現行の IT ガバナンス・モデルを拡張して新しいサービスを取り込む上での問題、そして必要な役割を理解する上での問題があります。
問題
ビジネス・サービスと IT サービスの識別に用いられる方法に一貫性がないためにもたらされるプロジェクトのリスクには、さまざまなものがあります。例えばサービスが相互運用可能でない可能性、そしてそのためにサービスを識別した後にサービスの多くが重複してしまうこともあります。また、サービスの識別と実現に責任を持つビジネス・ドメインの所有者がいないという場合も考えられます。最終的に、このようなリスクのすべてが、プロジェクトの経費を増大させることになったり、納期に間に合わないという事態をもたらしたりします。しかしガバナンス・プロセスを適用することで、これらの問題を解決することができます (図 2 を参照)。
サービス識別のためのガバナンス・サブプロセス
このガバナンス・プロセスのシナリオでは、ポリシーの定義とガバナンス・プロセスの実施に関与することになるのは、IT エクゼクティブ運営委員会のメンバーです。この委員会には、内部 SOA COE (Center of Excellence) のメンバーとビジネス・ドメインの所有者または事業部門 (LOB) のリーダーが含まれます。IT エクゼクティブ運営委員会にはポリシーを定義する権限が与えられます。そしてこのシナリオでは、委員会は以下のことを目指します。
- 既存のオペレーティング・システムからサービスの 70% を作成し、残りの 30% だけを新規サービスとして作成する。
- 識別したサービスを企業全体から見えるようにして、再利用できるようにする。
図 2. サービス識別のためのガバナンス・サブプロセス
ガバナンス・プロセスは、以下の要件を確実に満たすように定義しなければなりません。
- ドメイン分解ビジネス・プロセス・モデルとボトムアップ・モデルの両方を使用して、サービスを識別するための適切な手法を採択すること。
- このガバナンス・プロセスは、IT プロジェクトが事業年度の初めに提案された時点で IT エクゼクティブ運営委員会からの要請で開始するか、あるいはドメイン所有者からの緊急要請として開始すること。
- サービス識別に取り掛かる前に、SOA COE が、LOB リーダーが収集したすべてのビジネス要件が満たされていること、そしてこれらの要件が最新のものであることを確実にすること。これにより、SOMA (Service-Oriented Modeling and Architecture: サービス指向モデリング・アーキテクチャー) のステップが実行されること、そして識別されたサービスが追跡可能であり、ビジネス・ゴールへつながっていることが確実になります。
- 識別されたサービス・モデルは、そのドメインのエキスパートによって検証され、承認されること。
- 承認されたモデルは、重複したサービスが識別されることのないように共通リポジトリーに公開すること。
- このガバナンス・プロセスでは、サービスに責任を持つドメイン所有者が明確に識別されていること。
- このガバナンス・プロセスによって、サービスに対してより適切な要件が定義され、設計時の再利用が促進されること。
サービス作成の例
必要なサービスが識別された後のサービス作成のシナリオでは、サービスの詳細な仕様が定義および実装されます。ガバナンス・モデルの役割は、これらのタスクを実行することではなく、これらのタスクが確実に実行されるようにすることです。SOA COE がサービスを作成するチームとサービスを要求するチームを調整し、ニーズが確実に満たされようにする一方で、重複した作業が行われないようにもします。そしてガバナンス・モデルが、このようなサービスを作成するドメイン所有者を識別するとともに、サービス実装の優先順位を決定します。
問題
ある組織では現在、重複した非効率なサービスが開発され、デプロイされるという問題を抱えています。それは、水平方向と垂直方向のさまざまなドメインが互いのリポジトリーを考慮せずにサービスを作成しているためです。さらに一部のサービスは、システム機能に関する認識に一貫性がない状態で実現されています。いくつにも重複した同様あるいは同一のサービスを保守することによって保守コストは増大し、そのようなサービスがまったく管理されなければ、さらなる開発はストップしてしまいます。このような問題すべてに最終的に必要となるのは、サービス作成プロセスの規定です。
サービス作成のためのガバナンス・サブプロセス
ガバナンス・プロセスは、以下のステップに従って定義されています (図 3 を参照)。
- 新しいガバナンス・プロセスの定義を作成する際には、プロジェクトの候補を検討して、どのプロジェクトを続行するかを決定する現行の IT 計画プロセスを念頭に置くとともに、各種のサービス・ドメインでそれぞれのサービスに対して責任を持つ所有権の役割を理解してください。また、資金調達プロセスを理解した上で、サービス仕様のフェーズで定義された QoS に対処するための包括的方法を定義しなければなりません。
- ガバナンス・プロセスではまず、SOA COEが潜在的サービスとしての機能を評価することによってプロジェクトを開始します。評価には、再利用、ビジネス・アジリティー、およびデプロイメントの柔軟性などといった共通の評価基準を使用します。
- 機能をサービスにすると決定した後、各種のサービス・レジストリーを検索し、同じようなサービスが存在していないことを確認します。そのような既存のサービスが見つからなければ、SOA COE はそのサービスが属するビジネス・ドメインに応じてサービスに所有権をあてがいます。
- 共通して使用されるインフラストラクチャーおよび技術サービスの所有権は、SOA COE が保持します。
- SOA COE が他のサービスとの相対的な優先順位をサービスに割り当てます。SOA COE が、サービスが属するドメイン所有権を基にそのサービスの優先順位が高いと判断した場合、ドメイン所有者が財源を割り当てます。
- サービス所有者は、SOA COE の専門的スキルを持つメンバーによる協力の下、サービスを設計および開発する上での適切なリソースを割り当てます。
- 識別されたサービス・モデルが、そのドメインのエキスパートによって検証され、承認されます。
- SOA COE アーキテクトがインターフェース、メッセージ・フロー、非機能要件 (NFR)、および詳細な機能要件を定義します。
- サービスの仕様が完成した後、SOA COE はもう一度サービスを検討し、サービス実現を進める上での優先順位を決定します。
- 実現のフェーズでは、SOA COE アーキテクチャー・チームが協力してサービスの詳細な設計を作成し、垂直方向のドメイン開発チームを対象として、サービスを技術ツール、実装などに対応付けます。
- SOA COE は、サービスが標準とベスト・プラクティスに準拠していることをさらに確認し、それによってデプロイメントと管理でのリスクを軽減させます。
(図 3 の拡大バージョンを参照してください。)
図 3. サービス作成のためのガバナンス・サブプロセス
サービス・テストの例
このシナリオでは、実現されたサービスをテストし、必要な機能があるかどうか、そして結合テストおよびシステム・テストに適しているかどうかを判断します。結合テストとシステム・テスト両方のレベルでの適格性が認められると、続いてサービスの NFR テスト (応答時間テスト、リソース使用量テスト、トランザクション処理能力テストなど) が行われます。
問題
このシナリオでは、さまざまなグループが異なるツールとテスト・ストラテジーを使用して自分たちのサービスをテストしているという状況を検討します。つまりこの組織には、サービスを実現するためのツール、プラグイン、テスト・ストラテジーを使用する上での統一した方法がないということです。これは一部のサービスでの準拠性テストが縦割りの部門で開発されたことに起因しますが、そのために、実現された IT サービスではビジネス要件が適切に満たされていないという問題が生じました。部門によっては、厳しいプロジェクト・スケジュールのなかで、結合テストとシステム・テストを期日までに行うことが不可能になっています。体系的な IT サービスの実現に従ってビジネス要件の変更に対処するのに苦労しているプロジェクト・チームもあります。このすべての点が、テスト・シナリオでのガバナンスにとって問題になっています。
サービス・テストのためのガバナンス・サブプロセス
図 4 に示した詳細なプロセスには、以下のステップが含まれます。
- SOA COE は、機能および非機能テスト・ツールとテスト環境用のプラグインの識別を行う権限を持ち、プロジェクトの要件に基づいてテスト・ストラテジーを定義します。
- SOA COE は他のビジネス部門に対し、これらのツールとテスト・ストラテジーを使用するように指定し、使用を促進します。
- プロジェクトのガバナンス・プロセスでは、SOA COE が対応するドメインのビジネス・アナリストと協力し、サービス・テスト・ケースのドキュメントを作成することから始まります。この文書はビジネス・アナリストが承認します。
- SOA COE は、そのプロジェクトで識別された開発チーム、あるいはサービス所有者によって識別されたリソースによるサービスの単体テストを開始します。
- SOA テスターが単体テスト・レポートの作成を完了すると、プロセスでは次に、サービスの結合テストの要求が開始されます。
- 結合テスト・ケース・ドキュメントの作成には SOA COE のインテグレーション・アーキテクトが参加します。この文書はビジネス・アナリストが承認します。
- SOA COE のメンバーは、ビジネス部門内あるいはビジネス部門間のさまざまなチームによって結合テストに必要なすべてのサービスが開発されるまで待ちます。
- 結合テストに必要なサービスのうち、未だに作成プロセスにあって準備が整っていないサービスがあるために遅れが生じている場合には、COE のメンバーがモック・サービスを使用して結合テストを開始するかどうかを判断する必要があります。
- システム・テストの開始も上記と同じようなガイドラインに従い、インフラストラクチャー・アーキテクトとの活発なやり取りによって、システム・テストに必要なソフトウェアとハードウェアの正しいバージョンと構成が識別されます。
- システム・テストのレポートが完成すると、COE は NFR テストを開始します。
(図 4 の拡大バージョンを参照してください。)
図 4. サービス・テストのためのガバナンス・サブプロセス
サービス・バージョン管理および変更管理の例
新しいサービスが本番環境でリリースされた後、これらのサービスのユーザーは変更を要求するようになります。バグの修正、インターフェースの再設計、新機能の追加、そして不要な機能の削除は欠かせません。サービス・バージョン管理は、既存の実証済みのサービス機能を損なうことなく、システムを安定した状態で稼働させるために役立つだけでなく、既存のサービスに新しい機能を追加できるようにします。
問題
ビジネス要件が変更されても、必ずしもその変更を IT インフラストラクチャーに実装しなければならないとは限りません。このシナリオでは、ビジネス・プロセスに必要な変更を IT に実装する必要があるかどうか、そしてその変更を既存のサービスに実装するべきか、あるいは次期バージョン・リリースとして実装するべきかを判断する権限を持つ者が組織にいないという設定です。この企業には、変更を調査し、変更による他のサービス・コンシューマーへの影響を把握する共通機構がありません。さらに、サービスのバージョン管理を対象としたランタイム・ポリシーを決定する権限を持つ者もいません。サービス・バージョンの変更時には運用が中断されることから、システムが利用できないという苦情が顧客から上がっています。円滑な遷移を可能にする、規則に基づくサービス・プロバイダーの自動選択は行われていません。また、システム内でどのサービスが実行中で、どのサービスが実際に使用されていて、どのサービスの提供が取りやめられているかを把握するための追跡メカニズムもありません。このような問題によって、サービス・バージョン管理のガバナンスを実装せざるを得なくなりました。
サービス・バージョン管理および変更管理のためのガバナンス・サブプロセス
図 5 に定義された詳細なプロセスには、以下のステップが含まれます。
- このプロセスでは、IT エクゼクティブ運営委員会がガバナンス機構で重要な役割を担います。この機構には、ビジネス要件の改善に応じた IT の変更を許可する権限が与えられます。
- この機構はまた、サービスのどの基本バージョンを拡張するか、そして変更を既存のサービス・バージョンでリリースするか、あるいは次期バージョンとしてリリースするかも決定します。IT エクゼクティブ運営委員会への情報提供は SOA COE が取り仕切り、SOA COE はそのためにプロジェクト・チームまたは縦割りの部門からサービス・バージョンの詳細情報を入手します。
- SOA COE では、既存のサービスの変更が他のサービス・コンシューマーにどのように影響するかを調べ、影響の詳細を IT エクゼクティブ運営委員会に提出します。
- SOA COE は NFR を念頭に置いた上で、既存の変更を調査します。ただし変更が NFR の強化ではない場合には、プロバイダーとコンシューマーとの契約に基づいてランタイム・サービスのバージョン管理ポリシーを定義し、識別しなければなりません。
- 続いて COE は、メディエーター、ビジネス・ルール、セレクター、ビジネス動的アセンブラーを介したさまざまなバージョンのサービスを作成し、デプロイするための各プロジェクト・チームを識別します。
(図 5 の拡大バージョンを参照してください。)
図 5. サービス・バージョン管理および変更管理のためのガバナンス・サブプロセス
サービス管理の例
サービスの監視と管理は、サービスが本番環境へ移行された後の重要なアクティビティーです。サービスが 1 つでも機能しなくなった場合、システムはそのサービスが直面している問題を識別および検出しなければなりません。サービスを監視することにより、システム・アーキテクトは問題を検出し、発生する前に防ぐことができます。サービス監視では負荷の不均衡および障害を検出し、重大な問題になる前に警告できるだけでなく、問題の自動修正を試みることも可能です。
問題
このサービス管理のシナリオでは、さまざまなサービス・コンシューマーに公開されたサービスを監視し、管理するという難題に直面している組織について検討します。このシナリオでは、サービス・プロバイダーの役割が大きくなります。サービス管理アーキテクチャーの不完全な設計が原因で、この組織のサービスは高可用性の期待、パフォーマンス・メトリック、そして定義されたサービス・レベル・アグリーメント (SLA) を満たすことができませんでした。設計チームおよび開発チームは、SLA に基づいて監視する必要があるサービスとリソースを認識していません。ビジネス・アプリケーションの状況を確認するエンド・ツー・エンドの管理ツールを導入するための統一した方法も、個々のリソースを対象としたパフォーマンスおよび可用性メトリックに関する詳細情報を提供するための統一した方法もありません。このすべての点が原因で、サービス管理のガバナンスを実装せざるを得なくなりました。
サービス管理のためのガバナンス・サブプロセス
サービス管理のガバナンス・プロセスは、以下の基本ステップに従う必要があります (図 6 を参照)。
- SOA COE がビジネス・チームと協力し、顧客から NFR を収集します。
- SOA COE が LOB サービス・レベルのマネージャーと管理アーキテクトと協議して、SOA 基盤ライフサイクルのモデル・フェーズ期間中の SLA を定義します。
- SOA COE のコア・チームがこれらの SLA を分析し、管理アーキテクチャー・ドキュメントを設計します。管理アーキテクト、IT 管理者、サブジェクト・マター・エキスパート、そしてアプリケーション開発者が、複合アプリケーションを管理するためのリソースの識別を支援します。
- SOA COE のメンバーは、管理アーキテクチャーをサポートする管理開発ツールも識別します。
- IT 管理者と関連する縦割り部門のサービス・プロバイダーの協力により、COE はビジネスと IT 両方のパフォーマンス・リソースを監視するための共通監視コンソールが開発されることを確実にします。
(図 6 の拡大バージョンを参照してください。)
図 6. サービス・レベル管理のためのガバナンス・サブプロセス
サービス・セキュリティーの例
SOA セキュリティーにより、サービスに対するユーザー・アクセスを制限し、サービス・プロバイダーとサービス・コンシューマーとの間で交換されるデータを保護します。許可されたユーザーのなかでも、そのすべてのユーザーに、サービスがアクセスするすべてのデータへのアクセスを許可すべきではありません。サービスへのアクセスは制御し、許可されたコンシューマーだけがアクセスできるように制限します。そのためには、ユーザー ID をサービスに送り、データ・アクセスを許可するために使用する必要があります。また、データ保護の品質は、ある範囲内に規定されたポリシーとして表す必要があります。これにより、コンシューマーが最低限の保護レベルと最大限の機能を提示すると、そのコンシューマーを、さらなる保護手段を講じている可能性すらある適切なプロバイダーに照合することが可能になります。
問題
このシナリオでは、セキュリティーの脅威を撃退し、サービスを外部アクセスから保護するための共通のストラテジーが、組織にはないという設定です。サービスの認証と許可が複数あることが、オペレーターを苛立たせています。採用したセキュリティー・ポリシーを最初から実施に至るまで追跡するためのセキュリティー・ポリシー管理フレームワークはなく、企業境界にある組織とコミュニケーションを取って共通のセキュリティー標準を維持することに責任を持つ機構もありません。さらに、他のサービスとデータとの相互作用に対して合意されたセキュリティー標準はなく、ポリシー管理の役割と責任も定義されていません。これらの問題により、この組織はサービス・セキュリティーのガバナンス・プロセスを定義し、導入する必要に迫られました (図 7 を参照)。
サービス・セキュリティーのためのガバナンス・サブプロセス
この場合のガバナンス・プロセスは、以下のステップに従う必要があります。
- サービス開発のモデル・フェーズで、SOA COE がビジネス・アナリストと企業セキュリティー・アナリストと連携し、特定の SOA シナリオ (サービス作成、サービス接続、サービス連携、ビジネス・プロセス管理など) ごとにセキュリティー要件をモデル化します。セキュリティーの実装はシナリオによって大幅に異なるからです。
- SOA セキュリティーのリファレンス・アーキテクチャー、セキュリティー標準、シナリオ・ベースのセキュリティー実装ストラテジー、そしてベスト・プラクティスの開発については、SOA COE 内部で責任を持ちます。
- SOA COE はビジネス・アナリストの協力の下、プロジェクトの実装に必要な各種の IT セキュリティー・サービスを識別し、これらのサービスを実装する上でオープン・スタンダードに準拠しているかどうかを確認します、
- SOA COE が、各種のセキュリティー・イネーブラー (暗号化技術など)、ユーザー情報を保管するためのレジストリーとリポジトリー、ハードウェア・キー、そして IT セキュリティー・サービスを実現するファイアウォールを識別します。
- SOA COE は、プロジェクト・チームの実現シナリオに従って、定義済みの論理アーキテクチャーおよび物理アーキテクチャーを再利用および共有します。
- SOA COE がさまざまな縦割り部門のアプリケーション開発者の協力を得て、セキュリティー・ポリシーを実装するための各種ツールと製品を識別します。
(図 7 の拡大バージョンを参照してください。)
図 7. サービス・セキュリティー
まとめ
この記事では、SOA ガバナンスの観点で価値のある重要なシナリオを取り上げ、それぞれのシナリオに伴うリスクを軽減する方法を説明しました。ガバナンスのシナリオは、組織の構造やセットアップ、そしてプロセスに必要なコンテキストなどによって、さまざまに異なることが考えられますが、この記事で定義したガバナンスのすべてのシナリオをそれぞれに合わせて調整してください。
謝辞
この記事の執筆を支援し、完成に導いてくれた John Falkl 氏と彼のチーム、そして Amar Raiker 氏と Yaseen M Yaseen 氏に感謝いたします。
参考文献 学ぶために
製品や技術を入手するために
- IBM 製品の評価版をダウンロードして、DB2®、Lotus®、Rational®、Tivoli®、および WebSphere® のアプリケーション開発ツールとミドルウェア製品を使ってみてください。
議論するために
著者について  | 
| | Prabhakar Mynampati は、インド IBM Software Labs で BPTSE に取り組む SOA アーキテクトです。彼は IBM の ISV クライアントが IBM の SOA、CBS リファレンス・アーキテクチャーを使用してアセット集約ソリューションを構築する際の支援を行っています。 |
記事の評価
| 
