クラウド・サービスの時代のエンタープライズ・アーキテクチャー

ハイブリッド SaaS (Software as a Service) を使用する

この記事では、エンタープライズ・アーキテクチャー (Enterprise architecture: EA) を使用してパブリック・クラウド・サービスの要件を規定する方法について、ハイブリッド SaaS (Software as a Service) の例を使用して説明します。EA は、クラウドの利用者がクラウド技術によって可能になった新しいビジネス・モデルの活用方法や、自分達が現在利用しているアプリケーションや技術環境に外部サービスを適合させる方法を理解する上で、重要なツールです。IT アーキテクトはこの記事を読むことで、EA の記述方法や IBM Rational System Architect を使用して、ビジネス・ユーザーやその他の利害関係者 (サービス・プロバイダーなど) と効果的なコミュニケーションを行う方法を学ぶことができます。

Fabio Castiglioni, Senior IT Architect, IBM

Fabio Castiglioni photoFabio Castiglioni はイタリアの IBM Sales and Distribution の Executive IT Architect です。彼は開発研究所に 13 年間在籍し、国際的プロジェクトの技術職や管理職をしてきました。1995年、彼はオブジェクト指向技術の研究プロジェクトの Technical Director に指名されました。1998年、彼は大規模な政府プロジェクトに IGS Senior IT Architect として従事しました。彼は IBM アーキテクトのためのコンポーネント・モデリング・クラスの講師の 1 人であり、非機能要件に関する何本かの記事を発表しています。



2012年 10月 25日

はじめに

サービス指向アーキテクチャー (Service-Oriented Architecture: SOA) の効果的な導入を実現するには、優れたエンタープライズ・アーキテクチャー (Enterprise architecture: EA) が重要であるということが言われるようになって長い年月が経ちますが (「参考文献」に挙げた Ibrahim 氏と Long 氏による記事を参照)、SOA を導入した人達の多くは EA に関する「デュー・ディリジェンス」を行わないことによる代償を、プロジェクトの失敗、または半ば失敗という形で払ってきました。確立された EA に伴う要素である、アーキテクチャーの全体像、ビジネス・プロセスと IT サービスとの間のエンド・ツー・エンドのリンク、日常的なガバナンス・メカニズムは、いずれもビジネスや企業を変容できる技術を提供することを約束する SOA にとって不可欠の要素です。

ここまで読んで皆さんが「自分が思っていたのとは違う記事を開いてしまったに違いない。SOA に関する記事ではなくクラウドに関する記事だと思ったのだが」というようなことを思いながらブツブツ言っているのが私にはわかります。

実際には、クラウドについて議論するにせよ SOA について議論するにせよ、私達は「サービス」を扱います。

「サービス」を扱うということは、目の前にある特定の問題を扱うにはおそらく最適とは言えない粒度で IT を構築することを進んで受け入れること、そしてビジネス・オペレーションの再構成を行えるだけの高い柔軟性を持てるように一部のサービス・コンポーネントに対して過剰な設計をすることを進んで受け入れることを意味します。(例えばインターフェースの標準化について考えてみてください。標準化は代償を伴い、実際にインターフェースの機能を再利用しない限り代償の見返りはありません。) このレベルの柔軟性それ自体は、柔軟なビジネス・プロセスを実現するための手段でしかありません。そして、これらの手段が十分な情報に裏付けられた柔軟なビジネス戦略によるものでない限り、意味のある経済的見返りはありません。

クラウド (あるいは SOA) のアーキテクチャーを実装する人達は、目の前にあるこのような原因と結果のつながりを十分明らかにする必要があります。そうでないと、その人達による決定は常に問題に関する重要な側面を見落としたものになってしまいます。

これはつまり、ある分野のエンタープライズ・アーキテクチャー・モデルを変換するということは、ビジネスと IT との関係、依存関係、要件、制約を明らかにするためのデュー・ディリジェンスを実行する、ということを意味します。

