クラウド コンピューティング: 既に始めた場合に何から始めればよいか

  • [アーティクル]

SOA、SaaS、およびクラウド コンピューティングを取り巻く問題や機会は、事実上、ビジネス スタッフと IT スタッフの間のコミュニケーション格差を増幅します。このようなアーキテクチャやテクノロジの新しさがその理由の一部です。この記事では、こうした新しいモデルがもたらす技術的な機会を組織のニーズに結び付ける方法についてのガイダンスを提供します。

Ric Merrifield および Dennis Stevens

ビジネスの大きな変化を飛行中の飛行機を修理することにたとえるのは、複雑さ、リスク、および混乱の観点からするとなかなか良いたとえで、サービス指向アーキテクチャ (SOA)、サービスとしてのソフトウェア (SaaS)、およびクラウド コンピューティングに関連する機会にさらに焦点を絞っていくと、このたとえはかなり控えめな表現にすら思えてきます。実際、最近のほとんどの組織は、次のように、きわめて重要でありながら矛盾することの多い 2 つの目標の対立を経験しています。

組織が (通常、本業の成長と買収の両方を通じて) 成熟するにつれて、それぞれの部門、課、グループ、および企業は、サイロのように独立性がより強くなります。これにより、顧客、パートナー、および従業員にいろいろなことを説明しようとする際、大量の重複作業が発生し、混乱が激化します。最近のほとんどの組織は、ミッション、顧客への価値ある提案、日常業務の遂行方法などのあらゆることに関して、より統一された作業とメッセージを提供するために、組織全体の透明度を高めようと努めています。

新しいテクノロジは毎日登場しますが、大きな転換はめったにあるものではなく、多くの人は、クラウド コンピューティングがもたらす機会をこうした大きな転換の 1 つと認識しています。そのため、多くの組織が、競争相手より先にクラウド コンピューティングを実現しようと急いでいます。

ご想像のとおり、組織が縦割り型で、さまざまなグループにわたる可視性に欠けている場合、機会の最大化はより複雑になります。まず統一を行ってから、機会の最大化を行いますか。多くの場合、その時間はありません。現時点での正解は、合理的な優先順位付けを念頭に置きつつ、両方の目標を積極的に追求し続けることです。残念ながら、現在、これは言うのは簡単ですが、行うのははるかに困難です。ほとんどの組織には、その組織自身に対する認識 (統一を念頭に置いて効率的かつ客観的に優先順位を付けることを可能にする "レンズ") が欠けています。これにより、機会の最大化の取り組みは最初からほぼ絶望的になります。なぜでしょうか。組織のさまざまなグループ (情報技術 (IT) 部門を含む) にまたがる非常に大きなコミュニケーション格差が存在します。このコミュニケーション格差の中心にあるのは "'方法' の落とし穴" と呼ばれてきたもので、その詳細についてはこの記事の「機能のモデリングとヒート マッピングによって "'方法' の落とし穴" から抜け出す」で説明します。

では、話を SOA、SaaS、およびクラウド コンピューティングに戻しましょう。SOA、SaaS、およびクラウド コンピューティングを取り巻く問題や機会は、事実上、ビジネス スタッフと IT スタッフの間のコミュニケーション格差を増幅します。このようなアーキテクチャやテクノロジの新しさがその理由の一部です。ビジネスは、新しい機能やサービスを新しい顧客と既存の顧客の両方に提供する方法 (重要な新しい収益源となり、さらなる競争力のある差別化をもたらすもの) を探します。一方で、多くのビジネスは、新しい顧客と既存の顧客にセキュリティ、速度、アクセス、パーソナル化などの領域でより多くの選択肢を提供するために、レガシ テクノロジををクラウド サービスに移行することを検討します。ビジネスは、パッケージ化されたソフトウェアや元々カスタムのソフトウェアへの大幅なカスタマイズを含む詳細な "要件" を IT 部門に提示する可能性があります。この記事の本文で説明するように、組織が "'方法' の落とし穴" からまだ抜け出していない場合、IT は一般に、過度にカスタマイズされた必要以上に高価なサービスを作成します。このようなサービスは、こうした新しいモデルの潜在的な収益性を低下させ、最終的に、戦略的な目標を達成するための組織の取り組みを遅らせます。

ですが、組織のニーズと優先順位をより明確かつ客観的に表現する必要があるのと同様に、こうした新しいモデル (SOA、SaaS、およびクラウド コンピューティング) がどのように既存のレガシ IT ソリューションとアーキテクチャを補完するのかについても、より明確に理解する必要があります (飛行中の飛行機を修理するというたとえを思い出してください)。こうした新しいモデルがもたらす技術的な機会を組織のニーズに結び付けることはきわめて重要で、この記事ではその方法についてのガイダンスを提供します。

「機能のモデリングとヒート マッピングによって "'方法' の落とし穴" から抜け出す」では、機能のモデリングとヒート マッピングを通じて "'方法' の落とし穴" から抜け出す方法の詳細について説明します。続いて、「ヒート マップを優先順位付けの議論を行う際の参考情報として使用する方法」では、ビジネス要件およびプロジェクトの優先順位付けにおけるヒート マッピングの役割に関するガイダンスを提供します。「ビジネスにとっての SOA、SaaS、およびクラウド コンピューティングの機会とリスク」では、SOA、SaaS、およびクラウド コンピューティングの意味について説明します。また、これらが IT とビジネスにどのような種類の機会とリスクをもたらすかについても説明します。「クラウド コンピューティングのケース スタディ」では、クラウド コンピューティングのケース スタディを紹介します。このケース スタディでは、ビジネスがホストされたソリューションから得ることを期待できる基本的なメリットを示します。「結論とアドバイス」では、クラウド コンピューティングを単なるテクノロジ ソリューションや技術的な機会と考えてしまうと、ビジネスへの付加価値付けに成功する可能性は低いことを説明しています。ビジネス機能の厳密さと統制を通じて手に入れる、分析の客観性を適用するまでは、組織の戦略や戦術を明示的にテクノロジに結び付けていないというリスクは大幅に増大します。最後に、次のステップに関するいくつかの具体的な見解とこの議論に利用できるリソースを紹介します。

私たちは、この記事が、組織が今までよりもはるかに体系化され客観的で統制のとれた方法で統一と機会の最大化に引き続き力を注ぐのに役立つ明確なガイダンスを第一歩として提供することを信じています。

機能のモデリングとヒート マッピングによって "'方法' の落とし穴" から抜け出す

