段階的実装計画の作成

同じ導入フェーズでクラスタ化できるアプリケーションのグループを特定するには、アプリケーションごとに、ビジネス価値に対するクラウド・レディネスをプロットした4象限チャートを作成します。

次に、チャートの例を示します:

クラウド・レディネスは、アプリケーションをクラウドに移行する準備がどの程度できているかを表します。次に例を示します:

• コスト

• リスク

• 変更

• 技術的な制約

クラウド・レディネスが高いアプリケーションは、リプラットフォームやリホストが容易なアプリケーション、またはレディネスが低い他のアプリケーションに依存していないアプリケーションです。クラウド・レディネスが低いアプリケーションでは、多くのリファクタリングが必要であったり、他のアプリケーションとの重要な依存関係があるために、移行前にそれをリライトする必要があることがあります。

ビジネス価値は目標を表します。次に例を示します:

• 自動化

• アジリティ

• イノベーション

• ビジネス継続性

ビジネス価値は、アプリケーションがビジネスにおいて果たす役割、またはアプリケーションのクラウドへの移行に関連する戦略的優先度を分類するのに役立ちます。アプリケーションのビジネス価値は、そのアーキテクチャとは無関係です。

各アプリケーションをチャートの象限に配置します。適切な位置を決定するには、既存のアーキテクチャおよび将来のアーキテクチャの候補に対して先に実行した属性分析を使用します。同じフェーズで移行する予定のアプリケーションは、比較的適切にクラスタ化されている必要があります。クラウド・レディネスを優先している場合は、1つのフェーズ内のアプリケーションが価値スペクトラムに及ぶことがあります。同様に、ビジネス価値を重視している場合は、アプリケーションがレディネス・スペクトラムに及ぶことがあります。ただし、フェーズが2つ以上の象限にまたがっている場合は、特にクラウド導入のコンテキストにおいては、変更のリスクと範囲を再評価することをお薦めします。ただし、複数のパラレルなプロジェクトや比較的独立したプロジェクトを評価する場合は例外で、各プロジェクトのチャートを個別に確認する必要があります。

クリティカルなレガシー・アプリケーションが多数存在し、それらのアプリケーションをリライトするという時間のかかる作業を前提とせずにクラウドに移行したい場合、左上にある(レガシーの制約によりレディネスは低いがビジネス価値は高い)アプリケーションを開始点とすることをお薦めします。組織がリスク回避型の場合は、右下の象限(レディネスが高く、価値が低い)のアプリケーションを開始点とする方法もお薦めです。クラウドに移行する準備ができており、失敗しても組織に与える影響が少ないためです。組織が最初のパイロット・プロジェクトに注力したい場合や、プラットフォームを学習する機会が必要な場合は、レディネスが高い象限のいずれを開始点とすることをお薦めします。

大企業の場合は、比較的依存性の低いアプリケーションを保有しているために、様々な事業分野にわたるクラウド導入に異なる並列アプローチを採用するように選択できることもあります。

クラウド実装計画の作成は、反復的なプロセスです。アプリケーションをフェーズに分類し、アプリケーションをビジネスの優先事項にマップし、導入のフェーズを計画し、ビジネスの利害関係者との話し合いを重ねながら、日付、範囲、順序について適宜妥協点を見つけます。

まず、一緒に解決する必要があるアプリケーションのグループを特定します。次に、異なる順序決定をした場合の影響を確認します。組織のビジネス上の優先事項と制約をこの分析で考慮する必要があります。アプリケーションのグループ化および導入フェーズの計画においては、多くの場合、次の属性が最も強力な役割を果たします:

• データの重力: クラウドとオンプレミスに分割できず、一緒に解決する必要があるアプリケーションのグループはありますか。廃止するアプリケーションとリホストするアプリケーションが混在するシナリオを組み込みます。

• 変更の範囲: 変更管理を容易にするために、大きなアプリケーション・グループを小さなグループに分類する必要がある場合があります。変更管理では、テクノロジ・コンポーネントの数と同じくらい、人やスキルが重要になります。大きなアプリケーション・グループをリホストするほうが、小さなアプリケーション・グループをリファクタリングおよびリプラットフォームするよりも変更の範囲が小さくなる可能性があります。

• リスク許容度: ミッションクリティカルなプロセスでアプリケーションが果たす役割によって、プロジェクトの不確実性とリスクはどのように増幅または減衰しますか。

• コンペリング・イベント: ソフトウェア・サポートやハードウェアの更新、特定の決定を動機付ける不動産や建物の閉鎖など、ライフサイクルが終了したテクノロジ・ドライバはありますか。

現在のアーキテクチャと計画アーキテクチャを分析したときに、多くの属性を評価しました。導入のフェーズを計画する際には、集計ビューまたは概要ビューも使用します。前にリストした属性(データの重力、変更のスコープ、リスク許容度およびコンペリング・イベント)を概要ビューの開始点とすることをお薦めします。ビジネス・ニーズに応じて、アプリケーションのフェーズへのグループ化および計画の検証を行うために、より重要になる他の属性を特定します。

計画では、各フェーズをビジネス目標(自己回復性のあるシステムの作成、新しい開発の有効化、コンペリング・イベントへの対応など)とどのように連携させるかを示します。組織に好ましい順序で導入フェーズを達成できない場合は、特定のフェーズが他のフェーズより優先された理由を文書化します。

戦略を検証するには、収集した属性に基づいて、クラウド・レディネス・チャート、戦略機能マトリックス、集計属性ビューおよびその他の設計パースペクティブを相互参照します。

前進するためには、スコープの管理が不可欠です。小さな単位、場合によってはアプリケーションのサブセット単位で繰り返します。適用可能であれば、事業部門全体にわたって並列ストリームを分解します。組織があいまいさを受け入れることができる場合は、将来のフェーズのすべての詳細に取り組むのではなく、将来の重要な意思決定ポイントを特定し、それを未知のリスクとしてハイライトするか、それらの事項を決定できる時期を特定してください。たとえば、組織はマルチクラウド戦略を選択しますか。それとも、データ・レジデンシ要件やオンプレミス要件のために限定的なハイブリッド・モデルを維持できますか。

最も重要なことは、クラウド導入の計画は1回かぎりのアクティビティではなく、学習しながら繰り返すアクティビティであるという基本的な予想を確立することです。将来のフェーズで計画を変更することは、問題に対する反動的なピボットとしてではなく、急速に進化するクラウド・テクノロジとアーキテクチャ・エコシステムのコンテキストにおいてビジネス目標をサポートするサービスとして考えてください。