移行前にアーキテクチャの変更を承認するApprove architecture changes before migration

移行の評価プロセスの間、ワークロードの将来状態計画を作成するために各ワークロードの評価、設計、見積もりが行われます。During the assess process of migration, each workload is evaluated, architected, and estimated to develop a future state plan for the workload. 一部のワークロードは、アーキテクチャの変更なしでクラウドに移行できます。Some workloads can be migrated to the cloud with no change to the architecture. オンプレミスの構成とアーキテクチャを維持することで、リスクを軽減し、移行プロセスを効率化することができます。Maintaining on-premises configuration and architecture can reduce risk and streamline the migration process. 残念ながら、アーキテクチャ変更なしですべてのアプリケーションをクラウドで実行できるわけではありません。Unfortunately, not every application can run in the cloud without changes to the architecture. アーキテクチャの変更が必要な場合、この記事は変更の分類に役立ち、適切な承認アクティビティに関するいくつかのガイダンスを提供することができます。When architecture changes are required, this article can help classify the change and can provide some guidance on the proper approval activities.

ビジネスへの影響と承認Business impact and approval

移行中にいくつかの要素が変更され、ビジネスに影響が及ぶ可能性があります。During migration, some things are likely to change in ways that impact the business. 変更は避けられない場合もありますが、変更を公表せず文書化もしないでいると予想外の問題が生じることがあります。Although change sometimes can't be avoided, surprises as a result of undisclosed or undocumented changes should be. 移行作業全体を通して利害関係者のサポートを維持するには、予想外の問題を避けることが重要です。To maintain stakeholder support throughout the migration effort, it's important to avoid surprises. アプリケーションの所有者またはビジネスの利害関係者が予想していない問題が発生すると、クラウド導入作業に遅れが生じる、または作業が止まってしまう可能性があります。Surprising application owners or business stakeholders can slow or halt a cloud adoption effort.

以下に対する変更など、ビジネス プロセスに影響する可能性がある変更については、移行前にワークロードのビジネス所有者に準備してもらうことが重要です。Prior to migration, it is important to prepare the workload's business owner for any changes that could affect business processes, such as changes to:

  • サービス レベル アグリーメント。Service-level agreements.
  • エンド ユーザーに影響を与えるアクセス パターンまたはセキュリティ要件。Access patterns or security requirements that impact the end user.
  • データ保持プラクティス。Data retention practices.
  • コア アプリケーションのパフォーマンス。Core application performance.

最小限の変更で、または変更なしでワークロードを移行できる場合でも、ビジネスに影響が出る可能性があります。Even when a workload can be migrated with minimal to no change, there could still be a business impact. レプリケーション プロセスは、実稼働システムのパフォーマンスを低下させる可能性があります。Replication processes can slow the performance of production systems. 移行に備えて環境に変更を加えると、ルーティングまたはネットワークのパフォーマンスが制限される可能性があります。Changes to the environment in preparation for migration have the potential to cause routing or network performance limitations. レプリケーション、ステージング、または昇格の各アクティビティに起因する可能性がある追加の影響は数多くあります。There are many additional impacts that could result from replication, staging, or promotion activities.

定期的な承認アクティビティは、変更に起因する予想外の問題や、パフォーマンスに起因するビジネスへの影響を最小化または回避するために役立ちます。Regular approval activities can help minimize or avoid surprises as a result of change or performance-driven business impacts. クラウド導入チームは、評価プロセスの最後に、かつ移行プロセスを開始する前に変更承認プロセスを実行する必要があります。The cloud adoption team should execute a change approval process at the end of the assessment process, before beginning the migration process.

既存のカルチャExisting culture

IT チームには多くの場合、オンプレミス資産が関係する変更を管理するための既存のメカニズムが存在します。Your IT teams likely have existing mechanisms for managing change involving your on-premises assets. これらのメカニズムは通常、従来の ITIL (Information Technology Infrastructure Library) ベースの変更管理プロセスによって管理されます。Typically these mechanisms are governed by traditional Information Technology Infrastructure Library-based (ITIL-based) change management processes. 多くの大企業の移行では、変更諮問委員会 (CAB) がこれらのプロセスに関与します。CAB の責任は、すべての IT 関連の変更要求 (RFC) を確認し、文書化し、承認することです。In many enterprise migrations, these processes involve a change advisory board (CAB) that's responsible for reviewing, documenting, and approving all IT-related requests for changes (RFC).

CAB には一般的に、複数の IT チームやビジネス チームの専門家が含まれており、すべての IT 関連の変更について多様な視点と詳細なレビューを提供します。The CAB generally includes experts from multiple IT and business teams, offering a variety of perspectives and detailed review for all IT-related changes. CAB の承認プロセスは、IT 運用によって管理される安定的なワークロードに関係した変更のリスクを軽減し、変更がビジネスに及ぼす影響を最小化するのに実績のある方法です。A CAB approval process is a proven way to reduce risk and minimize the business impact of changes involving stable workloads managed by IT operations.

技術的承認Technical approval

技術的変更の承認に対する組織の準備は、クラウド移行失敗の最も一般的な理由の 1 つです。Organizational readiness for the approval of technical change is among the most common reasons for cloud migration failure. クラウド プラットフォームのどの赤字よりも多くのプロジェクトが、一連の技術的承認によって停滞しています。More projects are stalled by a series of technical approvals than any deficit in a cloud platform. 技術的変更の承認のために組織を準備することは、移行成功の重要な要件です。Preparing the organization for technical change approval is an important requirement for migration success. 組織で技術的承認の準備ができていることを確認するためのベスト プラクティスを以下に示します。The following are a few best practices to ensure that the organization is ready for technical approval.