テクノロジとアーキテクチャのこうした機会について説明する前に、まずは、多くの組織に存在する現実を見てみましょう。多くの企業では、ビジネス側の人間は (テクノロジの詳細に関する知識は毎日増えていくとしても) テクノロジの詳細に関心を持っていないにもかかわらず、特定の戦術につながる特定の戦略を設定し、多くの場合、こうした戦術の実現にはテクノロジが必要となります。しかし、組織の戦術と戦略をサポートするうえでのテクノロジの具体的な役割について議論する場合、ビジネス スタッフは、患者が医者に痛みを説明する場合と同様に、特定の問題や機会に関係があるとは限らない詳細についても説明することがよくあります。医者と患者の関係の場合は、医者は患者が本当に必要としている情報に関係がありそうなことと関係がなさそうなことを区別するのに慣れているので、通常、これは問題になりません。それに対して、ビジネス スタッフと情報技術 (IT) スタッフの会話では、IT スタッフはビジネスの専門家ではないため、関係がない詳細を医者のようにうまくは見分けられないので、多くの場合、ビジネス スタッフの要求に応じて、あまり大きな価値を生み出さない多くのことを実行してしまいます。これは、ビジネス スタッフと IT スタッフの賢明さや頑張りが足りないからではなく、両者が文字どおり、同じ言語を話さないことが多いからです。

方法の落とし穴

このコミュニケーション格差の根底にあるのは "'方法' の落とし穴" と呼ばれてきたもので、これはすべての人に影響を与えます。多くの人は、何かを行う "方法" (FAX を送信するなど) を重視するあまり、作業について説明する際に "何" を行っているのかを説明しないことがよくあります (FAX の送信よりも、何かの状況を伝えることの方が "何" に該当する可能性が高く、FAX は "方法" に該当します)。組織を構成する "何" は、ビジネス機能とも呼ばれます (これについては、私たちが『Harvard Business Review』で Jack Calhoun と共同執筆した「『サービス指向アーキテクチャー』が生み出す『超』リエンジニアリング革命」という論文でより詳細に考察しています)。私たちは、組織のさまざまなビジネス機能を特定することが、組織を構成する作業をはるかに明確でより客観的にとらえるための優れた第一歩であることに気付きました。この特定作業にはあまり時間がかからず、ほとんどの人はこの作業を楽しんで行います。その後、最も価値が高い領域、最も価値が低い領域、成果、および成熟度に関する情報を追加していくと、作業の優先順位付けに関する非常に客観的で効率的な議論につながる場合があります (ビジネス価値が話題となる場合は特にそうです)。これは、ほとんどの組織にお勧めする第一歩です。数か月かかる組織全体のマッピングに着手するのではなく、このアプローチが他の使用できる手法とどのように異なり、他の手法をどのように補完するのかを感じ取るために、課や部門などのより小規模なレベルから始めることをお勧めします。他の使用できる手法には、プロセス リエンジニアリング、リーン、シックス シグマなどがあります。

SOA、SaaS、またはクラウド コンピューティングに関する会話をテクノロジやアーキテクチャの話から始めると、成功の可能性は低くなります。IT とビジネスの両方にとっての重要な第一歩は、"'方法' の落とし穴" から抜け出すことです。さいわい、これにはそれほど時間はかかりません。

ほとんどの人は、車に乗っているときに「どうしてこの道を行くのか」という会話をした経験があるでしょう。これは、時間どおりに目的地に到達するという結果 (目的) をどのような "方法" で達成したかが問題になることなどめったにないにもかかわらず、お気に入りの目的地に到達する "方法" が重視されていることの表れです。これは、このような人が非常識だというわけではなく、人は、実際の目的が "何" であるかがわからなくなってしまうほどに、実際の目的を実行 "方法" で覆い隠してしまうことが多く、それによって、他の実現方法を考えるのが困難になるというだけなのです。

"'方法' の落とし穴" がどこよりもよく見られるのは職場であり、それを示すには例を挙げるのが一番です。組織の特定の部分に関するビジネス要件を収集しようとしているとしましょう。組織について何も知らないので、FAX 機器を使って FAX を送信している人のところに行き、"何" をしているのか質問することにします。返事はおそらく「FAX を送信しています。」というもので、その場合、ほとんどの人は、続いて「FAX の送信はあなたの仕事にとって欠かせない構成要素ですか。仕事を無事に完了するには FAX を送信する必要がありますか。」のような質問をするでしょう。そして、それに対する答えはおそらく「はい」で、質問をした人は "FAX の送信" を要件としてとらえることになるでしょう。

しかし、これは要件ではありません。この場合、要件 ("何" をしているか) に該当するのは "状況を伝える"、"注文を確認する" のようなことで、それを行う "方法" が FAX 機器の使用です。したがって、"方法" から "何" を探り出してから、先ほどの従業員のところに戻り、これを達成する "方法" は重要かどうか質問すると、この従業員は通常、重要でないと気付くでしょう。ここでは、要件についての会話が既に変化しています。組織の要件を構成する "何" はビジネス機能と呼ばれるもので、ビジネス機能をとらえることは、人々を "'方法' の落とし穴" から救い出す効果的かつ効率的な方法であり、ヒート マップと呼ばれる温度図を作成するための重要な第一歩です。

価値と成果のマップ

では、"'方法' の落とし穴" から抜け出すための第一歩として、何をすればよいでしょうか。大規模な組織は何千ものビジネス機能で構成されており、時間の経過と共にこうしたビジネス機能の一覧をより明確にしていく必要がありますが、現時点では、組織は少なくとも次の 2 つのどちらかを特定する必要があります。

**ビジネス価値の最も高いビジネス機能を特定する。**これを行うには、次の 3 つのテストを使用します (3 つとも重要度は同じです)。たとえば、"従業員に賃金を支払う" というビジネス機能は、この 3 つのテストすべてに不合格になります。このビジネス機能は必要であり、無事に実行され遵守される必要がありますが、3 つのテストには不合格になります。

  • そのビジネス機能は、顧客、パートナー、および従業員がその組織と仕事をする理由の面で、組織のブランドや独自性の一因となるか。そのビジネス機能は、当該の組織から連想されるものの 1 つであるか (はい/いいえ、高/中/低、または 1 ～ 5)。
  • その作業の成果は、組織の主要業績評価指標に直接結び付くか (はい/いいえ)。
  • そのビジネス機能の成果を向上させることには価値があるか (はい/いいえ)。