この記事では、このエンタープライズ・アーキテクチャー・モデルを表現するための方法や、このモデルを基に何をなぜ行う必要があるかを理解するための方法について、クラウド・サービスのコンシューマーの観点から説明します。この場合のコンシューマーは、クラウド技術を活用してビジネス・オペレーションに新しいレベルの柔軟性を取り入れようとする組織の可能性もあります。


クラウド・サービスのコンシューマーのシナリオ

クラウド・リファレンス・アーキテクチャー (例えば IBM や米商務省 (United States Department of Commerce) の NIST (National Institute of Standards and Technology: 米国国立標準技術研究所) などによるクラウド・リファレンス・アーキテクチャー) は、クラウド・ビジネスの構造を規定します。そのためには、関係する一連のアクターを規定するところから始めます。各アクターにはロールが定義されています。

図 1. IBM のクラウド・リファレンス・アーキテクチャー (NIST のアーキテクチャーと似ています)
IBM のクラウド・リファレンス・アーキテクチャーを説明した図

IBM のリファレンス・アーキテクチャーでは以下のロールを定めています。

  • クラウド・サービス・クリエーター: クラウド・インフラストラクチャーを通じて利用される新しいサービスを作成します。
  • クラウド・サービス・プロバイダー: クラウド・インフラストラクチャーを管理、運営します。
  • クラウド・サービス・コンシューマー: クラウド・インフラストラクチャーでホストされるサービスを利用します。

NIST は以下のロールを挙げています。

  • クラウド・プロバイダー (IBM のものと同様です)
  • クラウド・コンシューマー (IBM のものと同様です)
  • クラウド・オーディター: クラウド・サービスの査定を単独で行うことができます。
  • クラウド・ブローカー: プロバイダーのサービスを仲介したり、作成したり、あるいはサービスに付加価値を追加したりすることができます。
  • クラウド・キャリア: クラウド・サービス・プロバイダーにトランスポート・サービスを提供することができます。

これを見るとわかるように、中心的なロールはプロバイダーとコンシューマーです。プロバイダーのビジネス・モデルと IT モデルは従来のアウトソーサーと非常によく似ていますが、クラウドの革新的な機能を最も活用するのはコンシューマーです。

IBM のクラウド・リファレンス・アーキテクチャーに戻ると、コンシューマーは以下の 4 つのクラスのサービスを選択することができます。

  • インフラストラクチャー・サービス (IaaS (Infrastructure as a Service)): コンシューマーはハードウェア・システムと等価なサービスを使用します。
  • プラットフォーム・サービス (PaaS (Platform as a Service)): サービスはハードウェアとソフトウェアから成る完全なインフラストラクチャーと等価です。
  • ソフトウェア・サービス (SaaS (Software as a Service)): コンシューマーはビジネス・アプリケーションを使用します。
  • サービスとしてのビジネス・プロセス (BPaaS (Business Process as a Service) と呼ばれることもあります): コンシューマーは既にビジネス・プロセスの一部を外部のプロバイダーにアウトソースしています。

プロバイダーとコンシューマーは、同じ企業内でプライベート・クラウドを使用する 2 つの部門 (IT 運用部門と IT 開発部門など) の場合もあれば、2 つの別の企業で構成され、一方がクラウドを通じてサービスを提供するビジネスをしている場合もあります。興味深いのは後者のケースです。後者は単に企業内の一組織のモデルの変更ではなく、企業のビジネス・モデルの変更を伴うからです。

この記事では上記 4 つのクラスのサービスのうち、新しいビジネス機能を取得する特定のケースに焦点を絞り、クラウド・サービス (パブリック SaaS) を通じて提供されるビジネス・アプリケーションを使用する方法について説明します。

ここで最後に触れておくべき点は、クラウド・モデルが「プラットフォーム」となり得ることです。サービスの提供が目的であることは当然ですが、提供されるサービスの品質は、そのプラットフォームで提供される技術サポート機能とビジネス・サポート機能 (IBM のリファレンス・アーキテクチャーでベージュ色に塗られた 2 つのボックス) に依存します。

