レベル: 中級 Geoffrey Meissner (geoff@us.ibm.com), Executive Architect, IBM CIO Office, IBM
Luba Cherbakov (lubacher@us.ibm.com), IBM Distinguished Engineer, IBM
Lance Walker (lancew@us.ibm.com), IBM Distinguished Engineer, IBM
2007年 4月 13日 この連載ではさらに 2 つの SOA インプリメンテーションを取り上げて、IBM Corporation が重要なビジネス・サービスをデプロイするために、どのようにSOA を使用しているかを説明します。最初の事例 5 では外部ビジネス・パートナー・アプリケーションを対象とした IBM 社員の ID 管理を検討し、次の事例6 では IBM の顧客およびビジネス・パートナーの ID 管理と IBM Web サイトのユーザーを対象とした資格付与について検討します。この2 つの事例を選択した理由は、SOA で解決できるビジネス上の課題が多種多様であることを表すためです。それぞれの事例では、SOA 対応ソリューションによって、プロセスおよびビジネス・ルールに対する変更を、組織境界さえも超えて広範で容易かつ低コストにすることで、目的とするビジネスの柔軟性を実現できることを実証しています。
はじめに
事例研究は、IBM が多種多様なビジネス上の課題を解決するためにどのように SOA を利用しているかを明らかにすると同時に、皆さんがそれぞれに抱えるビジネス上の課題をSOA で解決する方法を見つける糸口にもなります。
連載第 1 回で取り上げたのは、顧客の注文分析を焦点とした事例 1、そして追跡システムとマイクロエレクトロニクスの箱の中のファクトリーを焦点とした事例 2です。記事の中ではビジネスの背景、それぞれの事例研究プロジェクトが克服しなければならなかった課題、最終的なソリューションのアーキテクチャー概要、そしてそのソリューションを可能にした技術とツールを説明しました。さらに、それぞれのプロジェクトによって達成された具体的な業績、そして、そこで得られたベスト・プラクティスと教訓(IBM および IBM の顧客が現在適用しています) についても説明しました。
連載第 2 回では、法規制の順守を支援する輸出検証サービスを焦点とした事例 3、CCMS (Central Customer Master System)を焦点とした事例 4 を検討しました。
今回の記事で紹介するのは、同じく SOA の手法を使用した事例です。まず、事例 5 では外部ビジネス・パートナーのアプリケーションを対象とした ID 管理を取り上げます。そして事例 6 では、IBM の顧客とビジネス・パートナーの ID 管理と IBM Web サイトのユーザーを対象とした資格付与について検討します。今までの2 回の記事で説明した事例研究の一部は業界固有のものでしたが、今回説明するイニシアチブは、業界を問わずに一般的に発生するシナリオを表しています。
事例 5: IIPx (IBM Intranet Password External)
事例 5 では、外部ビジネス・パートナーのアプリケーションを対象とした ID 管理を取り上げます。
ビジネスの背景
IBM 内部 Web アプリケーションが増えるにつれ、IBM 社員が管理しなければならならない ID とパスワードの数も増えていきました。初期のアプリケーションのそれぞれが、独自の認証メカニズムを開発していたためです。1990年半ばになると、各 IBM 社員に対してすべての IBM 内部 Web アプリケーションで使える単一の ID とパスワードのクレデンシャルを提供する、唯一かつ世界規模の認証機能が必要なことは一目瞭然になりました。そこで開発されたのが、IIP(IBM Intranet Password) 機能です。この IIP が内部アプリケーションの ID 管理を可能にする共通ソリューションとしてデプロイされたのですが、IBM社員一人ひとりに単一の ID とパスワードを提供するという IIP の目標は完全には実現されませんでした。その原因は、IBM 社員が IBM関連の通常業務を行うために、かなりの数の IBM ビジネス・パートナーのサイトとアプリケーションを使用していたことです。このようなサード・パーティー・ベンダーによる外部Web サイトには、外部委託の旅行予約、管理調査、退職金積立制度、社内指導教育、IBM ブックストアなどがあります。アプリケーション・プロバイダーのシステムごとにID とパスワードのスキーマはまちまちだったため、IBM 社員にはこれらのアプリケーションにアクセスするために複数の ID とパスワードが必要だったのです。
課題
IBM 社員は、パートナーが提供するビジネス・アプリケーションを使用するときに、それぞれのアプリケーションがインプリメントする異なる認証ソリューションを使用しなければなりませんでした。一般的に、各ビジネス・パートナーは、そのサイトのユーザーに対して認証クレデンシャル(一般的には単なる ID とパスワードの組み合わせ) を作成し、有効なパスワードとパスワード有効期限に関するルールを確立しています。そのため、IBM社員は IBM ビジネス関連の機能を実行するかたわら、外部 Web サイトでの複数の ID とパスワードを追跡してリセットするという作業に無駄な時間を費やしていました。
一方、IBM パートナーはその認証システムが独自のものであるがために、IBM 社員からのクレデンシャル支援の要請に対応するヘルプ・センターを用意しなければなりませんでした。さらに、認証管理ソリューションとビジネス・ルールの開発および管理に伴う諸経費もIBM との契約料で補う必要がありました。
IBM 社員の満足度向上と経費削減を図るには、パートナーのアプリケーションで共通した認証が必要であることは明らかでした。一部のビジネス・パートナーはIBM 社員のクレデンシャル認証を管理するという目的で、IBM 社員の LDAP ディレクトリーのコピーとその定期的更新を要求しましたが、IBM内部ネットワークの整合性を維持すると同時に社員のプライバシーを守るには、IBM が社員データを IBM 外部で共有したり、パートナーに IBM内部ネットワークへのアクセスを許可して内部 LDAP インスタンスを直接使用させることはできません。さらに、この問題に対するソリューションは、すでに実施されているセキュリティー・システムによっても制限されていました。
ソリューションに課せられた制約は、以下のとおりです。
- 既存のアプリケーションに対する影響を最小限にすること。新しいソリューションをインプリメントするために各ビジネス・パートナーに大々的な作業を行わせるのは現実的とは言えませんでした。
- 既存の ID とパスワードはそれぞれのアプリケーションで有効にすること。IBM 社員にとってできる限り容易な移行を実現することも目標だったからです。
- ビジネス・パートナーが比較的簡単にインプリメントできるソリューションであること。ソリューションはセキュアでなければなりませんが、ビジネス・パートナーは大量の作業やパスワードを管理するための継続的な作業が必要となるソリューションに関心を持ちませんでした。
SOA ベースのソリューション
IIPx と命名された最終的な SOA 対応ソリューションを図 1 に示します。IIPx は、IBM イントラネットの ID とパスワードを使用して外部Web アプリケーションにアクセスする認証ユーティリティーです。IIPx がベースとしているのは、内部アプリケーションを対象とした社員 IDの管理用として以前にデプロイされた IIP ソリューションが築いた基盤です。
図 1. IIPx アーキテクチャーの概要
外部アプリケーションは、IBM が提供する Web サービスを使用して IBM 社員の ID を検証します。このサービスでは、トークン (デジタル署名されたXML 文書) の妥当性検査を行います。IIPx は、IBM 内部 IIP が社員を認証するとトークンを作成し、内部ディレクトリーを使って固有のLDAP 認証を行います。ユーザーのクレデンシャルが内部で認証されると、ユーザーのブラウザーは作成されたトークンと共に外部サイトにリダイレクトされます。
以下に、図 1 に示した典型的な IIPx ログイン・セッションを順を追って説明します。説明の番号は、図中の番号に対応します。
- IBM 社員がビジネス・パートナーの Web サイトにリンクし、ベンダー ID コードが含まれるリンクに従って IIPx ログイン・ページにアクセスします。これは、IBM内部ネットワーク (w3 と呼ばれます) 上で行われます。このリンクは通常、IBM 内部の IIPx ログイン・ページにアクセスするボタンあるいはURL です。
- w3 で認証が行われます。
- IBM 社員が IIP ログイン・クレデンシャルを入力します。このクレデンシャルは、IBM 社員が持つ通常の内部 ID とパスワードです。
- IIPx サーバーが、IBM 社員の内部クレデンシャルが認証されるのと同じ方法で IIP ログインの妥当性を確認します。
- IIPx サーバーが、内部 IBM 社員ディレクトリー (IBM 内部では BluePages と呼ばれます) から取得した基本社員情報が含まれるXML 文書を作成します。
- この文書は、Web サイトにアクセスしている社員に関する情報を提供するためにベンダーに渡されます。
- IIPx サーバーが、XML 文書のデジタル署名を作成します。この署名がベースとするのは、IBM 内部でのみ使用できる共通 IBM マスター・キーです。
- IIPx サーバーが、XML 文書と署名をエンコードした HTTP リダイレクト URL を生成し、この URL を社員のデスクトップ上のクライアント・ブラウザーに返します。
- 認証トークンが渡されます。
- クライアント・ブラウザーはリダイレクト URL に従ってサード・パーティーの Web サイトにアクセスします。
- サード・パーティーのサイトは、URL に含まれる変数から XML 文書と署名を取得します。
- サード・パーティーのサイトは、署名と文書を IBM の IIPx Web サービス (SOAP インターフェース) に渡します。IBM がホストするこのサービスは、ビジネス・パートナーへのエクストラネットに用意されています。
- IBM の IIPx 外部 Web サービスが、文書と署名との一致を検証します。これにより、キーの一致が確実になります。つまり、IBM からのログインとデータが正しいということです。IIPx外部 Web サービスが、肯定的な結果を戻します。
- サード・パーティーのサイトが、ユーザーのセッションを確立し、ベンダーのサイトでの作業が続行されます。
IIPx の実際のデプロイメントを管理するために、インクリメンタル搭載という概念が使用されました。この概念は、新しい機能がデプロイされている間、アプリケーションは既存の認証機能を引き続き実行できるというものです。そのため、限られた切り替え期間中は新旧双方のIIPx 認証を使用することができ、新しい認証が完全にテストされてから以前の認証を無効にすることができました。
さらに、このインクリメンタル搭載では、すべてのアプリケーションすべてが 1 日も停止することがないことを保証していました。そのため、各ビジネス・パートナーはそれぞれのアプリケーションに妥当で、さらに自分たちの作業負荷を基に実行可能な切り替えスケジュールを決定することができました。またインクリメンタル搭載では、すべてのユーザーに変更が行われるという認識を行き渡らせる時間に一層余裕が持てるため、IBM社員にとっても有益でした。
 |