**ビジネス価値の最も低いビジネス機能を特定する。**意外に思われるかもしれませんが、コスト削減、統合、および外部委託の最大の機会の多くはここから生まれます。最初はこれは重要な作業ではなくても、最初にこの特定作業をある程度行っておくことをお勧めします。新しいアプローチや手法を採用する場合は必ず教訓を得ることになり、組織の価値の高い作業領域よりも価値の低い作業領域で教訓を得る方がはるかにリスクが低いからです。

では、作業に注目し、"方法" を表す動詞を作業から取り除きましょう。次の図は、保険の見積もりを作成する必要がある保険会社についての図で、"方法" を表す動詞の特定について説明するのに役立ちます。

図 1 - 方法を表す動詞の特定

余談ですが、左側の "Automate" (自動化する) という動詞が右側の "None" (なし) にマップされていることに注目してください。これは、"自動化する" が "方法" を表す動詞でも "何" を表す動詞でもないからです。これは、"方法" を表す動詞の補助的な説明であり、こうした議論で使用する際は注意が必要です。

次は、ビジネス機能 (保険の見積もりの作成を構成する作業の "何") の概観を図や文書で示します (下図参照)。

図 2 - 見積もりの作成

これだけでは組織内の多くの人をあっと言わせることはできないでしょうが、親である (保険の見積もりの場合は) "Create Quote" (見積もりの作成) を含む各作業ブロックのビジネス価値について質問し、また、各ブロックの成果についても質問すると、各ビジネス機能に色を付けることができます。赤の色調 (ピンクと赤) は注意が必要である (この場合は、価値が高く、成果が低い) ことを表し、緑の色調はその逆 (価値が低く、成果が高い) を表します。

図 3 - 見積もりの作成: ビジネス価値図 4 - 見積もりの作成: 色調表

ここで、会話の客観性と興味深さが大幅に増します。どの "子" ビジネス機能が親の成果向上の原因となるかを客観的に質問することができます。この場合は、子である "Create Certificate" (証明書の作成) が価値が高く成果は最も低いため、親の "塗りつぶし" の色はビジネス価値が中程度であることを表す黄色となっており、親の価値があまり高くないので、この問題は無視してよい可能性があります。ここで、ビジネス機能分析の大きな効果が現れます。これによって、より客観的にビジネスの優先順位付けを行うことが可能になり、クラウド コンピューティングなどの機会の最大化につながります。ですが、話が少し先に進みすぎてしまったようです。

ヒート マップを優先順位付けの議論を行う際の参考情報として使用する方法

飛行中の飛行機を修理するというたとえでは、すべての作業をまだ実行している最中にすべてを一度に修理するのは現実的ではないことが示されています。最高の成果を達成するには、最も重要な問題に的を絞る必要があります。解決策の考案と絞り込みは、問題に優先順位を付けた後で行う必要があります。

「機能のモデリングとヒート マッピングによって "'方法' の落とし穴" から抜け出す」では、機能のモデリングとヒート マッピングを使用して "'方法' の落とし穴" から抜け出す方法について説明しました。ヒート マップでは、"何" を行うかという観点からビジネスが表現され、各ビジネス機能のビジネス価値と成果が示されます。このようなヒート マップを作成する際に重要なのは、ビジネス スタッフと技術スタッフの両方が貢献する必要があるということです。さて、既に会話は始まりました。優先順位付けの議論でどのようにヒート マップを使用すればよいのでしょうか。

優先順位付け

優先順位付けは困難です。ヒート マップは、文字どおり、全体像 (優先順位を決定する際に共有する全体像) を提供します。作業や投資に優先順位を付ける際の考慮事項がいくつかあります。ほとんどの考慮事項は、次の 3 つのカテゴリのいずれかに該当します。

  • 成果を向上させる。
  • コストを削減する。
  • ビジネス リスクに対処する。

まず、ヒート マップでは、成果を向上させるためにはどこに投資すればよいかがどのようにして示されるのでしょうか。親機能を確認し、非常に価値が高いが十分な成果が得られていないビジネス機能を特定します。これは、価値と成果のギャップを示します。このようなところに投資すると、組織の業績が向上します。これには、潜在的な新しいビジネス機能 (クラウド コンピューティングなど) の特定が含まれます。潜在的な新しいビジネス機能となるのは、ヒート マップ上で塗りつぶし (価値) と枠線 (成果) のどちらも赤の色調になっているホットスポットです。たいしたことではありませんが、はっきりさせておくと、実際のところ、どちらが塗りつぶしの色でどちらが枠線の色かは問題ではありません。ですが、この記事内での混乱を避けるため、ここでは一貫性を保っています。ホットスポットは、最も重要な成果ギャップを示します。こうした領域には成果を向上させるための注意と投資が必要で、こうした領域は通常、せいぜい一覧の 10 ～ 20% である必要があります。私たちは、作業の所有者や実行者の話を聞くことにより、非常にすばやく、親ビジネス機能の一覧に客観的に優先順位を付け、重要な少数のビジネス機能だけに絞り込みました。

今度は、要件を絞り込む必要があります。優先順位が付けられた一覧上のそれぞれの "親" ビジネス機能をより詳しく見て、最も注意が必要な (1 つまたは複数の) "子" ビジネス機能を見つけます。簡単に言うと、因果関係 (どの子が親の成果に最も大きな影響を与えるか) を考えるのです。ここでは、成果に重点を置きます。というのも、ほとんどのビジネス機能は次の 3 つのいずれかに分類することができるからです。

  • 付加価値があるビジネス機能
  • 制御用のビジネス機能
  • 補助的なビジネス機能

一般に、付加価値があるビジネス機能のみが価値に直接貢献します (そして、このようなビジネス機能は親の成果の "原因" であることがよくあります)。制御用の機能および補助的な機能は、付加価値があるビジネス機能が高レベルの成果を収めるために必要です。この 3 種類の "子" ビジネス機能のいずれかで成果が低い場合、"親" レベルで成果が低くなる可能性があります。なお、成果の原因を見つけることは重要ですが、ほとんどの組織は (成果の "原因" に関して確実に断言はできない) 仮定のレベルからスタートする必要があります。ですが、私たちの経験では、組織には (このようなレンズによって解き放たれるのを待っている) 非常に多くの優れた知識と経験があるので、最初の仮定は非常に正確な傾向があります。

価値と成果のヒート マップを使用する