IBM のクラウド・リファレンス・アーキテクチャーでは以下のサポート・サービスを定めています。

  • サービス・オファリング・カタログおよび管理
  • サービス・リクエスト管理
  • 発注およびサブスクリプション管理
  • 契約およびアグリーメント管理
  • 価格設定、測定、課金
  • 顧客アカウント管理
  • 評価
  • 精算および決済、買掛金勘定、売掛金勘定
  • サービス・デリバリー・カタログ
  • サービス自動化管理
  • 変更および構成管理
  • イメージ・ライフサイクル管理
  • プロビジョニング
  • インシデントおよび問題管理
  • IT サービス・レベル管理
  • モニターおよびイベント管理
  • IT 資産およびライセンス管理
  • キャパシティーおよびパフォーマンス管理
  • プラットフォームおよび仮想化管理

これらのサービスの一部は明らかにプロバイダーのビジネス・プロセスや技術プロセスをサポートするものですが、一部のサービスはコンシューマーの参加を必要とし、実際のところプロバイダーにとっては新しいサービスかもしれません (例えば、サービスの支払いに対する課金や、購入されるサービスの質を外部モニター情報と相関させて制御するなど)。

注:
この記事ではスペースの都合上、これらのサービスについては説明しませんが、クラウド・ベースのサービスを導入する際には、技術的なデュー・ディリジェンスのなかに (EA の) 分析を含めることをお勧めします。


TOGAF フレームワークと ArchiMate モデル

TOGAF (The Open Group Architecture Framework) はエンタープライズ・アーキテクチャーのフレームワークです。1995年に作成された TOGAF Version 1 は、米国防総省 (US Department of Defense) が作成した TAFIM (Technical Architecture Framework for Information Management) をベースとしています。TOGAF の中心となっているのは、エンタープライズ・アーキテクチャーの開発管理を 8+1 フェーズのプロセスで記述する ADM (Architecture Development Method) です。

ADM は、プロセス全体、フェーズ間、フェーズ内、という 3 つのレベルで繰り返しを行います。ADM は汎用的な方法であり、組織の特定のニーズに合わせて調整することができます。例えば ADM を使用する米連邦機関のなかには、部門の特定のニーズに合わせた専用のアーキテクチャーを既に成果物として開発済みのところもあります。

Open Groupの標準である ArchiMate はエンタープライズ・アーキテクチャーのためのオープンで独立したモデリング言語であり、ビジネス、アプリケーション、技術のドメイン間の関係を、曖昧さを排除した方法で記述、分析、視覚化するための手段となります。

建造物を構築する昔ながらの手法において、建築図面が建造物の構造や用途のさまざまな側面を記述するのと同じように、ArchiMate はビジネス・プロセス、組織構造、情報フロー、IT システム、技術インフラストラクチャーの構築と運用を記述するための共通の言語です。このような洞察は、利害関係者が設計や評価を行ったり、これらのビジネス・ドメイン内やビジネス・ドメイン間で行われた決定や変更の結果を伝えたりする上で役に立ちます (原文の出典: The Open Group)。

ArchiMate は以下の 3 つの「コア」レイヤーと 2 つの「拡張機能」で構成されています。

ビジネス・レイヤー
このレイヤーは、組織構造とその組織構造が作成するサービス、ビジネス・ロールとビジネス・プロセス、製品や契約などのビジネス・オブジェクトをモデル化します。
 
アプリケーション・レイヤー
このレイヤーは、アプリケーションのコンポーネントとコンポーネント間の動作、論理データ・エンティティーとエンティティー間の関係、そしてそれらの結果として上位 (ビジネス) レイヤーに提供されるサービスを記述します。
 
技術レイヤー
このレイヤーは、ハードウェア・システムおよびソフトウェア・システムとそれらを接続するネットワークをモデル化し、それらをどのようにして上位 (アプリケーション) レイヤーに提供されるサービスにするのかを示します。