エクストラネット
公開 Web サイトとエクストラネットの違いのなかで最も重要な点の 1 つは、ユーザーが検索対象とする情報です。Web サイトでは、ユーザーは購入や投資の決定を行う上で必要な情報を検索します。エクストラネットのユーザーはすでにその組織に投資していたり、あるいはその組織からかなりの購入を行っているため、彼らが検索するのは、組織との関係や製品を最大限活用するための詳細な情報です。この定義で言うと、サポートWeb サイトもエクストラネットの部類に入ります。つまり、エクストラネットのユーザーが求めているものは内容の濃い情報です。例えば再販業者用のエクストラネットには、価格リスト、製品の技術的詳細、販売促進プログラム、対話式構成ツールがあると考えられます。
|
|
業績
IIPx ソリューションは、パートナーや社員から即座に承認され、肯定的なフィードバックを受けました。新しい認証機能の導入は、基本的には社員の目に見えないものでした。このサービスのインプリメンテーションによってIBM が実現したのは、確立された IBM メカニズム内部から新しい社員ユーザーを追加し、その ID とパスワード管理することを可能にするビジネスの柔軟性です。IBM社員は現在、改善されたエクストラネットを体験しています。記憶しておかなければならない ID とパスワードはたった 1 組で、外部のベンダーが管理するアプリケーションWeb サイトを呼び出すための特別なステップもありません。一方、IBM ビジネス・パートナーは、このサービスを使用することでかなりの経費削減を実現しました。ビジネス・パートナーがユーザーのID とパスワードを設定する必要も、パスワード・システムを管理する必要もなくなったからです。
使用されているベスト・プラクティスと教訓
IIPx のインプリメンテーションで再使用された IIP インプリメンテーションは、実績のある IIP サービスです。この再使用は、SOA の柔軟性を明確に示しています。IIPは IBM 社員が内部アプリケーションにアクセスするために内部でインプリメントされたものですが、認証モデルと Web サービスによって IBM外部から IIP を使用できるようにしたことにより、セキュリティーや IBM 社員ディレクトリーの整合性を犠牲にすることなく、この機能が有効に生かされています。
IBM ビジネス・パートナーはこのソリューションをすぐに承認したものの、その個別のソリューションの変換には時間がかかりました。一部でこの遅れが生じる原因となったのは、スケジュール、リソースの可用性、そしてその他のビジネス制約です。ただし、インクリメンタル方式のインプリメンテーションという概念によって、IBMビジネス・パートナーはそれぞれのニーズに合ったスケジュールで、個別の着実な変換過程を定義することができました。その結果、特定の時間枠がプロジェクトの重荷になることもなく、アプリケーション単位での理にかなった新規機能の段階的導入が実現したというわけです。
Web サービスを使用した SOA インターフェースは、企業そのものだけでなく、数々の外部パートナー全体での社員のクレデンシャル認証に対処するセキュアで確実なソリューションになります。このインターフェースでスプーフ(他人になりすますこと) を困難にしているのは、セキュリティー・クレデンシャルをビジネス・パートナーに渡す方法です。クレデンシャルは URLでパラメーターとしてビジネス・パートナーに渡され、ビジネス・パートナーが IBM のエクストラネット Web サービスを使用して、そのクレデンシャルの妥当性確認をIBM に要求します。この突き合せにより、IBM 社員とビジネス・パートナーの双方が、IBM 社員が正しく識別されること、そしてその社員に認められた機能とデータへアクセスできること、に信頼を持てるというわけです。
IIPx チームは、混乱のない移行過程を実現するレガシー・アプリケーションのインクリメンタル搭載も採用しました。一部のアプリケーションには、IIPx以前に ID とパスワードのシステムが設定されていたためです。インクリメンタル搭載では、ビジネス・パートナーが開発の完了時にこのメソッドに移行することも、切り替えが完了するまで新旧両方の認証形式を使用することもできます。
IIPx が成功した理由は、ベンダーが管理する IBM 機能にアクセスするだけのために、すべての IBM 社員が新しい ID とパスワードを取得しなければならない、ということがなくなったためです。ビジネス・パートナーのWeb サイトへの遷移は事実上シームレスなため、おそらく IBM 社員の大多数はこれらのアプリケーションが IBM 外部の環境で実行されていることに気付いていないでしょう。このほとんど透過的なインプリメンテーション、あるいは新規機能への移行は、ほとんどのプロジェクトが通常目標とするところですが、達成されることは滅多にありません。
事例 6: Customer IBM Web Identify - IBM Web サイトおよび関連機能のユーザーを対象とした ID 管理と資格付与
ビジネスの背景
www.ibm.com ドメインは、IBM が情報を掲載するとともに、顧客やビジネス・パートナーとやり取りするために使用する Web サイトと関連アプリケーションの集合です。直接的e-commerce と採用のための Web サイトに加え、このドメインにはビジネス・パートナーが製造、調達、あるいは配送に関する情報を調べられるポータルも含まれています。
顧客やビジネス・パートナーをサポートする各種の外部 IBM Web サイトでは、ユーザーが、サイトごとに固有のユーザー・クレデンシャル (ユーザーID とパスワード) を持っていなければなりませんでした。顧客やビジネス・パートナーが、外部サイトごとに名前、住所、E メール・アドレスなどの基本登録情報をサブミットして登録するわけですが、これらの情報は必然的に重複します。孤立したサイト(Software Developer Support など) のドメインには共通の認証および登録ソリューションがいくつかデプロイされましたが、それでもユーザーは各種のIBM Web サイトにアクセスするために、複数のクレデンシャルを保持しなければなりません。その上、各種の Web アプリケーションがそれぞれ独自のID とパスワードの認証機能を開発、デプロイ、維持することから、リソースも無駄になります。これが顧客の不満の種となっていたため、IBM イントラネット・パスワード・ソリューションのようなIBM 企業全体に共通の IT ソリューションで対処する必要がありました。
課題
ibm.com ドメイン内の情報を安全に保ち、許可されたユーザーにだけ情報が提供されるようにするため、認証システムは常に重要な機能のひとつでした。ところがインターネットの拡大に併せて、さまざまなIBM Web アプリケーション開発チームがビジネス・パートナーや顧客が使用するパスワード・スキーマを作成していったため、パスワード・スキーマは雑多になっていました。
外部ユーザーの中央ディレクトリーが存在しなかった当時、IBM Web アプリケーションはユーザーに関する ID および登録情報を共有できませんでした。そのため、IBMが顧客とパートナーのためにデプロイした Web ページまたはアプリケーションがそれぞれに固有の認証情報を収集しなければならなかっただけでなく、各アプリケーションが確立していたユーザーID とパスワードの要件 (パスワードで許容される文字数や文字の種類など) も異なっていました。このような要件の違いは、ユーザーにとって手間であるだけでなく、新しいアプリケーションをインストールするにも時間がかかります。
そこで必要となったのが、顧客とビジネス・パートナーごとに単一のユーザー ID とパスワードを提供し、そのユーザー ID とパスワードで ibm.comドメインのどの Web アプリケーションにもサインオンできるようにする、企業全体の共通のソリューションです。このソリューションでは、各アプリケーションの所有者が単独でアプリケーションのアクセス権を管理できるようにする必要がありました。
多くのアプリケーションが固有の認証ソリューションを持っていたため、ビジネス・パートナーにはそれぞれ独自の登録済みユーザーがいました。目標の 1つは、これらのユーザーをできるだけ多く新しいシステムに移行させ、既存のユーザー ID とパスワードが持つフォーマットの違いに対処することです。理想としては、外部ユーザーが登録しなくても済むようにしたり、さらには新規システムが舞台裏で認証を管理していることさえ気付かないようにすることです。最終的なWeb Identify サービスは、こうしたすべての要件を 1 つのソリューションでサポートする必要がありました。
SOA ベースのソリューション
Web Identify (WI) は、ibm.com アプリケーションにユーザー情報を提供するシステムです。このシステムは中央データ・ストアに保管されたユーザー・プロファイル情報を収集し、その情報をWeb サービス・インターフェースで使用できるようにします。プロファイル情報には、ユーザー名、住所、好みのコンテンツ、興味のある分野、マーケティング許可などの標準要素が含まれる他、アプリケーション固有のデータもあります。このようなプロファイル情報を一箇所で収集できれば、ibm.com全体がばらばらなものに見えることがなくなり、将来的な Web パーソナライゼーションも可能になります。
WI は認証サービスにもアクセスし、アプリケーションがユーザーを認証してグループと役割を管理できるようにします。
さらに、アプリケーションは WI システムを介してセッション情報を共有できるため、URL パラメーターや cookie を介して情報を渡す必要がなくなります。
WI システムには搭載プロセスがあり、アプリケーションはこのプロセスを使用して、アプリケーションに関連付ける役割と権限を Web Identifyツールで記述します。WI システムは LDAP ベースのディレクトリー・サービスを提供し、アプリケーションでユーザーの権限管理のために使う役割を、アプリケーション管理者がユーザーに割り当てられるようにしています。
サービス指向 (SOAP) インターフェースを使って実行する、WI システムの機能を使用するためのステップは以下のとおりです。
- アプリケーションの搭載
- ユーザー ID とプロファイルの設定
- アプリケーションへのユーザー・サインオン
アプリケーションの搭載
このセクションでは、WI システム内およびユーザーのアクセス要求を承認する現行の機能にアプリケーションをセットアップする方法を説明します。まず、それぞれのアプリケーションが、そのアプリケーションの機能に対するユーザー・アクセスを制御する1 人以上の管理者を割り当てます。一部のアプリケーションでは、そのサイトの管理を担当する IBM 社員が管理者になりますが、別のケースでは、ビジネス・パートナーとのやり取りのために開発されたIBM Web サイト内のアプリケーションに対する、ビジネス・パートナーの社員のアクセス権を管理するビジネス・パートナーが管理者となります。管理者はWI チームと協力してアプリケーションを定義します。この定義には、その特定のアプリケーションで設定する役割やアクセス・レベルも含まれます。管理者は継続的に新規ユーザーからのアクセス要求を検討し、アプリケーションに関連付けられた特定の役割を新規ユーザーに割り当てます。これによりユーザーは、必要とする多数のIBM アプリケーションへのアクセス権を獲得します。
ユーザー ID とプロファイルの設定
外部ユーザーから見ると、WI Web サイトではユーザーが自身の ID とパスワードを作成できます。作成した ID とパスワードは、アクセスするアプリケーションとは関係なく維持できます。さらに、このWeb サイトではユーザーが基本情報 (名前、住所、E メール・アドレスなど) のプロファイルを登録、作成したり、興味の対象とするサイトの部分やIBM オファリングを宣言することもできます。最初、ユーザー ID には特定のアプリケーション領域も特権も関連付けらません。アクセスできるようにするには、ユーザーが自分のニーズに応じて特定のアプリケーション(特定の役割やアクセス・レベルも含め) へのアクセスを要求します。アクセスが承認されると、ユーザーはその特定のアプリケーションにサインオンして機能を使用できるようになります。
図 2. WI アーキテクチャーの概要
アプリケーションへのユーザー・サインオン
以下に説明するのは、図 2 に示した典型的なセッションです。箇条書きになったそれぞれの説明は、図中のフィーチャーに左から右の順で対応します。
- ユーザーが ibm.com システムから機能にアクセスすると、TAM (Tivoli Access Manager) による認証が行われます。TAMは、アクセスしたユーザーを対象に認証機能を実行し、そのユーザーのサインオンを許可または拒否します。
- ユーザーのクレデンシャルが認証されると、セッションが WI 導入アプリケーション (WI Adopting Application) に渡されて機能を実行します。
- WI 導入アプリケーションが一連の呼び出しまたは Web サービスを介してユーザーのセキュリティー、プロファイルおよびセッション情報にアクセスすることにより、アプリケーションはユーザーに関する特定の情報を取得します。
認証および許可機能
WI システムは、ユーザーがセッションを開始した後にユーザーのクレデンシャルとプロファイル情報を取得するためのサービスを提供します。これらのサービスによって可能になるのは、アプリケーションがユーザーの基本登録プロファイル、そしてユーザーに割り当てられたアプリケーションと役割を取得することです。これにより、アプリケーションが各ユーザーに関する詳細な情報を収集して、どのibm.com Web サイトでもユーザー・セッションをカスタマイズできるようになります。
表 1 に、用意されているサービスの一部を記載します。
表 1. WI システムの機能
| WI 機能 | 説明 |
|---|
| authenticateUser | ユーザーのクレデンシャルを認証する |
|---|
| addToGroup | ユーザーをグループのメンバーにする |
|---|
| isGroupMember | ユーザーがグループのメンバーであるかどうかを判別する |
|---|
| removeFromGroup | ユーザーをグループから除去する |
|---|
| createIdMapping | IR ID を別の ID に関連付ける。マイグレーションの支援用 |
|---|
| getIdMapping | IR ID に関連付けられた ID を取得する |
|---|
| removeIdMapping | ID の関連付けを除去する |
|---|
| addToRole | ユーザーに役割を割り当てる |
|---|
| isRoleMember | ユーザーが特定の役割を持っているかどうかを判別する |
|---|
| removeFromRole | ユーザーから役割を除去する |
|---|
| resetPassword | ユーザーのパスワードをリセットする |
|---|
業績
1999 年に初めてデプロイされて以来、WI は、ibm.com アプリケーションで順調に使用されています。既存のアプリケーションの認証機能と登録機能は、WIを使用するように除々に変換されていきましたが、2003 年、WI が正式に IBM 企業の外部認証標準として定義されたのをきっかけに、この移行は加速しました。
WI の使用により、アプリケーション・ユーザーとアプリケーションの開発者および管理者の双方にとって、顧客満足度の向上、そして効率性の改善という結果につながりました。WIシステムを使用する顧客、ビジネス・パートナー、そして開発者によって、その改善は確認されています。
今日、ibm.com ドメイン内の 1000 を超える Web サイトからアクセスする 200 以上のアプリケーションで WI が使用されています。WIシステム内に確立された IBM の顧客、パートナー、そしてサプライヤーの ID は、350 万を超えています。
WI の使用によって削減されたアプリケーション経費は、1999 年の時点から合計すると 4700 万ドルに及ぶと概算されます。この期間中、IBMが WI の開発およびデプロイメントに費やしたのは約 1180 万ドルです。
使用されているベスト・プラクティスと教訓
WI システムの開発とデプロイメントでは、以下をはじめとする重要な教訓を学びました。
- アプリケーションのパフォーマンス評価には概念検証 (PoC) が極めて肝心です。WI チームはこれを認識していたため、PoC を上手く利用してWI 元来のパフォーマンス問題を理解し、解決することができました。PoC を早い段階に行ったことも、WI の初期開発およびデプロイメントに非常に役立ちました。
- アプリケーションの搭載が困難である可能性を認識していた WI チームは、既存のアプリケーションの資金問題への対処をはじめ、効率的な搭載プロセスの定義と文書化に大きな関心を向けました。
- WI の最初のリリース時には、既存のユーザー ID とパスワード・システムがいくつもありました。そこで、アプリケーションとユーザーへの影響を最小限に抑えるため、既存のクレデンシャルをWI にプリロードして、ユーザーが元のクレデンシャルをそのまま変更せずに使えるようにしたわけです。すべてのユーザーに対して可能だったわけではありませんが、多くのユーザーにはシームレスな遷移となりました。
ibm.com Web ドメイン全体で初めて WI が使用されるようになった後、WI は正式な IBM 内部開発標準として確立されました。これは、IBM内での一貫した WI ツール導入に向けた重要なステップでした。今では外部 Web サイトのすべての開発プロジェクトで、外部向け Web サイト・アプリケーションのユーザーID を保証する方法が統一されています。
まとめ
この連載では、6 つの IBM 内部イニシアチブで SOA 対応ソリューションのインプリメンテーションがどのように目的のビジネスおよび ITの変更を可能にしたかを説明しました。6 つすべてのイニシアシブが、一層迅速な新しいビジネス機能の導入と最適化されたビジネス・プロセスにより、今までにないビジネスの敏捷性を実現しています。
6 つの事例研究の説明で焦点としたのは、一般的なビジネス上の課題の特定、そしてその体験から導き出され、現在 IBM および提携しているクライアント全体で再使用されているインプリメンテーション・パターンです。それぞれの事例は、SOA対応ソリューションが組織境界さえも超えて、プロセスおよびビジネス・ルールを一層普及させて、より簡単でコストのかからないものに変えることで、目的とするビジネスの柔軟性を実現できることを実証しています。
謝辞
この記事のために実際の事例研究を報告してくれた下記の同僚たちに、その優れた考察力と貢献を感謝したいと思います。
- Jim Doran (IBM Distinguished Engineer)
- Gordon Greenlee, (Enterprise Directory Lead Architect, IBM)
- Brian Olorie (Lead architect for IIP and IIPx, IBM)
- Doug Gustafson, IIPx Project Manager, IBM
- David J. Foti (CPT Program Manager, IBM)
- Steve Looney (Program Manager, Web Identity, IBM)
- Sue Petroski (Web Identity/Common Profile/Order Status On Line, IBM)
- Terry Escamilla, (IBM CHQ, Enterprise On Demand BT/IT Global IT InfrastructureCoE STSM, Security and Privacy Programs, Office of the CIO InfrastructureArchitect)
また、ここでは紹介しきれませんが、革新的な SOA ソリューションを開発し、その経験と教訓を文書化するのに時間を費やしてくれた IBM の多くの同僚、コンサルタント、アーキテクト、開発マネージャー、そしてプロジェクト・マネージャーにも感謝の言葉を送ります。
参考文献 学ぶために
議論するために
著者について | | | Geoffrey Meissner は、IBM CIO Office のエグゼクティブ IT アーキテクトです。過去 2 年間、SOA+ イニシアチブに取り組んでいる彼は、多くの
IBM 内部アプリケーションで SOA ソリューションを提唱しています。それ以前は、IT アーキテクトとして、企業セキュリティー、IBM Travel、Academy
of Technology をはじめとした多数の内部取引に携わっていました。また、外部顧客を対象としたコール・センター・ソリューションを作成・販売する
Employee Services の開発および販売主任アーキテクトを務めた経験もあります。実際の SOA コミュニティーと Asset Architecture
Board に貢献する彼は、数々の再使用可能アセットの作成者でもあり、IBM シニア認証アーキテクトでもあります。 |
| | | IBM 指折りのエンジニアで、IBM Academy of Technology のメンバーでもある Luba Cherbakov は、IBM CIO Office の主要な技術リーダーです。現在、Web 2.0 技術、増加するサービス可用性、そしてエンタープライズ・データを一つにまとめる CIO Situational Applications Environment Initiative を推進しています。彼女は、サービス指向メソッドとコンポーネント・ベース・メソッドを用いた複合エンタープライズ・アプリケーションのアーキテクチャー、設計、開発における著名な専門家です。また、SOMA (Service-Oriented Modeling and Architecture) メソッド、リファレンス・アーキテクチャー・アセット、Architectural Description Standard、そしてグリッド・コンピューティング・サービス提供の作成者、提唱者、貢献者でもあります。IEEE Computer Society and ACM のメンバーである彼女は、ソフトウェアおよびシステムを専攻し、人工知能とシミュレーションを副専攻としたジョージ・ワシントン大学で、コンピューター・サイエンスの修士号を取得しています。 |
| | | Lance Walker は、IBM CIO Office のシニア・テクニカル・スタッフ・メンバーです。IBM エンタープライズ・アーキテクチャー全体の複数の分野でアプリケーション・アーキテクチャーに取り組んでいます。この記事を作成した時点では、企業の SOA+ イニシアチブの PDTL 兼主任アーキテクトを務め (IBM 内部での SOA 促進の責任者)、IBM 内部の SOA Guidance Council の議長でもありました。それ以前には、Isolation Layer Framework など、複数の CIO アプリケーション・アーキテクチャー・イニシアチブのリーダーを務めた経験もあります。Web Identity (IBM の顧客とビジネス・パートナーのための共通ユーザー ID とパスワードを作成する) での最初の主任アーキテクトとしての職務を始めとするエンタープライズ共通サービスでの経歴が、顧客特有のビジネス・ニーズや IBM 内での SOA インプリメンテーションの制約事項に対する彼の理解力の支えとなっています。専門分野は、SOA、エンタープライズ・アーキテクチャー、Web サービス導入の促進、統合アーキテクチャーです。デンバー州立大学でコンピューター情報システムと電気通信の修士号を取得し、コロラド州立大学で機械工学の修士号を取得しています。また、IBM 認定アーキテクトでもあります。 |
記事の評価
| 