ヒート マップからは、コスト削減、統合、および外部委託によって付加価値を付けることができる領域も明らかになります。これを明らかにする最良の方法は、ビジネス価値が最も低いビジネス機能を特定することです。それは、ヒート マップ上で塗りつぶし (価値) の色が緑になっている機能です。このような機能の成果が適切なレベル以下である場合、このような機能は価値が低く、中核的な機能ではないので、組織にとって最も価値のあることに力を注げるように、その機能の実行を得意とする相手 (これをコア コンピテンシーとする相手) にその機能を外部委託することを検討します。このような機能の成果が適切なレベル以上である場合は、効率を高め、コストを削減し、最も重要なことに焦点を絞るように努めます。また、サービスの統合も検討します。"従業員に賃金を支払う" ためのシステムや部門は本当に複数必要なのでしょうか。"'方法' の落とし穴" から抜け出して、目的と結果の観点から "何" を行うのかを説明すれば、その答えははるかにわかりやすくなります。そして、私たちはこの機能を必要ではあるがビジネス価値はあまり高くないと判断したので、実装の詳細はあまり重要ではありません。この機能が (法令遵守を含む) 成果目標を達成する限り、だれが (または何人の人が) それを行うか、それがどこで行われるか、どのようなテクノロジが使用されるか、およびどのようなプロセスで行われるかは、事実上、問題になりません。

ヒート マップは、リスクに対処するためのフレームワークも提供します。詳細については、「ビジネスにとっての SOA、SaaS、およびクラウド コンピューティングの機会とリスク」で説明します。

ここまでのところで、"何" のレンズを使用して組織のニーズを伝え、ヒート マップを使用して問題の優先順位付けと絞り込みを行うためのアプローチを紹介しました。次は、新しい "方法" ("方法" の将来像) を考えます。これには、話し合い、および統制のとれた分析と問題解決が必要となります。これにより、主要な問題に対処し、考案した将来像を実現する構想の一覧ができあがります。この構想一覧には、プロセスの改善、トレーニング、またはテクノロジが含まれる場合があります。次のセクションでは、SOA、クラウド コンピューティング、および SaaS がどのようにして新しいツールを提供し、優れている場合が多い解決策を提供するかを紹介します。

問題と解決策は異なることを理解することが重要です。これは単純なことに聞こえますが、議論しているうちに複雑になることがあります。このセクションでは、トップダウンの分析について説明しました。このセクションで説明した、優先順位を付けた問題一覧は、解決策に優先順位を付ける際の主要な参考情報となります。他の構想が既に機能していたり検討中であったりすることがわかっている場合、これはより重要になります。

どのようにして既存の構想一覧に優先順位を付ければよいのでしょうか。ヒート マップは、問題と解決策を結び付けるのに役立ちます。それぞれの解決策が改善対象としているビジネス機能を特定します。その解決策はホットスポットに対処しますか。これは通常、成果の向上を必要とする領域であることを覚えておいてください。したがって、構想の焦点がコスト削減である場合、より綿密な調査が必要なことがあります。たとえば、コスト削減は良いことですが、そのコスト削減によって提供される価値は、そのための投資およびそれによって生じる混乱に見合うものとなるでしょうか。価値の高いビジネス機能のコストを削減しようとしていませんか。している場合、それは本当に賢明な選択ですか。緑のビジネス機能 (ビジネス価値の面で) に対処する解決策もあるでしょう。ここでは、コスト削減を目的としています。構想の焦点が成果の向上である場合、投資対効果検討書の再検討が必要な可能性があります。本当に 1 日以内ではなく 5 分以内に "従業員に賃金を支払う" 必要はあるのでしょうか。成果を向上させるためには、これより重要な領域が間違いなく存在します。

ヒート マップは、優先順位付けの議論を行ううえでの重要な参考情報を提供します。成果、コスト、またはリスクの問題があるため注意を必要とするビジネス機能を特定し、こうしたビジネス機能に優先順位を付けることができます。さらなるビジネス機能分析により、問題を絞り込むことができます。これで、焦点とする必要がある場所 (およびその必要がない場所) がわかり、優れた解決策を提供するには SOA、SaaS、およびクラウド コンピューティングをどのように使用すればよいかを検討することができるようになります。

要約では、統一と機会の最大化という矛盾する目標について説明しました。私たちの経験では、ヒート マップの使用は、会話をより戦術的なレベルまたは細かいレベルに進めて、統一と機会の最大化との間のトレードオフを (より個別的な検討課題を通じて、または、客観的な視点なしで進む、より主観的な種類の会話を通じてではなく) 明確かつ客観的に評価できるようにするための手段です。

ビジネス戦略を達成するために提供する必要があるものの最小範囲を特定すると、SOA、SaaS、およびクラウドの取り組みでのビジネス利益が大幅に増大する場合があります。

ビジネスにとっての SOA、SaaS、およびクラウド コンピューティングの機会とリスク

まずは、これらの言葉の意味を見てみましょう。SOA (サービス指向アーキテクチャ) はアーキテクチャ スタイルであり、明確なレベルのサービスを提供するように調整された疎結合のブラック ボックス コンポーネントをベースとする、ビジネスと IT についての考え方です。SOA はアーキテクチャであり、テクノロジではありません。さまざまな種類の建材がある建物の構造の要件を満たすことができるのと同様に、さまざまな種類のテクノロジが SOA アーキテクチャをサポートすることができます。

SaaS (サービスとしてのソフトウェア) とは単に、インターネット経由で提供される、ソフトウェア対応のサービスを指します。SaaS は、SOA のアーキテクチャ ビジョンを実現するテクノロジ ソリューションを提供する方法です。通常、SaaS はサブスクリプション ベースで提供される (運用コスト) のに対して、ソフトウェア ライセンスと IT インフラストラクチャには先行資本投資が必要となります。

最も純粋な形のクラウド コンピューティングは、単に、インターネット経由でのコンピューター テクノロジの使用を指します。クラウド コンピューティングを使用すると、ユーザーや開発者は、コンピューティング リソース用の IT インフラストラクチャに関する知識を持たず、コンピューティング リソース用の IT インフラストラクチャを制御できなくても、コンピューティング リソースを利用することができます。リソースは仮想化され、インターネット経由で提供されます。

ベンダーは、ソフトウェアがサービスとして使用されるこのモデルを多くの異なる方法で顧客に提供することができます (ベンダー自身の社内 IT 環境、仮想化されホストされた環境、クラウド環境など)。SaaS はクラウド経由で提供されなければ SaaS と見なされないわけではありません (ただし、クラウドを使用すると、IT インフラストラクチャの構築と保守ではなく、アプリケーションにビジネス価値を組み込むことに焦点を絞ることができるため、クラウドの使用は多くの SaaS ベンダーにとって、ビジネス上、理にかなっています)。