AchiMate 2.0 仕様には上記のコア・レイヤーに以下の 2 つの拡張が追加されています。

動機
動機の概念は、エンタープライズ・アーキテクチャーの構成部分の設計や変更に影響、指針、制約などを与える動機 (つまり理由) をモデル化するために使用されます。
 
実装とマイグレーション
この拡張には、変更プログラムやマイグレーション・プランをモデル化するための概念、またプログラム管理やポートフォリオ管理、プロジェクト管理をサポートするための概念が含まれています。
図 2. ArchiMate による記述の例
ArchiMate モデルを一連のレイヤーとして示す図

適切なアーキテクチャー・モデルと同様に、ArchiMate 仕様はアーキテクチャー・レイヤーの他にビューポイントをサポートしています。ビューポイントはアーキテクチャーの特定の側面に関してやり取りするためのものです。これらの側面は利害関係者の関心事によって決定されます。そのため、特定のビューポイントに何を含め、何を含めるべきでないかは、完全に利害関係者の関心事に依存します。

この記事では、動機のビジネス・モデル、アプリケーション・モデル、技術モデルについて、アーキテクチャーの非機能的ビューポイントを用いて補足します。ここでは Castiglioni 氏と Pedulla 氏による説明 (「参考文献」を参照) と同じように、IBM Rational System Architect 用 Corso ArchiMate 2.0 プラグインを使用します。

EA を使用して企業内にクラウド・サービスを統合する

大雑把に紹介したとはいえ、ArchiMate モデルがサービスとサービスの実現に関するものであることは明らかです。従って、このモデルはクラウド・モデルに非常によく適しています。

アプリケーション・コンポーネントによって実装され、ビジネス・プロセスをサポートするために公開されるアプリケーション・サービスとして SaaS を定義するのは簡単です。

PaaS もそれと同じように、特定のアプリケーションのコンポーネントとデータをサポートする技術サービス (またはサービスの集合) として、簡単にモデル化することができます。

つまり、SaaS に対する機能要件を以下によって記述することができます。

  • 関係する利害関係者の動機
  • SaaS がサポートすべきビジネス・モデル
  • 他のアプリケーションに対して公開される、または他のアプリケーションから公開されるインターフェース
  • クラウド・システムと社内システムとの接続性が必要な場合、コンシューマーの技術レベルに対して要求されるサービス
  • SaaS ソリューションの非機能的側面

サンプル・シナリオ: ある 1 つのプロセスをクラウドへ外部化する

EA モデルを使用して SaaS ソリューションの使い方を規定する方法を十分理解するために、The Open Group の ArchiMate の例を拡張します。ここでは Archinsurance という架空の保険会社を例として使用します。Archinsurance 社ではビジネスの目標を実現する上で既存の CRM アプリケーションが障害になっていることを明らかにしたという前提にします。

すべての利害関係者と動機を共有する

動機モデルには利害関係者の動機と要件が取り込まれます。図 3 のフロー図に示すように、CEO には以下の 2 つの動機があります。

  • 特定の顧客の購入回数を増やす
  • 年末までに収益を上げる

CFO は資金繰りが厳しい期間における、設備投資の ROI を懸念しており、一方 CIO は既存のデータ・センターに利用可能なフロア・スペースがあるかどうかを主に心配しています。セキュリティー部門の担当者は、顧客レコードなどの会社の重要データに盗難または紛失のおそれがあることから、すべてのオフサイト・ソリューションに反対しており、会社のセキュリティー・プラクティスを実行するよう要求しています。

図 3. 新しい CRM に対する動機モデル
各利害関係者には動機と要件があります

CEO、CFO、CIO、そしてセキュリティー部門の要件から、選択肢はクラウド・ソリューションと従来のアウトソーシングのいずれかに思えますが、クラウドの方が多少優勢です。しかしセキュリティー要件を満たすのは難しく、候補となり得るプロバイダーの数はデータ転送中もそれ以外の時もデータの暗号化を提供できるプロバイダーのみに限定されてしまいます。