ITIL 変更諮問委員会の課題ITIL change advisory board challenges

すべての変更管理方法には、コントロールと承認プロセスの独自のセットがあります。Every change management approach has its own set of controls and approval processes. 移行は、あいまいさが大きい状態から始まり、実施過程で徐々に明確さが増していく一連の継続的変更です。Migration is a series of continuous changes that start with a high degree of ambiguity and develop additional clarity through the course of execution. そのため、移行の管理には、クラウド戦略チームがプロダクト所有者の役割を担うアジャイル ベースの変更管理方法が最も適しています。As such, migration is best governed by agile-based change management approaches, with the cloud strategy team serving as a product owner.

ただし、クラウド移行中の変更のスケールと頻度は、ITIL プロセスの性質とはあまり適合しません。However, the scale and frequency of change during a cloud migration doesn't fit well with the nature of ITIL processes. CAB 承認の要件が移行成功のリスクとなり、作業を遅らせたり止めたりしてしまう可能性があります。The requirements of a CAB approval can risk the success of a migration, slowing or stopping the effort. さらに、移行の初期段階では、あいまいさが大きく、主題の専門知識が不足している傾向があります。Further, in the early stages of migration, ambiguity is high and subject matter expertise tends to be low. 最初のいくつかのワークロードの移行またはリリースでは、クラウド導入チームは多くの場合、学習モードに入っています。For the first several workload migrations or releases, the cloud adoption team is often in a learning mode. そのため、CAB 承認に合格するために必要な種類のデータをチームが提供することが困難な場合があります。As such, it could be difficult for the team to provide the types of data needed to pass a CAB approval.

以下のベストプラクティスは、痛みをもたらす阻害要因になることなく、CAB が移行中にある程度の快適さを維持するために役立ちます。The following best practices can help the CAB maintain a degree of comfort during migration without become a painful blocker.

変更を標準化するStandardize change

クラウド導入チームにとって、クラウドに移行するワークロードごとに詳細なアーキテクチャ上の決定を検討することは魅力的です。It is tempting for a cloud adoption team to consider detailed architectural decisions for each workload being migrated to the cloud. 過去のアーキテクチャ上の決定をリファクタリングするための触媒としてクラウド移行を使用することも同様に魅力的です。It is equally tempting to use cloud migration as a catalyst to refactor past architectural decisions. 数百の VM または数十のワークロードを移行する組織の場合、どちらの方法も適切に管理できます。For organizations that are migrating a few hundred VMs or a few dozen workloads, either approach can be properly managed. 1,000 以上の資産で構成されるデータセンターを移行する場合、これらの各方法は、成功の可能性を大きく下げる高リスクのアンチパターンと見なされます。When migrating a datacenter consisting of 1,000 or more assets, each of these approaches is considered a high-risk antipattern that significantly reduces the likelihood of success. すべてのアプリケーションを最新化、リファクタリング、および再設計するには多様なスキルセットと広範な変更が必要であり、これらの作業は人間による大規模な作業に依存しています。Modernizing, refactoring, and rearchitecting every application requires a diverse skill set and a wide variety of changes, and these tasks create dependencies on human efforts at scale. こうした依存の 1 つ 1 つが移行作業のリスクを増やします。Each of these dependencies injects risk into the migration effort.

デジタル資産の合理化に関する記事では、デジタル資産を合理化する際の基本的前提条件の機敏性および時間節約の影響について説明しています。The article on digital estate rationalization discusses the agility and time-saving impact of basic assumptions when rationalizing a digital estate. 標準化された変更には追加の利点があります。There is an additional benefit of standardized change. 移行作業を管理するための既定の合理化方法を選択することで、クラウド諮問委員会またはプロダクト所有者は、ワークロードの長大なリストへの 1 つの変更の適用をレビューおよび承認することができます。By choosing a default rationalization approach to govern the migration effort, the cloud advisory board or product owner can review and approve the application of one change to a long list of workloads. これにより、各ワークロードの技術的承認は、アーキテクチャの大幅な変更に対してクラウドとの互換性を要求するというものに単純化されます。This reduces technical approval of each workload to those that require a significant architecture change to be cloud compatible.

承認者の期待と役割を明確にするClarify expectations and roles of approvers

最初のワークロードを評価する前に、クラウド戦略チームは、変更の承認に関与する人物の期待を文書化して周知する必要があります。Before the first workload is assessed, the cloud strategy team should document and communicate the expectations of anyone involved in the approval of change. このシンプルなアクティビティにより、クラウド導入チームが全面的に関与しているときに、損害を伴う遅延が発生することを回避します。This simple activity can avoid costly delays when the cloud adoption team is fully engaged.

早くから承認を求めるSeek approval early

可能であれば、評価プロセスの間に技術的変更を検出し、文書化する必要があります。When possible, technical change should be detected and documented during the assessment process. 承認プロセスに関係なく、クラウド導入チームは早い段階で承認者を関与させる必要があります。Regardless of approval processes, the cloud adoption team should engage approvers early. 変更承認を早く開始できればできるほど、承認プロセスが移行アクティビティを妨げる可能性が低くなります。The sooner that change approval can begin, the less likely an approval process is to block migration activities.

次のステップNext steps

これらのベスト プラクティスに従えば、適切でリスクの低い承認をより簡単に移行作業に統合できるはずです。With the help of these best practices, it should be easier to integrate proper, low-risk approval into migration efforts. ワークロードの変更が承認されたら、クラウド導入チームはワークロードを移行する準備が整います。After workload changes are approved, the cloud adoption team is ready to migrate workloads.