SOA、SaaS、およびクラウド コンピューティングのメリット

SOA、SaaS、およびクラウド コンピューティングを使用すると、IT グループは次の 4 つの方法でビジネスをサポートすることができます。

  1. 効率を高め焦点の絞り込みを促進する- SOA は、テクノロジの実装についてビジネスとほぼ同じレベルで考えて議論できる最初の機会です。ビジネスが必要としているものを定量化および測定が可能な単位でより正確に理解し構築すると、収益性の高いサービス提供につながります。SaaS とクラウド コンピューティングを通じて SOA ベースでサービスを提供すると、組織は最も重要なことに焦点を絞ることができ、IT 管理者はサービスと価値を効率的に (組織内外の) 顧客に提供することができます。ほとんどの組織は独自のテクノロジ インフラストラクチャの構築と管理にかなりのリソースを費やしますが、クラウド コンピューティングを活用する組織は、貴重な資金的リソース、開発リソース、および IT リソースをテクノロジ インフラストラクチャの展開、管理、およびスケール変更に集中的に費やす必要はありません。
  2. アジリティを向上させる - 効果的に設計および実装されたサービスは、高いレベルの相互運用性を持ちます。つまり、こうしたサービスを他のサービスと組み合わせて新しいサービスを提供することができるということです。外部のプロバイダーが提供する既存のサービスを統合するか、以前は分離されていたプラットフォームを 1 つにまとめることによって、新しいソリューションを提供することができます。従来は分離されていたプラットフォームを統合し、既存のサービスを活用する新しいサービスを構成することができると、IT 管理者や開発チームは、ビジネス ニーズや顧客のニーズの変化にすばやく対応することができます。これにより、アイデアをより迅速に商品化することができるようになります。トラフィックや導入の需要増加に応じて、単純な要求でインフラストラクチャをすばやく割り当てることができます。これにより、複雑な運用手順なしでシームレスにスケール変更を行うことが可能になります。また、サービスを停止させずにアップグレードすることも可能になります。これは、ハードウェア インフラストラクチャ、ソフトウェア インフラストラクチャ、ネットワーク インフラストラクチャ、およびストレージ インフラストラクチャの入手、インストール、テスト、および提供を必要とする従来の設置型ソリューションよりもはるかにスケーラブルです。
  3. パフォーマンスと可用性を向上させる - 本当のクラウド プラットフォームは、組織がその組織自身のリソースで無理なく実現できるレベルをはるかに超えたスケーラビリティ、パフォーマンス、可用性、冗長性、ベスト プラクティス、およびセキュリティを実現する地理的に分散した世界中のデータ センター、リソース、およびプラットフォームを提供します。クラウドを使用するとビジネスは最も重要なことに焦点を絞ることができるのと同様に、クラウド コンピューティング プロバイダーは、個々の企業では提供できない最善の組み合わせのサービス管理と高可用性ソリューションを提供することができます。
  4. 組織が柔軟性と制御のバランスをとるのを手助けする - クラウド プラットフォームは、組織がアプリケーションにとって最善の展開モデル (組織自身のサーバーでホストされるか、クラウド プロバイダーによってホストされるか、この 2 つの併用か) を選択することを可能にし、開発者やサービス管理者がビジネスの問題を解決するために設置型リソースとクラウド リソースを組み合わせることができるようにする必要があります。

こうしたテクノロジ上のメリットは、ビジネスに新しい機会を提供します。第 1 に、企業は、レガシ システムの統合を通じたサービスの改善や拡張により収益を保護および増加することを計画する可能性があります。たとえば、ある金融サービス会社は、最善の組み合わせのソリューションから成る、市場では入手できない統合ソリューションを提供できるため、新たな顧客を獲得することができました。この会社は、完全に新しいシステムを作成するのではなく、SaaS の実装を通じて既存のアプリケーションを統合することによって、これを実現します。第 2 に、企業は、パートナーシップと相互運用性を通じて目的のサービスをまとめたり新しいサービスをすばやく追加したりすることによって、ビジネス アジリティを向上させることができます。第 3 に、企業は、比較的高価な機能や環境をクラウドに移行したり、企業内での機能の重複実装をなくしたりすることで、段階的に IT コストを削減することができます。

SOA、SaaS、およびクラウド コンピューティングのリスク

新しいテクノロジやアーキテクチャ アプローチは、新しい機会をもたらすだけでなく、サービスの効果的な設計、構築、および提供にかかわるリスクももたらします。

  1. ビジネス リスク – 統一と機会の最大化との対立は、サービス活動の境界と焦点を効果的に特定することの重要性を浮き彫りにします。入手または開発された各サービスの特定のビジネス メリットに的を絞らなかったことにより、期待されるビジネス メリットが提供されず、コストが増大することがあります。たとえば、十分な成果が得られていない機能があったり、新しいサービスによって大幅なコスト削減が実現されたりしない限り、幅広い人材管理機能を提供する SaaS ソリューションの構築や入手は有益ではないでしょう。このソリューションが収益の保護および増加、ビジネス アジリティの向上、または IT コストの削減に役立たない場合、これはビジネスが焦点とするのにふさわしい領域ではない可能性があります。ヒート マップは、組織がビジネス リスクを軽減するための、実績のある方法を提供します。
  2. 設計リスク – 明確なレベルのサービスを提供するように調整された疎結合のブラック ボックス コンポーネントをベースとして提供されないサービスを設計すると、ビジネスが実現できる最終的なメリットが制限されます。ビジネス モデルと合致しないサービスを構築すると、IT とビジネスの連携が制限されます。相互運用性、自律性、疎結合、および構成可能性をサポートする設計原則に従わないと、サービスのアジリティ、可用性、およびパフォーマンスの潜在性が制限されます。ビジネス機能が他のビジネス機能とどれほど緊密に相互結合されているか考えてみてください。ビジネス レベルまたはテクノロジ実装レベルの相互結合性のレベルが高ければ高いほど、自律サービスを作成するのは難しくなります。また、ビジネス機能をサービスとして公開することに関する重要な法令遵守要件が存在するかどうかも理解する必要があります。たとえば、PCI データにアクセスするサービスはプライバシー法の遵守レベルを向上させるように設計される可能性がありますが、これが考慮されていない場合、こうしたサービスを公開するのは問題となる可能性があります。ヒート マップ作成の一環として、機能に伴うビジネス リスクとテクノロジ リスクを評価する必要があります。
  3. 開発リスク - サービスを適切に構築するには、新しいスキルや開発プロセスが必要となります。SOA、SaaS、およびクラウド コンピューティングのビジネス メリットとテクノロジ メリットを得るには、開発チームは、分析、設計、および開発の適切なスキルを持っている必要があります。理解する必要のある新しいツールと新しい展開パターン、および軽減する必要のある新しい実装リスクが存在します。適切なコンピテンシーやインフラストラクチャを構築するために、適切なトレーニング、環境、およびパートナーシップを早期に構築することは、開発リスクを軽減するために必要です。
  4. 提供リスク - SaaS とクラウド コンピューティングを実装するには、インフラストラクチャ、新しいテクノロジ プロセス、および新しい開発手法への多大な投資が必要です。クラウド コンピューティングを活用すると、初期コストが大幅に削減されると同時に、関連するリスクも軽減されます。