また、選択される SaaS ソリューションは、不正アクセスからのデータ保護メカニズムやクラウドとデータ・センターとのデータ整合メカニズムを含む必要があるため、「純粋な」クラウド・サービスではありません。つまり、ハイブリッド・ソリューションになります。

ビジネス・モデルから機能要件を明らかにする

先ほど触れたように、この例は新しいアプリケーションが従来のアプリケーションと同じビジネス・モデルとビジネス・プロセスをサポートすることを前提としています。上記で説明した EA によるビジネス・モデルは、何をサポートする必要があるのかを明らかにするための指針となります。

例えば、現状の CRM は顧客管理サービス (Customer administration service) と印刷サービス (Printing service) を提供することによって請求処理 (Handle claim) プロセスをサポートしています。このようにして特定されるサービスは、新しい SaaS ソリューションの機能要件 (例えば「請求に関する印刷物には以下のデータを含む必要がある」など) を規定するベースとなり、非機能要件 (例えば「請求の書式設定と印刷に要する時間は 3 分を超えてはならない」など) を規定するベースにもなります。

図 4. 新しい CRM によって影響されるアプリケーション・サービス
サービスは従来と同じですが、影響を受けます

新しいアプリケーション・モデルを設計する

候補としての SaaS ソリューションはすべての機能要件を満たすことができると満足できたら、次のステップでは、そのソリューションが他のアプリケーション (社内アプリケーションや、場合によってはクラウド内のアプリケーション) とのインターフェース要件を満たせるかどうかを検証する方法を設計します。

図 5. 新しいアプリケーションのポートフォリオ
この例では CRM が外部にあります

この例では、Archinsurance 社のアプリケーションのポートフォリオは図 5 の左側に示す形式から、CRM が企業外部のコンポーネントとなっている右側の形式に変わります。CRM コンポーネントのロールは変わりませんが、このコンポーネントと他のコンポーネント (Customer data access (顧客データ・アクセス) や Policy data management (ポリシー・データ管理) など) とのインターフェースを注意深く検討することが重要です。なぜなら、他のコンポーネントはシグニチャー (交換されるデータ) もプロトコル (データ交換に使用される技術) も変更される可能性があるからです。(ArchiMate での関係の方向が UML モデルでの関係の方向と逆になっていることに注意してください。)

この側面に注目するために、アプリケーション・モデルを書き直してアプリケーションのインターフェースを明確にし、それらのインターフェースを実装する技術コンポーネントも必要に応じて明確にします。これは、図 5 に示した 2 つのインターフェースの場合、SaaS を実装できる技術的な能力があることから、会社のデータに対する Web サービス・インターフェースを提供できる ESB 技術コンポーネントをネットワークのエッジに追加するということになります。ここではセキュアな ESB とセキュアな FTP サービスをエンタープライズ・データ・ウェアハウスに使用し、この会社のセキュリティー管理者が要求する条件を満たすようにします。

Web ポータルとのインターフェースに関しては、実際の要件は、1 つのユーザー ID とパスワードによるスキーマでサポートされる単純な HTTP リダイレクトに対するものであると判断しました。つまりコンタクト・エージェントは 1 つの ID とパスワードのペアを使用して社内システムと新しい CRM アプリケーションにログインします。

このインターフェースは、LDAP のデータとクラウド内の CRM で使用される認証メカニズムのデータとのインターフェースです (この例では LDAP の更新をイベントとして CRM にプッシュします)。CRM データと社内のデータ・マートが協調して新しいデータ・ウェアハウス機能を提供するのと同じように、LDAP の認証と CRM は協調して (新しい) ユーザー認証機能を提供します。

この新しいアプリケーション・モデルを基に、新しい SaaS サービスを既存の社内インフラストラクチャーと組み合わせるために必要な変更を設計することができます。