クラウド コンピューティングのケース スタディ

ここまでのところで、ビジネス機能のモデリングとヒート マッピングについて説明し、統一と機会の最大化の両方に関連する決断に優先順位を付ける際にこの 2 つがどのように役立つかについても説明したので、今度は、「ビジネスにとっての SOA、SaaS、およびクラウド コンピューティングの機会とリスク」で説明した内容に沿ってクラウド コンピューティング戦略のメリットのいくつかを実現した実在の企業の詳細の一部を見ていきます。

このケース スタディでは、インドを拠点とし、何千人もの従業員を抱える実在の企業の事例を紹介します。この企業は、顧客である企業や公的部門のサービス強化を支援するソフトウェア開発サービスを提供しています。この記事ではこの企業を Contoso と呼びますが、この企業やここに出てくる人物の実際の名前を知ることが重要になった場合は、ご連絡いただければ、この企業やその人物に連絡を取り、実際の名前を伝えてよいか確認いたします。

事例の概要

この事例では、Contoso は、Microsoft Windows Azure™ Platform を使用して、マイクロソフトのデータ センターを通じてインターネットでアプリケーションを提供することにしました。クラウド コンピューティング ソリューションとして使用できるテクノロジは他にもありますが、他のソリューションを使用した場合に、Contoso がこの状況で収めたのと同じ成功がもたらされたかどうかは定かではないことをここで述べておきます。

メリット

  • アプリケーション展開の簡略化
  • 柔軟でコスト効率のよいスケーラビリティ
  • コスト削減
  • 迅速で低コストの開発
  • 強化された業界固有の (この場合は行政) サービス

状況

インドのプネに本部を置き、アジア、ヨーロッパ、および北米で事業を展開する Contoso Systems は、電気通信、ライフ サイエンス、データ インフラストラクチャ、および行政の領域のさまざまな顧客にソフトウェア製品開発サービスを提供します。6,000 人を超える従業員を抱える Contoso Systems は、全体的なコストを削減しつつ顧客のサービス強化を支援するサービスを提供します。

Contoso Systems の主要なサービスの 1 つは、電子政府ソリューションです。このソリューションを使用すると、地方自治体や地方の政府機関は、Web ベースの 4 つのアプリケーションのセット (Contoso Systems はこれを電子政府スイートと呼んでいます) を通じて電子的にサービスを提供し住民や企業とやり取りすることができます。このスイートは、まとまりのある公共サービス ソリューションとなっており、これには、苦情処理、道路とインフラ、国勢調査、および選挙管理のシステムが含まれています。

苦情処理システムを使用すると、住民は、任意の政府部門に対する事象レポートを登録および追跡することができます。道路とインフラのアプリケーションを使用すると、住民は、オンライン地図ツールで具体的な場所を特定して、道路とインフラに関する問題を報告することができます。登録された病院、医師、および他の承認されたスタッフは、国勢調査部門アプリケーションを使用して誕生と死亡を記録することができます。選挙事務所アプリケーションは国勢調査部門アプリケーションと連携して、最新の有権者リストを維持し、行政機関が選挙を管理および計画するのに役立ちます。

Contoso Systems は、Microsoft® ASP.NET と Microsoft SQL Server® データベース管理ソフトウェアを使用して電子政府スイートを開発し、個々のコンポーネントを顧客自身のデータ センターでホストされたクライアント ベースのソフトウェア アプリケーションとして提供しました。しかし、Contoso Systems は、電子政府ソリューションの販売促進が地方自治体の技術的能力によって制限されることが多いことに気付きました。

インドでは、多くの地方自治体は、Contoso Systems の電子政府アプリケーションを設置型のソフトウェア ソリューションとして完全に展開するのに必要な IT インフラストラクチャを持っていません。高パフォーマンスのサーバー環境を構築するために使用できる資金を持っている自治体や政府機関でも、追加のコストを生じさせる可能性のある、ネットワーク、冗長性などのインフラストラクチャに関する問題を適切に処理するための技術的知識は持っていない場合があります。さらに、自治体や政府機関のスタッフは、技術的能力や技術的知識を必要とはしておらず、行政サービスの提供に焦点を絞りたいと考えている場合があります。

Contoso Systems は、電子政府ソリューションを使用すればこうした自治体のサービス提供能力が向上すると確信していました。Contoso Systems は、新しい IT インフラストラクチャやスタッフへの多大な投資を要求せずに電子政府スイートを地方自治体に提供できる必要がありました。Contoso Systems は、コンポーネント アプリケーション、処理能力、またはデータ ストレージを必要に応じてすばやく、簡単に、コスト効率よく追加または削除してソリューションをスケール変更する方法を顧客に提供したいと考えました。

Contoso Systems は、まだ高パフォーマンスのインフラストラクチャを持っていない潜在顧客に、電子政府ソリューションをテストする方法を提供したいと考えました。また、顧客がこのソリューションを使用したときに使用した分に見合うだけの料金を支払えるようにしたいとも考えました。一方で、Contoso Systems は既に電子政府スイートの開発に多大な投資を行っていたので、ソリューションを大幅にリエンジニアリングすることなく効率的に作成できる新しい提供モデルを必要としていました。

ソリューション

Contoso Systems は、データ センターを通じてインターネットで電子政府スイートをホストするソリューションを開発することにしました。このようなアプリケーション提供システムは、"クラウド" コンピューティングと呼ばれることがあります。Contoso Systems は、Windows Azure™ Platform (マイクロソフトのデータ センターでホストされるインターネット規模のクラウド サービス プラットフォーム) を選びました。Windows Azure Platform の信頼できる高い可用性とスケーラビリティが使用上のニーズに合うと判断したためです。

Contoso Systems は、Windows Azure クラウド サービス オペレーティング システム (Windows Azure Platform 用の開発、サービス ホスティング、およびサービス管理の環境) を使用して Web アプリケーションにオンデマンドの処理能力とストレージ容量を提供します。Windows Azure クラウド サービス オペレーティング システムでは、Microsoft SQL Azure™ データベースをサービスとして使用してアプリケーション データを保存および管理します。また、アプリケーション ユーザーは Windows Azure Platform の BLOB ストレージ機能を使用してファイルや画像を保存することができます。アプリケーション ユーザーは、Live サービスを利用すると、Bing™ を使用して情報を検索し、Bing Maps for Enterprise で場所を特定することができます。

Contoso Systems は、電子政府スイートの 4 つのコア コンポーネントの他に、独自のテナント提供システム (TPS) も Windows Azure 環境に展開します。Contoso Systems は、TPS を使用して、特定のコンポーネントを個々の顧客 (またはテナント アプリケーション) に提供します。Contoso Systems は、各テナント アプリケーションを個々の Windows Azure プロジェクト アカウントに展開します。これにより、各テナント アプリケーションは他のテナント アプリケーションから自動的に分離され、各テナントのセキュリティとスケーラビリティが向上します。

電子政府ソリューションが Windows Azure Platform に展開されたので、地方自治体は、設置型のインフラストラクチャに先行投資するのではなく、月々のサブスクリプションの形で必要なアプリケーションの分だけ料金を支払うことができるようになります。Contoso Systems は TPS を使用して個々のサブスクリプション会員に対する監査と請求書作成を管理し、顧客はサブスクリプションに変更を加えたい場合、システム管理者にフィードバックを提供することができます。「顧客の立場からすると、柔軟性が大幅に向上しています。」と Contoso Systems のシニア プロジェクト マネージャーは言います。「顧客は、利用中に、簡単に追加のアプリケーションを購入したり、不要なアプリケーションを解約したりすることができます。」

Contoso Systems は、電子政府アプリケーション データベースと構成データベースの保存に SQL Azure を使用します。ログインの詳細とユーザーによってアップロードされた添付ファイルは、Windows Azure ストレージ テーブルと BLOB ストレージ機能を使用して保存されます。システムは、Windows Azure のサービス バス機能を使用して、電子政府スイート内のアプリケーションを結び付け、アプリケーション間でデータを共有します。

Contoso Systems は ASP.NET と SQL Server を使用して最初の電子政府ソリューションを開発したので、Contoso Systems の開発者は、最小限の努力で電子政府スイートを Windows Azure Platform に移行することができました。たとえば、開発者は、SQL スクリプトを使用して既存の SQL Server スキーマを SQL Azure データベースに移行しました。「従来の設置型の SQL Server ソフトウェアを使用していたので、既存のアプリケーションを SQL Azure に移行する時間をかなり節約することができました。」と Contoso Systems のテクニカル リードは言います。「学習にかかる期間を最小限に抑え、移行全体を非常に円滑にすることができました。」

Windows Azure Patform を使用することで、Contoso Systems は、自社と顧客の両方の資本支出を削減しながら、電子政府アプリケーションを地方自治体に提供することができます。自治体は、電子政府アプリケーションをすばやくテストおよび展開し、必要に応じてスケール変更し、必要なときに必要な分に見合うだけの料金を支払うことができます。開発が容易だったため、Contoso Systems は、新しいソリューション提供モデルをすばやく市場に出すことができました。そして、電子政府アプリケーションをより多くの顧客に提供することができるようになりました。

Azure のメリット: アプリケーション展開の簡略化

マイクロソフトのデータ センターを通じてインターネットでソリューションをホストすることにより、Contoso Systems は独自のサーバー インフラストラクチャを持たない顧客に電子政府スイートを展開することができます。また、Contoso Systems は、独自のインフラストラクチャを構築することなく、ホストされたソリューションを提供することができます。見込み顧客はアプリケーションを組織内に展開せずにソリューションを評価することができ、Contoso Systems は、新しいシステムを使用すると、新しい顧客にアプリケーションを提供するのにかかる期間を約 50% 短縮することができます。

「Windows Azure を使用すると、オーバーヘッドを大幅に削減しながら、非常に簡単にアプリケーションを新しい顧客に展開することができます。」とシニア プロジェクト マネージャーは言います。「試験運用は非常に簡単です。顧客は、試用ユーザーとして 1 か月間申し込めばいいだけです。」

Azure のメリット: 柔軟でコスト効率のよいスケーラビリティ

マイクロソフトのデータ センターは高い可用性とスケーラビリティを提供するので、Contoso Systems は、顧客のニーズに応じて電子政府ソリューションのコンポーネントを追加または削除して、構成を顧客用にすばやく簡単にアップグレードすることができます。また、Windows Azure Platform を通じて提供される強力な処理能力により、顧客は多大な資本投資を行うことなくさまざまな負荷を処理することができます。

顧客は、ピーク時の負荷に合わせてサーバー容量への投資を行い、他の期間中はその容量を十分に活用しないのではなく、必要なときに必要な容量の分だけ料金を支払うことができます。「たとえば、選挙が近づいている場合、顧客の選挙事務所アプリケーションのインスタンスを追加し、より大きな処理能力を提供することができます。そして、顧客はその期間中だけこの追加の分を支払えばよいのです。」と Contoso の別の従業員は言います。

Azure のメリット: コスト削減

Contoso Systems の電子政府ソリューションを申し込んだ自治体は、資本投資を最小限に抑え、インフラストラクチャの保守にかかるオーバーヘッドをなくして運用コストを削減し、使用したときに使用した分に見合うだけの料金を支払うことにより、より効果的にコストを管理することができます。

顧客は、電子政府スイートの特定の機能の組み合わせのために、資本コストに 24,000 米ドルを費やし、年間の保守オーバーヘッドに 60,000 ドルも費やさなければならない可能性があります。Azure を使用すると、顧客は、資本支出や保守費用を完全になしで済ませ、サービス量のみを支払うことができます。サービス量は 1 年で 10,000 米ドルもかからない可能性があります。

「Windows Azure を使用すると、顧客はインフラストラクチャやホスティング サービスに先行投資しなくて済みます。」とシニア プロジェクト マネージャーは言います。「また、顧客は使った分に応じて支払いを行うことができるので、予算編成がはるかに簡単になります。」