図 6. 変更されたアプリケーション・モデルを示す図
アプリケーション・モデルが変更されています

非機能的ビューポイントを記述する

最後に、非機能的ビューポイントについて検討する必要があります。

ここでは以下の 2 点に注目する必要があります。

  • SaaS ソリューションはどのような非機能要件 (NonFunctional Requirement: NFR) をサポートする必要があるのか
  • 2 つのシステムを接続するために何をする必要があり、それがどのように社内インフラストラクチャーの NFR に影響するか

実際、この新しいサービスは複雑な一連の NFR を満たす必要があります。それらの NFRの一部はビジネスの要求 (印刷時間など) によるものであり、一部はセキュリティー管理者のような他の利害関係者によるものです。

また、(大量のユーザーが同時にアクセスした場合の応答時間など) いくつかの要件が追加されて組み合わせが複雑になり、新しいサービスの負荷が増大するかもしれません。SaaS ソリューションが受け入れ可能であると宣言する前に、それらの要件について検証する必要があります。

サービス・プロバイダー内部のアーキテクチャーやインフラストラクチャーは (デュー・ディリジェンスを実行する場合を除き) 私達の関心事ではありません。従って、どのような受け入れテストを実行しても構いません。ただしインフラストラクチャーを考慮する必要があります。この記事のスキーマでは、Archinsurance 社の ESB をセキュアに維持する XML ファイアウォールと HTTP/FTP ファイアウォールとを構成する際、Archinsurance 社とサービス・プロバイダーとの間の新しいフローを考慮する必要があります。

図 7. CRM のための SaaS の非機能的ビューポイント
オペレーション・モデルのアプリケーションの側面

まとめ

この記事では、SaaS ソリューションを導入するにあたって、プロバイダーに対する要件を検討する場合にも、新しいサービスに対応するために社内インフラストラクチャーに必要なものを規定し、設計する場合にも、EA モデルが優れた指針となることを示しました。この手法を説明する例として、Rational System Architect の Corso プラグインで使用されている TOGAF の ArchiMate による記述方法を使用しました。


謝辞

この記事を校閲し、助言をくださった IBM の Executive IT Architect、Pietro della Peruta 氏と Francesco Pedulla 氏に感謝いたします。

参考文献

学ぶために

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

  • 無料で完全に機能を使える Rational System Architect試用版をダウンロードしてください。
  • 皆さんに最適な方法で IBM 製品を評価してください。製品の試用版をダウンロードする方法、オンラインで製品を試す方法、クラウド環境で製品を使う方法、あるいは SOA Sandbox で数時間を費やし、サービス指向アーキテクチャーの効率的な実装方法を学ぶ方法などがあります。

議論するために

  • Enterprise Architecture and Business Architecture フォーラムに参加してください。このフォーラムでは、さまざまな方法、フレームワーク、ツールの実装に関する情報を共有することができます。ここで行われている議論には、Rational System Architect のツールに特化した技術的な議論などがあります。
  • Rational ソフトウェアを評価またはレビューしてください。評価やレビューは、短時間で簡単に行えます。
  • developerWorks に記事を寄稿し、Rational ソフトウェアを使用する他の人達に皆さんの知識を広めてください。どのような記事が developerWorks の記事として適切なのか、また執筆するための方法については、こちらを参照してください。
  • FacebookTwitter (@ibmrational)、YouTube で Rational ソフトウェアをフォローし、皆さんのコメントやリクエストを書き込んでください。
  • Rational ForumsRational CafésRational Wiki に参加して質問したり、質問に答えたり、皆さんの専門知識を深めたりしてください。
  • つながりを持ってください。Rational コミュニティーに参加し、Rational ソフトウェアに関する専門知識を共有し、仲間達とつながりを持ってください。

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Rational, Cloud computing
ArticleID=841183
ArticleTitle=クラウド・サービスの時代のエンタープライズ・アーキテクチャー
publish-date=10252012