Contoso Systems は、ソリューションを Windows Azure Platform 上で提供および管理できるので、より多くの顧客に電子政府スイートを提供するにつれて、収益性を高め、コストを 70% も削減することができます。「Windows Azure Platform を通じて電子政府ソリューションを提供することで、より多くの顧客とより多くの取引を結べるようになります。」とシニア プロジェクト マネージャーは言います。「また、このプラットフォームを通じて顧客の追加と管理および顧客への請求を行うと、効率が高まり、コストが削減されます。」

Azure のメリット: 迅速で低コストの開発

Contoso Systems の開発者は、既存のスキルを利用できたので、Windows Azure Platform の使い方を学習するのにあまり時間がかかりませんでした。そのため、Windows Azure を使用して電子政府ソリューションを展開するのにかかる時間が短縮されました。また、開発者は、展開をサポートするインフラストラクチャを構成する必要がなかったので、アプリケーションのビジネス ロジックと設計に焦点を絞ることができました。「Windows Azure がなければ、プロセスの開発に費やす時間が 25% 長くなっていたでしょう。」とシニア プロジェクト マネージャーは言います。

まとめ

Contoso Systems の電子政府ソリューションを申し込むと、インドや他の国の地方自治体は、より効率的に行政サービスを提供し、有権者とやり取りすることができます。このソリューションを使用すると、便利な方法でサービスにアクセスすることができ、住民に有益な情報が提供され、自治体の透明度が高まり説明責任が強化されます。その一方で、コストが削減され、運用が簡略化され、効率が高まります。

結論とアドバイス

Contoso は、クラウド サービスによって (この場合はマイクロソフト テクノロジを使用して) アプリケーション展開の簡略化、柔軟でコスト効率のよいスケーラビリティ、コスト削減、および焦点を絞った開発を実現した組織の良い例です。この例で示したように、SOA、SaaS、およびクラウド コンピューティングは、ビジネスにとっての新しい機会を生み出す可能性のある新しい技術的機会をもたらします。こうした新しい技術的機会に伴って新しいビジネス リスクと技術的リスクがもたらされ、技術的機会とビジネス上の機会を実現するにはこうしたリスクに対処する必要があります。

私たちが 6 年以上にわたる研究によって実証したように、(ビジネス機能分析、ヒート マッピング、および優先順位付けを通じた) ビジネス ニーズの分析は、技術アーキテクチャ レベルで IT の会話に関与します。私たちは、『Harvard Business Review』の 2008 年 9 月号で共同執筆した論文「『サービス指向アーキテクチャー』が生み出す『超』リエンジニアリング革命」で、"作業のヒート マップを用意できれば、管理者は、新しい運用モデルの設計に必要な情報の多くまたはほとんどを手に入れることになります。" というふうにこれを指摘しました。

これまでに説明したように、クラウド コンピューティングは、速度、コスト、およびスケーラビリティの点で新しいメリットを提供しました。ビジネス機能のモデリングは、テクノロジをビジネスの戦略的方向性と合わせるのに役立ちました。クラウド コンピューティングとビジネス機能のモデリングを組み合わせることで、SOA と SaaS に移行する組織は、投資収益率および価値を生み出すのにかかる時間を最適化することができます。したがって、次のステップに関する具体的なアドバイスは、実際のところ、次のような 2 つの非常に並列的な道筋で構成されています。

ビジネス機能分析を開始する

これは、ヒート マップを用意し、統一と機会の最大化に関する議論を促進するための第一歩です。組織では既にプロセス リエンジニアリング、シックス シグマ、リーンなどの補完的な手法を使用している可能性が非常に高いので、これがこうした他の手法とどのように異なり、他の手法をどのように補完するのかを理解できるように、小さな限られた領域でビジネス機能の使用を開始することをお勧めします。これを行う際に役立つリソースは『Harvard Business Review』に掲載されている私たちの論文や『Rethink』という書籍の他にもあるので、ご意見やご質問がある場合はご連絡ください。

テクノロジ ロードマップを定義する

現在の技術アーキテクチャがどのようなもので、明確なサービス定義を持つのはそのうちどのくらいであるかについて、明確に理解します。その後、既存のレガシ ソリューションを (必要に応じて) 補完する一方で、組織の目標や顧客のニーズに最も合った方法で組織でのクラウド コンピューティングの導入をサポートする、さまざまなテクノロジについて見ていきます。技術アーキテクチャやクラウド コンピューティングについてご質問がある場合は、お知らせください。

ロードマップを管理する

飛行中の飛行機を修理するというたとえの締めくくりになりますが、適切な道具があるとしても、飛行中に飛行機を修理する方法を非常に明確に理解している必要があります。移行を進めていく中で、ビジネス価値をもたらすために SOA、SaaS、およびクラウド コンピューティングを活用するさまざまな方法が明らかになり、状況固有のさまざまなリスクを特定することになり、価値と成果のギャップが変化します。価値と成果のヒート マップは最新の状態に保つのが非常に簡単で、最新の状態に保つようにすると、ビジネスにとって重要なものおよびその理由を明確に理解し続けるのに役立ちます。SOA、SaaS、およびクラウド コンピューティングは適切なツールであり、機能分析を行うと、作業に関連する価値とリスクを明らかにするために使用できる明確なマップが提供されます。

 

Ric Merrifield

Ric Merrifield は、ワシントン州レドモンドの Microsoft Corporation でビジネス アーキテクチャの取り組みのリーダーを務めており、2008 年 9 月号の『Harvard Business Review』に掲載された「『サービス指向アーキテクチャー』が生み出す『超』リエンジニアリング革命」の共同執筆者の 1 人です。Merrifield は、『Rethink – a Business Manifesto for Cutting Costs and Boosting Innovation』(FT Press、2009 年) の著者でもあります。

Dennis Stevens はジョージア州ノークロスを拠点とするコンサルティング会社 Synaptus の CEO であり、2008 年 6 月号の『Harvard Business Review』に掲載された「『サービス指向アーキテクチャー』が生み出す『超』リエンジニアリング革命」の共同執筆者の 1 人です。Stevens は、Cutter Consortium の 7 月のレポート「Rethinking the Agile Enterprise (アジャイル企業を再検討する、英語)」の共同執筆者の 1 人でもあり、現在、『Value Driven Agile Adoption: Scaling Agility to the Enterprise』(Addison-Wesley、2010 年末までに発売予定) を執筆中です。