diff --git a/docs/cloud-adoption/appendix/cloud-operating-model.md b/docs/cloud-adoption/appendix/cloud-operating-model.md index 396914e4b3a..af6c6f39f55 100644 --- a/docs/cloud-adoption/appendix/cloud-operating-model.md +++ b/docs/cloud-adoption/appendix/cloud-operating-model.md @@ -15,7 +15,7 @@ layout: LandingPage In early 2018, Microsoft released the Cloud Operating Model (COM). The COM was a guide that helped customers understand the **what** and the **why** of digital transformation. This helped customers get a sense of all the areas that needed to be addressed: business strategy, culture strategy, and technology strategy. What was not included in the COM were the specific _how-to's_, which left customers wondering, "Where do we go from here?" -In October 2018, we began a review of all the models that had proliferated across the Microsoft community, we found roughly 60 different cloud adoption models. A cross-Microsoft team was established to bring everything together as a dedicated engineering "product" with defined implementations across services, sales, and marketing. This effort culminated in the creation of a single model, the Microsoft Cloud Adoption Framework for Azure, designed to help customers understand the **what** and **why** and provide unified guidance on the **how** to help them accelerate their cloud journey. The goal of this project is to create a One Microsoft approach to cloud adoption. +In October 2018, we began a review of all the models that had proliferated across the Microsoft community, we found roughly 60 different cloud adoption models. A cross-Microsoft team was established to bring everything together as a dedicated engineering "product" with defined implementations across services, sales, and marketing. This effort culminated in the creation of a single model, the Microsoft Cloud Adoption Framework for Azure, designed to help customers understand the **what** and **why** and provide unified guidance on the **how** to help them accelerate their cloud adoption. The goal of this project is to create a One Microsoft approach to cloud adoption. ## Using Cloud Operating Model practices within the Cloud Adoption Framework @@ -48,7 +48,7 @@ COM included an infographic that outlined the various decisions and actions need The Cloud Adoption Framework follows a similar model. However, as the actions and decisions expanded into multiple decision trees, complexity quickly made a single graphical view appear overwhelming. To simplify the guidance and make it more immediately actionable, the single graphic has been decomposed into the following structures. -At the executive level, the Cloud Adoption Framework has been simplified into the following three phases of adoption and two primary journeys. +At the executive level, the Cloud Adoption Framework has been simplified into the following three phases of adoption and two primary governance guides. ![Executive level structure of the Cloud Adoption Framework](../_images/caf-structure.png) @@ -63,7 +63,7 @@ The three phases of cloud adoption have been mapped to two specific journeys: - [Migrate](../getting-started/migrate.md): Move existing workloads to the cloud. - [Innovate](../getting-started/innovate.md): Modernize existing workloads and create new products and services. -Additional resources required to be successful in a cloud adoption journey can be found in [Enabling adoption success](../getting-started/enable.md). +Additional resources required for successful cloud adoption can be found in [Enabling adoption success](../getting-started/enable.md). ## Next steps diff --git a/docs/cloud-adoption/appendix/roadmap.md b/docs/cloud-adoption/appendix/roadmap.md index d03a113ac38..f8f7d879c3a 100644 --- a/docs/cloud-adoption/appendix/roadmap.md +++ b/docs/cloud-adoption/appendix/roadmap.md @@ -50,7 +50,7 @@ To successfully adopting the cloud, a customer must prepare its people, technolo - Prioritize workloads based on impacts to the business outcomes. - Create a cloud adoption plan based on the current digital estate and prioritized workloads. - **Ready:** Prepare the people, culture, and environment for change. This phase has three key components: - - Create a Cloud Strategy team and other organizational alignment. + - Create a cloud strategy team and other organizational alignment. - Create a skills readiness plan across roles and functions. - Establish an Azure foundation by preparing the cloud environment. - **Adopt:** Implement the desired changes across IT and business processes to help customers realize their business, technology, and people strategies. This phase includes several areas that will vary depending on what the organization is implementing: diff --git a/docs/cloud-adoption/business-strategy/global-markets.md b/docs/cloud-adoption/business-strategy/global-markets.md index 4bace695c14..3c53d006e5a 100644 --- a/docs/cloud-adoption/business-strategy/global-markets.md +++ b/docs/cloud-adoption/business-strategy/global-markets.md @@ -30,7 +30,7 @@ It is important to understand which business units operate in foreign countries, It is important to understand how global users access applications that are not hosted in the same country as the user. Often time global WANs (Wide Area Networks) route users based on existing networking agreements. In a traditional on-premises world, some constraints limit WAN design. Those constraints can lead to poor user experiences if not properly understood before cloud adoption. -In a cloud model, commodity internet opens up many new options as well. Communicating the spread of employees across multiple geographies can help the Cloud Adoption team design WAN solutions that create positive user experiences **and** potential reduce networking costs. +In a cloud model, commodity internet opens up many new options as well. Communicating the spread of employees across multiple geographies can help the cloud adoption team design WAN solutions that create positive user experiences **and** potential reduce networking costs. ## External user usage patterns diff --git a/docs/cloud-adoption/decision-guides/software-defined-network/index.md b/docs/cloud-adoption/decision-guides/software-defined-network/index.md index fb2969f7e1c..b05c0fdea9a 100644 --- a/docs/cloud-adoption/decision-guides/software-defined-network/index.md +++ b/docs/cloud-adoption/decision-guides/software-defined-network/index.md @@ -23,7 +23,7 @@ Jump to: [PaaS Only](paas-only.md) | [Cloud-native](cloud-native.md) | [Cloud DM SDN provides several options with varying degrees of pricing and complexity. The above discovery guide provides a reference to quickly personalize these options to best align with specific business and technology strategies. -The inflection point in this guide depends on several key decisions that your Cloud Strategy team have made before making decisions about networking architecture. Most important among these are decisions involving your [digital estate definition](../../digital-estate/index.md) and [subscription design](../subscriptions/index.md) (which may also require inputs from decisions made related to your cloud accounting and global markets strategies). +The inflection point in this guide depends on several key decisions that your cloud strategy team has made before making decisions about networking architecture. Most important among these are decisions involving your [digital estate definition](../../digital-estate/index.md) and [subscription design](../subscriptions/index.md) (which may also require inputs from decisions made related to your cloud accounting and global markets strategies). Small single-region deployments of fewer than 1,000 VMs are less likely to be significantly affected by this inflection point. Conversely, large adoption efforts with more than 1,000 VMs, multiple business units, or multiple geopolitical markets, could be substantially affected by your SDN decision and this key inflection point. diff --git a/docs/cloud-adoption/digital-estate/index.md b/docs/cloud-adoption/digital-estate/index.md index d644f907e89..2205fb4ecd5 100644 --- a/docs/cloud-adoption/digital-estate/index.md +++ b/docs/cloud-adoption/digital-estate/index.md @@ -31,7 +31,7 @@ The measurement of a digital estate changes depending on the desired business ou After an organization understands the most important form of transformation, digital estate planning becomes much easier to manage. > [!TIP] -> Each type of transformation can be measured with any of the three views. Companies commonly complete all three transformations in parallel. We strongly recommend that the leadership and cloud strategy team agree regarding the transformation that is most important for business success. That understanding serves as the basis for common language and metrics across multiple initiatives. +> Each type of transformation can be measured with any of the three views. Companies commonly complete all three transformations in parallel. We strongly recommend that company leadership and the cloud strategy team agree regarding the transformation that is most important for business success. That understanding serves as the basis for common language and metrics across multiple initiatives. ## How can a financial model be updated to reflect the digital estate? diff --git a/docs/cloud-adoption/digital-estate/rationalize.md b/docs/cloud-adoption/digital-estate/rationalize.md index e238c08758d..83783cfb46d 100644 --- a/docs/cloud-adoption/digital-estate/rationalize.md +++ b/docs/cloud-adoption/digital-estate/rationalize.md @@ -55,7 +55,7 @@ In an incremental rationalization process, an agent-less solution could be used ### Quantitative analysis: Streamline decisions -Regardless of the approach to inventory discovery, quantitative analysis can drive initial decisions and assumptions. This is especially true when trying to identify the first workload or when the goal of rationalization is a high-level cost comparison. In an incremental rationalization process, the cloud strategy and cloud adoption teams limit the [five Rs of rationalization](5-rs-of-rationalization.md) to two concise decisions and only apply those quantitative factors. This streamlines the analysis and reduces the amount of initial data that's required to drive change. +Regardless of the approach to inventory discovery, quantitative analysis can drive initial decisions and assumptions. This is especially true when trying to identify the first workload or when the goal of rationalization is a high-level cost comparison. In an incremental rationalization process, the cloud strategy team and the cloud adoption teams limit the [five Rs of rationalization](5-rs-of-rationalization.md) to two concise decisions and only apply those quantitative factors. This streamlines the analysis and reduces the amount of initial data that's required to drive change. For example, if an organization is in the midst of an IaaS migration to the cloud, you can assume that most workloads will either be retired or rehosted. @@ -111,7 +111,7 @@ The first workload is often deployed in an experimental environment with no oper ### Qualitative analysis -The cloud adoption and cloud strategy teams can work together to analyze this small workload. This collaboration creates a controlled opportunity to create and test qualitative analysis criteria. The smaller population creates an opportunity to survey the affected users, and to complete a detailed qualitative analysis in a week or less. For common qualitative analysis factors, see the specific rationalization target in the [5 Rs of rationalization](5-rs-of-rationalization.md). +The cloud adoption teams and the cloud strategy team can work together to analyze this small workload. This collaboration creates a controlled opportunity to create and test qualitative analysis criteria. The smaller population creates an opportunity to survey the affected users, and to complete a detailed qualitative analysis in a week or less. For common qualitative analysis factors, see the specific rationalization target in the [5 Rs of rationalization](5-rs-of-rationalization.md). ### Migration @@ -133,7 +133,7 @@ The traditional approach to rationalization attempts to meet all foreseeable nee ### Build the first backlogs -The cloud adoption and cloud strategy teams can work together on the qualitative analysis for the first 10 workloads. This effort creates the first prioritized migration backlog and the first prioritized release backlog. This method enables the teams to iterate on the approach and provides sufficient time to create an adequate process for qualitative analysis. +The cloud adoption teams and the cloud strategy team can work together on the qualitative analysis for the first 10 workloads. This effort creates the first prioritized migration backlog and the first prioritized release backlog. This method enables the teams to iterate on the approach and provides sufficient time to create an adequate process for qualitative analysis. ### Mature the process diff --git a/docs/cloud-adoption/getting-started/migrate.md b/docs/cloud-adoption/getting-started/migrate.md index a3d220660f3..0acbf43a01c 100644 --- a/docs/cloud-adoption/getting-started/migrate.md +++ b/docs/cloud-adoption/getting-started/migrate.md @@ -93,7 +93,7 @@ The effort to realize the desired business outcomes may trigger slight changes t - The IT team is likely to adopt new skills to support workloads in the cloud. - Execution of a cloud migration encourages iterative or agile approaches. - Inclusion of cloud governance also tends to inspire DevOps approaches. -- Creation of a Cloud Strategy team can lead to tighter integration between business and IT leaders. +- Creation of a cloud strategy team can lead to tighter integration between business and IT leaders. - Collectively, these changes tend to lead to business and IT agility. Cultural change is not a goal of cloud migration or the Cloud Adoption Framework, but it is a commonly experienced outcome. diff --git a/docs/cloud-adoption/governance/corporate-policy.md b/docs/cloud-adoption/governance/corporate-policy.md index 35934d8d58e..fda54cbcc0c 100644 --- a/docs/cloud-adoption/governance/corporate-policy.md +++ b/docs/cloud-adoption/governance/corporate-policy.md @@ -22,7 +22,7 @@ layout: LandingPage
-Any change to business processes or technology platforms introduces risk to the business. Cloud Governance teams, whose members are sometimes known as cloud custodians, are tasked with mitigating these risks with minimal interruption to adoption or innovation efforts.

However, cloud governance requires more than technical implementation. Subtle changes in the corporate narrative or corporate policies can affect adoption efforts significantly. Before implementation, it's important to look beyond IT while defining corporate policy.

+Any change to business processes or technology platforms introduces risk to the business. Cloud governance teams, whose members are sometimes known as cloud custodians, are tasked with mitigating these risks with minimal interruption to adoption or innovation efforts.

However, cloud governance requires more than technical implementation. Subtle changes in the corporate narrative or corporate policies can affect adoption efforts significantly. Before implementation, it's important to look beyond IT while defining corporate policy.

diff --git a/docs/cloud-adoption/governance/cost-management/business-risks.md b/docs/cloud-adoption/governance/cost-management/business-risks.md index 081c9632ec0..28dca7f2146 100644 --- a/docs/cloud-adoption/governance/cost-management/business-risks.md +++ b/docs/cloud-adoption/governance/cost-management/business-risks.md @@ -29,10 +29,10 @@ The cloud offers self-service capabilities that were previously unheard of in tr The Cost Management discipline attempts to address core business risks related to expenses incurred when hosting cloud-based workloads. Work with your business to identify these risks and monitor each of them for relevance as you plan for and implement your cloud deployments. -Risks will differ between organization, but the following serve as common cost-related risks that you can use as a starting point for discussions within your Cloud Governance team: +Risks will differ between organization, but the following serve as common cost-related risks that you can use as a starting point for discussions within your cloud governance team: - **Budget control:** Not controlling budget can lead to excessive spending with a cloud vendor. -- **Utilization loss:** Prepurchases or precommitments that are not used can result in wasted investments. +- **Utilization loss:** Prepurchases or precommitments that go unused can result in wasted investments. - **Spending anomalies:** Unexpected spikes in either direction can be indicators of improper usage. - **Overprovisioned assets:** When assets are deployed in a configuration that exceed the needs of an application or virtual machine (VM), they can increase costs and create waste. diff --git a/docs/cloud-adoption/governance/cost-management/compliance-processes.md b/docs/cloud-adoption/governance/cost-management/compliance-processes.md index 71f9bfa8d35..efe47404d97 100644 --- a/docs/cloud-adoption/governance/cost-management/compliance-processes.md +++ b/docs/cloud-adoption/governance/cost-management/compliance-processes.md @@ -13,7 +13,7 @@ ms.custom: governance # Cost Management policy compliance processes -This article discusses an approach to creating processes that support a [Cost Management](./index.md) governance discipline. Effective governance of cloud costs starts with recurring manual processes designed to support policy compliance. This requires regular involvement of the Cloud Governance team and interested business stakeholders to review and update policy and ensure policy compliance. In addition, many ongoing monitoring and enforcement processes can be automated or supplemented with tooling to reduce the overhead of governance and allow for faster response to policy deviation. +This article discusses an approach to creating processes that support a [Cost Management](./index.md) governance discipline. Effective governance of cloud costs starts with recurring manual processes designed to support policy compliance. This requires regular involvement of the cloud governance team and interested business stakeholders to review and update policy and ensure policy compliance. In addition, many ongoing monitoring and enforcement processes can be automated or supplemented with tooling to reduce the overhead of governance and allow for faster response to policy deviation. ## Planning, review, and reporting processes @@ -29,7 +29,7 @@ This is the time to make a precommitment or prepurchase to maximize discounting. **Quarterly planning:** On a quarterly basis, review budgets with each billing unit leader to align forecast and actual spending. If there are changes to the plan or unexpected spending patterns, align and reallocate the budget. -This quarterly planning process is also a good time to evaluate the current membership of your Cloud Governance team for knowledge gaps related to current or future business plans. Invite relevant staff and workload owners to participate in reviews and planning as either temporary advisors or permanent members of your team. +This quarterly planning process is also a good time to evaluate the current membership of your cloud governance team for knowledge gaps related to current or future business plans. Invite relevant staff and workload owners to participate in reviews and planning as either temporary advisors or permanent members of your team. **Education and training:** On a bimonthly basis, offer training sessions to make sure business and IT staff are up-to-date on the latest Cost Management policy requirements. As part of this process review and update any documentation, guidance, or other training assets to ensure they are in sync with the latest corporate policy statements. diff --git a/docs/cloud-adoption/governance/cost-management/discipline-improvement.md b/docs/cloud-adoption/governance/cost-management/discipline-improvement.md index 75886942d19..78fec3c7b7c 100644 --- a/docs/cloud-adoption/governance/cost-management/discipline-improvement.md +++ b/docs/cloud-adoption/governance/cost-management/discipline-improvement.md @@ -21,7 +21,7 @@ This article outlines potential tasks your company perform to develop and mature *Figure 1 - Adoption phases of the incremental approach to cloud governance.* -No single document can account for the requirements of all businesses. As such, this article outlines suggested minimum and potential example activities for each phase of the governance maturation process. The initial objective of these activities is to help you build a [Policy MVP](../journeys/index.md#an-incremental-approach-to-cloud-governance) and establish a framework for incremental policy evolution. Your Cloud Governance team will need to decide how much to invest in these activities to improve your Cost Management governance capabilities. +No single document can account for the requirements of all businesses. As such, this article outlines suggested minimum and potential example activities for each phase of the governance maturation process. The initial objective of these activities is to help you build a [Policy MVP](../journeys/index.md#an-incremental-approach-to-cloud-governance) and establish a framework for incremental policy improvement. Your cloud governance team will need to decide how much to invest in these activities to improve your Cost Management governance capabilities. > [!CAUTION] > Neither the minimum or potential activities outlined in this article are aligned to specific corporate policies or third-party compliance requirements. This guidance is designed to help facilitate the conversations that will lead to alignment of both requirements with a cloud governance model. @@ -99,7 +99,7 @@ Once the transformation is complete, governance and operations must live on for - Analyze stakeholder value and cost reporting methods on a monthly basis. - Remediate underused assets and determine if they're worth continuing. - Detect misalignments and anomalies between the plan and actual spending. -- Assist the cloud adoption teams and the Cloud Strategy team with understanding and resolving these anomalies. +- Assist the cloud adoption teams and the cloud strategy team with understanding and resolving these anomalies. ## Next steps diff --git a/docs/cloud-adoption/governance/cost-management/index.md b/docs/cloud-adoption/governance/cost-management/index.md index ad491132af9..86c601d1f39 100644 --- a/docs/cloud-adoption/governance/cost-management/index.md +++ b/docs/cloud-adoption/governance/cost-management/index.md @@ -19,7 +19,7 @@ Cost Management is one of the [Five Disciplines of Cloud Governance](../governan > [!NOTE] > Cost Management governance does not replace the existing business teams, accounting practices, and procedures that are involved in your organization's financial management of IT-related costs. The primary purpose of this discipline is to identify potential cloud-related risks related to IT spending, and provide risk-mitigation guidance to the business and IT teams responsible for deploying and managing cloud resources. -The primary audience for this guidance is your organization's cloud architects and other members of your Cloud Governance team. However, the decisions, policies, and processes that emerge from this discipline should involve engagement and discussions with relevant members of your business and IT teams, especially those leaders responsible for owning, managing, and paying for cloud-based workloads. +The primary audience for this guidance is your organization's cloud architects and other members of your cloud governance team. However, the decisions, policies, and processes that emerge from this discipline should involve engagement and discussions with relevant members of your business and IT teams, especially those leaders responsible for owning, managing, and paying for cloud-based workloads. ## Policy statements diff --git a/docs/cloud-adoption/governance/cost-management/policy-statements.md b/docs/cloud-adoption/governance/cost-management/policy-statements.md index f0a3182d23e..909980e8c9d 100644 --- a/docs/cloud-adoption/governance/cost-management/policy-statements.md +++ b/docs/cloud-adoption/governance/cost-management/policy-statements.md @@ -63,7 +63,7 @@ The following sample policy statements address common cost-related business risk **Business risk:** Effective cost management creates new risks. Optimization of spending is inverse to system performance. When reducing costs, there is a risk of overtightening spending and producing poor user experiences. -**Policy statement:** Any asset that directly affects customer experiences must be identified through grouping or tagging. Before optimizing any asset that affects customer experience, the Cloud Governance team must adjust optimization based on at least 90 days of utilization trends. Document any seasonal or event driven bursts considered when optimizing assets. +**Policy statement:** Any asset that directly affects customer experiences must be identified through grouping or tagging. Before optimizing any asset that affects customer experience, the cloud governance team must adjust optimization based on at least 90 days of utilization trends. Document any seasonal or event driven bursts considered when optimizing assets. **Design options:** diff --git a/docs/cloud-adoption/governance/deployment-acceleration/compliance-processes.md b/docs/cloud-adoption/governance/deployment-acceleration/compliance-processes.md index 68c95d959c7..0ce32aab093 100644 --- a/docs/cloud-adoption/governance/deployment-acceleration/compliance-processes.md +++ b/docs/cloud-adoption/governance/deployment-acceleration/compliance-processes.md @@ -23,17 +23,17 @@ The best Deployment Acceleration tools in the cloud are only as good as the proc **Deployment planning:** Before deploying any asset, perform a security and operations review to identify any new risks and ensure all deployment related policy requirements are met. -**Deployment testing:** As part of the deployment process for any asset, the Cloud Governance team, in cooperation with your IT operations teams, is responsible for reviewing the deployment policy compliance. +**Deployment testing:** As part of the deployment process for any asset, the cloud governance team, in cooperation with your IT operations teams, is responsible for reviewing the deployment policy compliance. **Annual planning:** Conduct an annual high-level review of Deployment Acceleration strategy. Explore future corporate priorities and updated cloud adoption strategies to identify potential risk increase and other emerging configuration needs and opportunities. Also use this time to review the latest DevOps best practices and integrate these into your policies and review processes. **Quarterly review and planning:** Conduct a quarterly review of operational audit data and incident reports to identify any changes required in Deployment Acceleration policy. As part of this process, review current DevOps and DevTechOps best practices, and update policy as appropriate. After the review is complete, align application and systems design guidance with updated policy. -This planning process is also a good time to evaluate the current membership of your Cloud Governance team for knowledge gaps related to new or evolving policy and risks related to DevOps and Deployment Acceleration. Invite relevant IT staff to participate in reviews and planning as either temporary technical advisors or permanent members of your team. +This planning process is also a good time to evaluate the current membership of your cloud governance team for knowledge gaps related to new or evolving policy and risks related to DevOps and Deployment Acceleration. Invite relevant IT staff to participate in reviews and planning as either temporary technical advisors or permanent members of your team. **Education and training:** On a bimonthly basis, offer training sessions to make sure IT staff and developers are up-to-date on the latest Deployment Acceleration strategy and requirements. As part of this process review and update any documentation, guidance, or other training assets to ensure they are in sync with the latest corporate policy statements. -**Monthly audit and reporting reviews:** Perform a monthly audit on all cloud deployments to assure their continued alignment with configuration policy. Review deployment-related activities with IT staff and identify any compliance issues not already handled as part of the ongoing monitoring and enforcement process. The result of this review is a report for the Cloud Strategy team and each cloud adoption team to communicate overall adherence to policy. The report is also stored for auditing and legal purposes. +**Monthly audit and reporting reviews:** Perform a monthly audit on all cloud deployments to assure their continued alignment with configuration policy. Review deployment-related activities with IT staff and identify any compliance issues not already handled as part of the ongoing monitoring and enforcement process. The result of this review is a report for the cloud strategy team and each cloud adoption team to communicate overall adherence to policy. The report is also stored for auditing and legal purposes. ## Ongoing monitoring processes @@ -43,7 +43,7 @@ Ensure that your IT operations teams have implemented automated monitoring syste ## Violation triggers and enforcement actions -Because noncompliance with configuration policies can lead to critical service disruption risks, the Cloud Governance team should have visibility into serious policy violations. Ensure IT staff have clear escalation paths for reporting configuration compliance issues to the governance team members best suited to identify and verify that policy issues are mitigated once detected. +Because noncompliance with configuration policies can lead to critical service disruption risks, the cloud governance team should have visibility into serious policy violations. Ensure IT staff have clear escalation paths for reporting configuration compliance issues to the governance team members best suited to identify and verify that policy issues are mitigated once detected. When violations are detected, you should take actions to realign with policy as soon as possible. Your IT team can automate most violation triggers using the tools outlined in the [Deployment Acceleration toolchain for Azure](toolchain.md). diff --git a/docs/cloud-adoption/governance/deployment-acceleration/discipline-improvement.md b/docs/cloud-adoption/governance/deployment-acceleration/discipline-improvement.md index 8c5495fb8ec..6c8fcd0e199 100644 --- a/docs/cloud-adoption/governance/deployment-acceleration/discipline-improvement.md +++ b/docs/cloud-adoption/governance/deployment-acceleration/discipline-improvement.md @@ -21,7 +21,7 @@ This article outlines some potential tasks your company can engage in to better *Figure 1 - Adoption phases of the incremental approach to cloud governance.* -It's impossible for any one document to account for the requirements of all businesses. As such, this article outlines suggested minimum and potential example activities for each phase of the governance maturation process. The initial objective of these activities is to help you build a [Policy MVP](../journeys/index.md#an-incremental-approach-to-cloud-governance) and establish a framework for incremental policy evolution. Your Cloud Governance team will need to decide how much to invest in these activities to improve your Identity Baseline governance capabilities. +It's impossible for any one document to account for the requirements of all businesses. As such, this article outlines suggested minimum and potential example activities for each phase of the governance maturation process. The initial objective of these activities is to help you build a [Policy MVP](../journeys/index.md#an-incremental-approach-to-cloud-governance) and establish a framework for incremental policy improvement. Your cloud governance team will need to decide how much to invest in these activities to improve your Identity Baseline governance capabilities. > [!CAUTION] > Neither the minimum or potential activities outlined in this article are aligned to specific corporate policies or third-party compliance requirements. This guidance is designed to help facilitate the conversations that will lead to alignment of both requirements with a cloud governance model. diff --git a/docs/cloud-adoption/governance/deployment-acceleration/index.md b/docs/cloud-adoption/governance/deployment-acceleration/index.md index 249bf8f0dc6..704f0e2c355 100644 --- a/docs/cloud-adoption/governance/deployment-acceleration/index.md +++ b/docs/cloud-adoption/governance/deployment-acceleration/index.md @@ -14,14 +14,14 @@ layout: LandingPage # Deployment Acceleration discipline overview -Deployment Acceleration is one of the [Five Disciplines of Cloud Governance](../governance-disciplines.md) within the [Cloud Adoption Framework governance model](../index.md). This discipline focuses on ways of establishing policies to govern asset configuration or deployment. Within the Five Disciplines of Cloud Governance, Deployment Acceleration includes deployment, configuration alignment, and script reusability. This could be through manual activities or fully automated DevOps activities. In either case, the policies would remain largely the same. As this discipline matures, the Cloud Governance team can serve as a partner in DevOps and deployment strategies by accelerating deployments and removing barriers to cloud adoption, through the application of reusable assets. +Deployment Acceleration is one of the [Five Disciplines of Cloud Governance](../governance-disciplines.md) within the [Cloud Adoption Framework governance model](../index.md). This discipline focuses on ways of establishing policies to govern asset configuration or deployment. Within the Five Disciplines of Cloud Governance, Deployment Acceleration includes deployment, configuration alignment, and script reusability. This could be through manual activities or fully automated DevOps activities. In either case, the policies would remain largely the same. As this discipline matures, the cloud governance team can serve as a partner in DevOps and deployment strategies by accelerating deployments and removing barriers to cloud adoption, through the application of reusable assets. -This article outlines the Deployment Acceleration process that a company experiences during the planning, building, adopting, and operating phases of implementing a cloud solution. It's impossible for any one document to account for all of the requirements of any business. As such, each section of this article outlines suggested minimum and potential activities. The objective of these activities is to help you build a [policy MVP](../policy-compliance/index.md#minimum-viable-product-mvp-for-policy), but establish a framework for [Incremental Policy](../policy-compliance/index.md#incremental-policy-growth) evolution. The Cloud Governance team should decide how much to invest in these activities to improve the Deployment Acceleration position. +This article outlines the Deployment Acceleration process that a company experiences during the planning, building, adopting, and operating phases of implementing a cloud solution. It's impossible for any one document to account for all of the requirements of any business. As such, each section of this article outlines suggested minimum and potential activities. The objective of these activities is to help you build a [policy MVP](../policy-compliance/index.md#minimum-viable-product-mvp-for-policy), but establish a framework for [Incremental Policy](../policy-compliance/index.md#incremental-policy-growth) improvement. The cloud governance team should decide how much to invest in these activities to improve the Deployment Acceleration position. > [!NOTE] > The Deployment Acceleration discipline does not replace the existing IT teams, processes, and procedures that allow your organization to effectively deploy and configure cloud-based resources. The primary purpose of this discipline is to identify potential business risks and provide risk-mitigation guidance to the IT staff that are responsible for managing your resources in the cloud. As you develop governance policies and processes make sure to involve relevant IT teams in your planning and review processes. -The primary audience for this guidance is your organization's cloud architects and other members of your Cloud Governance team. However, the decisions, policies, and processes that emerge from this discipline should involve engagement and discussions with relevant members of your business and IT teams, especially those leaders responsible for deploying and configuring cloud-based workloads. +The primary audience for this guidance is your organization's cloud architects and other members of your cloud governance team. However, the decisions, policies, and processes that emerge from this discipline should involve engagement and discussions with relevant members of your business and IT teams, especially those leaders responsible for deploying and configuring cloud-based workloads. ## Policy statements diff --git a/docs/cloud-adoption/governance/deployment-acceleration/toolchain.md b/docs/cloud-adoption/governance/deployment-acceleration/toolchain.md index 1d472c75ea6..849a8e9b745 100644 --- a/docs/cloud-adoption/governance/deployment-acceleration/toolchain.md +++ b/docs/cloud-adoption/governance/deployment-acceleration/toolchain.md @@ -15,7 +15,7 @@ ms.custom: governance [Deployment Acceleration](index.md) is one of the [Five Disciplines of Cloud Governance](../governance-disciplines.md). This discipline focuses on ways of establishing policies to govern asset configuration or deployment. Within the Five Disciplines of Cloud Governance, the Deployment Acceleration discipline involves deployment and configuration alignment. This could be through manual activities or fully automated DevOps activities. In either case, the policies involved would remain largely the same. -Cloud custodians, cloud guardians, and cloud architects with an interest in governance are each likely to invest a lot of time in the Deployment Acceleration discipline, which codifies policies and requirements across multiple cloud adoption efforts. The tools in this toolchain are important to the Cloud Governance team and should be a high priority on the learning path for the team. +Cloud custodians, cloud guardians, and cloud architects with an interest in governance are each likely to invest a lot of time in the Deployment Acceleration discipline, which codifies policies and requirements across multiple cloud adoption efforts. The tools in this toolchain are important to the cloud governance team and should be a high priority on the learning path for the team. The following is a list of Azure tools that can help mature the policies and processes that support this governance discipline. diff --git a/docs/cloud-adoption/governance/getting-started.md b/docs/cloud-adoption/governance/getting-started.md index 5377348fa58..c437320ab68 100644 --- a/docs/cloud-adoption/governance/getting-started.md +++ b/docs/cloud-adoption/governance/getting-started.md @@ -21,7 +21,7 @@ This article provides two options for establishing an initial foundation for gov ## Already using the Cloud Adoption Framework -If you have been following along with the Cloud Adoption Framework, you may already have deployed a governance MVP. Guidance is a core aspect of any operating model. It is present throughout every phase of the cloud adoption lifecycle. As such, the [Cloud Adoption Framework](../index.md) provides guidance that injects governance into activities related to the implementation of your [cloud adoption plan](../plan/index.md). One example of this governance integration would be the use of blueprints to deploy one or more landing zones seen throughout in the [ready](../ready/index.md) guidance. Another example is the guidance regarding [scaling out subscriptions](../ready/considerations/scaling-subscriptions.md). If you have followed either of those points of guidance, then the following MVP sections will be little more than a review of your existing deployment decisions. After a quick review, jump ahead to [Mature the initial governance solution and apply best practice controls](./best-practices.md). +If you have been following along with the Cloud Adoption Framework, you may already have deployed a governance MVP. Guidance is a core aspect of any operating model. It is present throughout every phase of the cloud adoption lifecycle. As such, the [Cloud Adoption Framework](../index.md) provides guidance that injects governance into activities related to the implementation of your [cloud adoption plan](../plan/index.md). One example of this governance integration would be the use of blueprints to deploy one or more landing zones seen throughout in the [ready](../ready/index.md) guidance. Another example is the guidance regarding [scaling out subscriptions](../ready/considerations/scaling-subscriptions.md). If you have followed either of those points of guidance, then the following MVP sections will be little more than a review of your existing deployment decisions. After a quick review, jump ahead to [Mature the initial governance solution and apply best-practice controls](./best-practices.md). ## Implement an initial governance foundation (or governance MVP) @@ -65,4 +65,4 @@ The following are two different examples of initial governance foundations (or g Once a governance foundation is in place, apply appropriate best practices to evolve the solution and protect against tangible risks. > [!div class="nextstepaction"] -> [Mature the initial governance solution and apply best practice controls](./best-practices.md) +> [Mature the initial governance solution and apply best-practice controls](./best-practices.md) diff --git a/docs/cloud-adoption/governance/governance-disciplines.md b/docs/cloud-adoption/governance/governance-disciplines.md index 6d2eb1c203b..dfc5012af1e 100644 --- a/docs/cloud-adoption/governance/governance-disciplines.md +++ b/docs/cloud-adoption/governance/governance-disciplines.md @@ -22,7 +22,7 @@ layout: LandingPage
- Any change to business processes or technology platforms introduces risk. Cloud governance teams, whose members are sometimes known as cloud custodians, are tasked with mitigating these risks and ensuring minimal interruption to adoption or innovation efforts.

The Cloud Adoption Framework governance model guides these decisions (regardless of the chosen cloud platform) by focusing on development of corporate policy] and the Five Disciplines of Cloud Governance. Actionable design guides demonstrate this model using Azure services. Learn about the disciplines of the Cloud Adoption Framework governance model below. + Any change to business processes or technology platforms introduces risk. Cloud governance teams, whose members are sometimes known as cloud custodians, are tasked with mitigating these risks and ensuring minimal interruption to adoption or innovation efforts.

The Cloud Adoption Framework governance model guides these decisions (regardless of the chosen cloud platform) by focusing on development of corporate policy and the Five Disciplines of Cloud Governance. Actionable design guides demonstrate this model using Azure services. Learn about the disciplines of the Cloud Adoption Framework governance model below.
diff --git a/docs/cloud-adoption/governance/identity-baseline/business-risks.md b/docs/cloud-adoption/governance/identity-baseline/business-risks.md index b67e8f94c47..d96bd447367 100644 --- a/docs/cloud-adoption/governance/identity-baseline/business-risks.md +++ b/docs/cloud-adoption/governance/identity-baseline/business-risks.md @@ -29,7 +29,7 @@ The importance of the Identity Baseline discipline to your cloud deployment will The Identity Baseline discipline attempts to address core business risks related to identity services and access control. Work with your business to identify these risks and monitor each of them for relevance as you plan for and implement your cloud deployments. -Risks will differ between organization, but the following serve as common identity-related risks that you can use as a starting point for discussions within your Cloud Governance team: +Risks will differ between organization, but the following serve as common identity-related risks that you can use as a starting point for discussions within your cloud governance team: - **Unauthorized access.** Sensitive data and resources that can be accessed by unauthorized users can lead to data leaks or service disruptions, violating your organization's security perimeter and risking business or legal liabilities. - **Inefficiency due to multiple identity solutions.** Organizations with multiple identity services tenants can require multiple accounts for users. This can lead to inefficiency for users who need to remember multiple sets of credentials and for IT in managing accounts across multiple systems. If user access assignments are not updated across identity solutions as staff, teams, and business goals change, your cloud resources may be vulnerable to unauthorized access or users unable to access required resources. diff --git a/docs/cloud-adoption/governance/identity-baseline/compliance-processes.md b/docs/cloud-adoption/governance/identity-baseline/compliance-processes.md index 172bc07a6d9..fb2604d9b80 100644 --- a/docs/cloud-adoption/governance/identity-baseline/compliance-processes.md +++ b/docs/cloud-adoption/governance/identity-baseline/compliance-processes.md @@ -13,7 +13,7 @@ ms.custom: governance # Identity Baseline policy compliance processes -This article discusses an approach to policy adherence processes that govern [Identity Baseline](./index.md). Effective governance of identity starts with recurring manual processes that guide identity policy adoption and revisions. This requires regular involvement of the Cloud Governance team and interested business and IT stakeholders to review and update policy and ensure policy compliance. In addition, many ongoing monitoring and enforcement processes can be automated or supplemented with tooling to reduce the overhead of governance and allow for faster response to policy deviation. +This article discusses an approach to policy adherence processes that govern [Identity Baseline](./index.md). Effective governance of identity starts with recurring manual processes that guide identity policy adoption and revisions. This requires regular involvement of the cloud governance team and interested business and IT stakeholders to review and update policy and ensure policy compliance. In addition, many ongoing monitoring and enforcement processes can be automated or supplemented with tooling to reduce the overhead of governance and allow for faster response to policy deviation. ## Planning, review, and reporting processes @@ -23,17 +23,17 @@ Identity management tools offer capabilities and features that greatly assist us **Deployment planning:** Before any deployment, review the access needs for any workloads and develop an access control strategy that aligns with established corporate identity policy. Document any gaps between needs and current policy to determine if policy updates are required, and modify policy as needed. -**Deployment testing:** As part of the deployment, the Cloud Governance team, in cooperation with IT teams responsible for identity services, will be responsible for reviewing the deployment to validate identity policy compliance. +**Deployment testing:** As part of the deployment, the cloud governance team, in cooperation with IT teams responsible for identity services, will be responsible for reviewing the deployment to validate identity policy compliance. **Annual planning:** On an annual basis, perform a high-level review of identity management strategy. Explore planned changes to the identity services environment and updated cloud adoption strategies to identify potential risk increase or need to modify current identity infrastructure patterns. Also use this time to review the latest identity management best practices and integrate these into your policies and review processes. **Quarterly planning:** On a quarterly basis perform a general review of identity and access control audit data, and meet with the cloud adoption teams to identify any potential new risks or operational requirements that would require updates to identity policy or changes in access control strategy. -This planning process is also a good time to evaluate the current membership of your Cloud Governance team for knowledge gaps related to new or evolving policy and risks related to identity. Invite relevant IT staff to participate in reviews and planning as either temporary technical advisors or permanent members of your team. +This planning process is also a good time to evaluate the current membership of your cloud governance team for knowledge gaps related to new or evolving policy and risks related to identity. Invite relevant IT staff to participate in reviews and planning as either temporary technical advisors or permanent members of your team. **Education and training:** On a bimonthly basis, offer training sessions to make sure IT staff and developers are up-to-date on the latest identity policy requirements. As part of this process review and update any documentation, guidance, or other training assets to ensure they are in sync with the latest corporate policy statements. -**Monthly audit and reporting reviews:** On a monthly basis, perform an audit on all cloud deployments to assure their continued alignment with identity policy. Use this review to check user access against business change to ensure users have correct access to cloud resources, and ensure access strategies such as RBAC are being followed consistently. Identify any privileged accounts and document their purpose. This review process produces a report for the Cloud Strategy team and each cloud adoption team detailing overall adherence to policy. The report is also stored for auditing and legal purposes. +**Monthly audit and reporting reviews:** On a monthly basis, perform an audit on all cloud deployments to assure their continued alignment with identity policy. Use this review to check user access against business change to ensure users have correct access to cloud resources, and ensure access strategies such as RBAC are being followed consistently. Identify any privileged accounts and document their purpose. This review process produces a report for the cloud strategy team and each cloud adoption team detailing overall adherence to policy. The report is also stored for auditing and legal purposes. ## Ongoing monitoring processes diff --git a/docs/cloud-adoption/governance/identity-baseline/discipline-improvement.md b/docs/cloud-adoption/governance/identity-baseline/discipline-improvement.md index 1dd51d4443a..0b89c270747 100644 --- a/docs/cloud-adoption/governance/identity-baseline/discipline-improvement.md +++ b/docs/cloud-adoption/governance/identity-baseline/discipline-improvement.md @@ -21,7 +21,7 @@ This article outlines some potential tasks your company can engage in to better *Figure 1 - Adoption phases of the incremental approach to cloud governance.* -It's impossible for any one document to account for the requirements of all businesses. As such, this article outlines suggested minimum and potential example activities for each phase of the governance maturation process. The initial objective of these activities is to help you build a [Policy MVP](../journeys/index.md#an-incremental-approach-to-cloud-governance) and establish a framework for incremental policy evolution. Your Cloud Governance team will need to decide how much to invest in these activities to improve your Identity Baseline governance capabilities. +It's impossible for any one document to account for the requirements of all businesses. As such, this article outlines suggested minimum and potential example activities for each phase of the governance maturation process. The initial objective of these activities is to help you build a [Policy MVP](../journeys/index.md#an-incremental-approach-to-cloud-governance) and establish a framework for incremental policy improvement. Your cloud governance team will need to decide how much to invest in these activities to improve your Identity Baseline governance capabilities. > [!CAUTION] > Neither the minimum or potential activities outlined in this article are aligned to specific corporate policies or third-party compliance requirements. This guidance is designed to help facilitate the conversations that will lead to alignment of both requirements with a cloud governance model. diff --git a/docs/cloud-adoption/governance/identity-baseline/index.md b/docs/cloud-adoption/governance/identity-baseline/index.md index 74a159a7881..d9ba252413f 100644 --- a/docs/cloud-adoption/governance/identity-baseline/index.md +++ b/docs/cloud-adoption/governance/identity-baseline/index.md @@ -19,7 +19,7 @@ Identity Baseline is one of the [Five Disciplines of Cloud Governance](../govern > [!NOTE] > Identity Baseline governance does not replace the existing IT teams, processes, and procedures that allow your organization to manage and secure identity services. The primary purpose of this discipline is to identify potential identity-related business risks and provide risk-mitigation guidance to IT staff that are responsible for implementing, maintaining, and operating your identity management infrastructure. As you develop governance policies and processes make sure to involve relevant IT teams in your planning and review processes. -This section of the Cloud Adoption Framework outlines the approach to developing an Identity Baseline discipline as part of your cloud governance strategy. The primary audience for this guidance is your organization's cloud architects and other members of your Cloud Governance team. However, the decisions, policies, and processes that emerge from this discipline should involve engagement and discussions with relevant members of the IT teams responsible for implementing and managing your organization's identity management solutions. +This section of the Cloud Adoption Framework outlines the approach to developing an Identity Baseline discipline as part of your cloud governance strategy. The primary audience for this guidance is your organization's cloud architects and other members of your cloud governance team. However, the decisions, policies, and processes that emerge from this discipline should involve engagement and discussions with relevant members of the IT teams responsible for implementing and managing your organization's identity management solutions. If your organization lacks in-house expertise in Identity Baseline and security, consider engaging external consultants as a part of this discipline. Also consider engaging [Microsoft Consulting Services](https://www.microsoft.com/enterprise/services), the [Microsoft FastTrack](https://azure.microsoft.com/programs/azure-fasttrack) cloud adoption service, or other external cloud adoption experts to discuss concerns related to this discipline. @@ -32,7 +32,7 @@ Actionable policy statements and the resulting architecture requirements serve a ## Developing Identity Baseline governance policy statements -The following six steps offer examples and potential options to consider when developing Identity Baseline governance. Use each step as a starting point for discussions within your Cloud Governance team and with affected business, and IT teams across your organization to establish the policies and processes needed to manage identity-related risks. +The following six steps offer examples and potential options to consider when developing Identity Baseline governance. Use each step as a starting point for discussions within your cloud governance team and with affected business, and IT teams across your organization to establish the policies and processes needed to manage identity-related risks. diff --git a/docs/cloud-adoption/governance/identity-baseline/metrics-tolerance.md b/docs/cloud-adoption/governance/identity-baseline/metrics-tolerance.md index 725abe68f5a..b7bd74a6f15 100644 --- a/docs/cloud-adoption/governance/identity-baseline/metrics-tolerance.md +++ b/docs/cloud-adoption/governance/identity-baseline/metrics-tolerance.md @@ -53,7 +53,7 @@ Once you have a baseline, establish minimum benchmarks representing an unaccepta - **Authorization failure trigger.** A company where access attempts are rejected more than _x%_ of the time should invest in the Identity Baseline discipline to improve the application and updating of access controls, and identify potentially malicious access attempts. - **Compromised account trigger.** A company with more than _x_ compromised accounts should invest in the Identity Baseline discipline to improve the strength and security of authentication mechanisms and improve mechanisms to remediate risks related to compromised accounts. -The exact metrics and triggers you use to gauge risk tolerance and the level of investment in the Identity Baseline discipline will be specific to your organization, but the examples above should serve as a useful base for discussion within your Cloud Governance team. +The exact metrics and triggers you use to gauge risk tolerance and the level of investment in the Identity Baseline discipline will be specific to your organization, but the examples above should serve as a useful base for discussion within your cloud governance team. ## Next steps diff --git a/docs/cloud-adoption/governance/identity-baseline/policy-statements.md b/docs/cloud-adoption/governance/identity-baseline/policy-statements.md index e39459b7bfe..b6066b9d577 100644 --- a/docs/cloud-adoption/governance/identity-baseline/policy-statements.md +++ b/docs/cloud-adoption/governance/identity-baseline/policy-statements.md @@ -36,7 +36,7 @@ The following sample policy statements address common identity-related business **Policy statement:** The following policies will be implemented: - A least-privilege access model will be applied to any resources involved in mission-critical applications or protected data. -- Elevated permissions should be an exception, and any such exceptions must be recorded with the Cloud Governance team. Exceptions will be audited regularly. +- Elevated permissions should be an exception, and any such exceptions must be recorded with the cloud governance team. Exceptions will be audited regularly. **Potential design options:** Consult the [Azure Identity Management best practices](/azure/security/azure-security-identity-management-best-practices) to implement a role-based access control (RBAC) strategy that restricts access based on the [need to know](https://wikipedia.org/wiki/Need_to_know) and [least-privilege security](https://wikipedia.org/wiki/Principle_of_least_privilege) principles. diff --git a/docs/cloud-adoption/governance/index.md b/docs/cloud-adoption/governance/index.md index 3493858258f..dbe2b22875c 100644 --- a/docs/cloud-adoption/governance/index.md +++ b/docs/cloud-adoption/governance/index.md @@ -13,11 +13,11 @@ layout: LandingPage # Governance in the Microsoft Cloud Adoption Framework for Azure -The cloud creates new paradigms regarding the technologies that support the business. These new paradigms also cause shifts in how those technologies are adopted, managed, and governed. When entire datacenters can be destroyed and re-created with one line of code executed from an unattended process, we have to rethink traditional approaches. This is equally true when it comes to governance. +The cloud creates new paradigms for the technologies that support the business. These new paradigms also change how those technologies are adopted, managed, and governed. When entire datacenters can be virtually torn down and rebuilt with one line of code executed by an unattended process, we have to rethink traditional approaches. This is especially true for governance. ## Get started with cloud governance -Cloud governance is an iterative process. For organizations with existing policies that govern on-premises IT environments, cloud governance should complement those policies. However, the level of corporate policy integration between on-premises and the cloud varies depending on cloud governance maturity and digital estate in the cloud. As the cloud estate evolves over time, so do cloud governance processes and policies. The following exercises help you get started on an incremental growth journey. +Cloud governance is an iterative process. For organizations with existing policies that govern on-premises IT environments, cloud governance should complement those policies. However, the level of corporate policy integration between on-premises and the cloud varies depending on cloud governance maturity and a digital estate in the cloud. As the cloud estate evolves over time, so do cloud governance processes and policies. The following exercises help you start building your initial governance foundation. @@ -34,7 +34,7 @@ Cloud governance is an iterative process. For organizations with existing polici

Methodology

- Establish a basic understanding of the methodology that drives cloud governance within the Cloud Adoption Framework. + Establish a basic understanding of the methodology that drives cloud governance in the Cloud Adoption Framework.
@@ -71,8 +71,8 @@ Cloud governance is an iterative process. For organizations with existing polici
-

Initial governance best practice

- Begin your governance journey with a small, easily implemented set of governance tools. This initial best practice is called a minimum viable product (MVP). +

Initial governance foundation

+ Begin your governance journey with a small, easily implemented set of governance tools. This initial governance foundation is called a minimum viable product (MVP).
@@ -104,30 +104,30 @@ Cloud governance is an iterative process. For organizations with existing polici ## Objective of this content -The guidance in this section of the Cloud Adoption Framework is designed for two purposes: +The guidance in this section of the Cloud Adoption Framework serves two purposes: -- Provide examples of actionable customer journeys that represent common experiences that customers often encounter. Each of these examples encapsulates business risks, corporate policies for risk mitigation, and design guidance to implement technical solutions. By necessity, the design guidance is specific to Azure. All other guidance in these journeys could be applied as part of a cloud-agnostic or multicloud approach. -- Help you create personalized governance solutions that can meet a variety of business needs. These needs include the governance of multiple public clouds through detailed guidance on the development of corporate policies, processes, and tooling. +- Provide examples of actionable governance guides that represent common experiences often encountered by customers. Each example encapsulates business risks, corporate policies for risk mitigation, and design guidance for implementing technical solutions. By necessity, the design guidance is specific to Azure. All other content in these guides could be applied in a cloud-agnostic or multicloud approach. +- Help you create personalized governance solutions that meet a variety of business needs. These needs include the governance of multiple public clouds through detailed guidance on the development of corporate policies, processes, and tooling. -This content is intended for the cloud governance team. It's also relevant to cloud architects who need to develop a strong foundation in cloud governance. +This content is intended for use by the cloud governance team. It's also relevant to cloud architects who need to develop a strong foundation in cloud governance. ## Intended audience -The content in the Cloud Adoption Framework affects the business, technology, and culture of enterprises. This section of the Cloud Adoption Framework interacts heavily with IT security, IT governance, finance, line-of-business leaders, networking, identity, and cloud adoption teams. Various co-dependencies on these personnel require a facilitative approach by the cloud architects using this guidance. Facilitation with these teams might be a one-time effort. In some cases, it results in recurring interactions with these other personnel. +The content in the Cloud Adoption Framework affects the business, technology, and culture of enterprises. This section of the Cloud Adoption Framework interacts heavily with IT security, IT governance, finance, line-of-business leaders, networking, identity, and cloud adoption teams. Various dependencies on these personnel require a facilitative approach by the cloud architects using this guidance. Facilitation with these teams might be a one-time effort. In some cases, interactions with these other personnel will be ongoing. The cloud architect serves as the thought leader and facilitator to bring these audiences together. The content in this collection of guides is designed to help the cloud architect facilitate the right conversation, with the right audience, to drive necessary decisions. Business transformation that's empowered by the cloud depends on the cloud architect to help guide decisions throughout the business and IT. -**Cloud architect specialization in this section:** Each section of the Cloud Adoption Framework represents a different specialization or variant of the cloud architect role. This section of the Cloud Adoption Framework is designed for cloud architects with a passion for mitigating or reducing technical risks. Some cloud providers refer to these specialists as *cloud custodians*, but we prefer *cloud guardians* or, collectively, the *cloud governance team*. In each actionable customer journey, the articles show how the composition and role of the cloud governance team might change over time. +**Cloud architect specialization in this section:** Each section of the Cloud Adoption Framework represents a different specialization or variant of the cloud architect role. This section of the Cloud Adoption Framework is designed for cloud architects with a passion for mitigating or reducing technical risks. Some cloud providers refer to these specialists as *cloud custodians*, but we prefer *cloud guardians* or, collectively, the *cloud governance team*. In each actionable governance guide, the articles show how the composition and role of the cloud governance team might change over time. ## Use this guide If you want to follow this guide from beginning to end, this content aids in developing a robust cloud governance strategy in parallel with cloud implementation. The guidance walks you through the theory and implementation of such a strategy. -For a crash course on the theory and quick access to Azure implementation, get started with the [Overview of actionable governance journeys](./journeys/index.md). Through this guidance, you can start small and evolve your governance needs in parallel with cloud adoption efforts. +For a crash course on the theory and quick access to Azure implementation, get started with the [Governance guides overview](./journeys/index.md). Using this guidance, you can start small and evolve your governance needs in parallel with cloud adoption efforts. ## Next steps -Review the actionable governance journeys. +Review the actionable governance guides. > [!div class="nextstepaction"] -> [Actionable governance journeys](./journeys/index.md) +> [Review the governance guides](./journeys/index.md) diff --git a/docs/cloud-adoption/governance/journeys/index.md b/docs/cloud-adoption/governance/journeys/index.md index 18745d89378..6bd2bdcfd90 100644 --- a/docs/cloud-adoption/governance/journeys/index.md +++ b/docs/cloud-adoption/governance/journeys/index.md @@ -1,7 +1,7 @@ --- -title: "Actionable governance journeys" +title: "Actionable governance guides" titleSuffix: Microsoft Cloud Adoption Framework for Azure -description: Actionable governance journeys +description: Actionable governance guides author: BrianBlanchard ms.author: brblanch ms.date: 02/11/2019 @@ -12,45 +12,45 @@ ms.custom: governance layout: LandingPage --- -# Actionable governance journeys +# Actionable governance guides -The governance journeys in this section illustrate the incremental approach of the Cloud Adoption Framework governance model. You can establish an agile governance platform that will evolve to meet the needs of any cloud governance scenario. +The governance guides in this section illustrate the incremental approach of the Cloud Adoption Framework governance model. You can establish an agile governance platform that will evolve to meet the needs of any cloud governance scenario. ## Review and adopt cloud governance best practices -To start down an adoption path, choose one of the following journeys. Each journey outlines a series of best practices, based on a set of fictional customer experiences. For readers who are new to the incremental approach of the Cloud Adoption Framework governance model, it is advised that you review the high-level governance theory introduction below, before adopting either best practice. +To begin your cloud adoption journey, choose one of the following governance guides. Each guide outlines a set of best practices, based on a set of fictional customer experiences. For readers who are new to the incremental approach of the Cloud Adoption Framework governance model, review the high-level governance theory introduction below before adopting either set of best practices. @@ -59,7 +59,7 @@ To start down an adoption path, choose one of the following journeys. Each journ Adopting the cloud is a journey, not a destination. Along the way, there are clear milestones and tangible business benefits. However, the final state of cloud adoption is unknown when a company begins the journey. Cloud governance creates guardrails that keep the company on a safe path throughout the journey. -These governance journeys describe the experiences of fictional companies, based on the journeys of real customers. Each journey follows the customer through the governance aspects of their cloud adoption. +These governance guides describe the experiences of fictional companies, based on the journeys of real customers. Each journey follows the customer through the governance aspects of their cloud adoption. ### Establishing an end state @@ -67,7 +67,7 @@ A journey without a target destination is just wandering. It’s important to es ![Infographic of the Cloud Adoption Framework governance model](../../_images/operational-transformation-govern-highres.png) -The Cloud Adoption Framework governance model identifies key areas of importance during the journey. Each area relates to different types of risks the company must address as it adopts more cloud services. Within this framework, the governance journey identifies required actions for the Cloud Governance team. Along the way, each principle of the Cloud Adoption Framework governance model is described further. Broadly, these include: +The Cloud Adoption Framework governance model identifies key areas of importance during the journey. Each area relates to different types of risks the company must address as it adopts more cloud services. Within this framework, the governance journey identifies required actions for the cloud governance team. Along the way, each principle of the Cloud Adoption Framework governance model is described further. Broadly, these include: **Corporate policies:** Corporate policies drive cloud governance. The governance journey focuses on specific aspects of corporate policy: @@ -91,18 +91,18 @@ Because governance requirements will evolve throughout the cloud adoption journe An **incremental governance** approach empowers these traits. Incremental governance relies on a small set of corporate policies, processes, and tools to establish a foundation for adoption and governance. That foundation is called a **minimum viable product (MVP)**. An MVP allows the governance team to quickly incorporate governance into implementations throughout the adoption lifecycle. An MVP can be established at any point during the cloud adoption process. However, it’s a good practice to adopt an MVP as early as possible. -The ability to respond rapidly to changing risks empowers the Cloud Governance team to engage in new ways. The Cloud Governance team can join the Cloud Strategy team as scouts, moving ahead of the cloud adoption teams, plotting routes, and quickly establishing guardrails to manage risks associated with the adoption plans. These just-in-time governance layers are known as **governance evolutions**. With this approach, governance strategy evolves one step ahead of the cloud adoption teams. +The ability to respond rapidly to changing risks empowers the cloud governance team to engage in new ways. The cloud governance team can join the cloud strategy team as scouts, moving ahead of the cloud adoption teams, plotting routes, and quickly establishing guardrails to manage risks associated with the adoption plans. These just-in-time governance layers are known as **governance evolutions**. With this approach, governance strategy evolves one step ahead of the cloud adoption teams. The following diagram shows a simple governance MVP and three governance evolutions. During the evolutions, additional corporate policies are defined to remediate new risks. The Deployment Acceleration discipline then applies those changes across each deployment. ![Example of Incremental Governance evolutions](../../_images/governance/incremental-governance-example.png) > [!NOTE] -> Governance is not a replacement for key functions such as security, networking, identity, finance, DevOps, or operations. Along the way, there will be interactions with and dependencies on members from each function. Those members should be included on the Cloud Governance team to accelerate decisions and actions. +> Governance is not a replacement for key functions such as security, networking, identity, finance, DevOps, or operations. Along the way, there will be interactions with and dependencies on members from each function. Those members should be included on the cloud governance team to accelerate decisions and actions. ## Choosing a governance journey -The journeys demonstrate how to implement a governance MVP. From there, each journey shows how the Cloud Governance team can work ahead of the cloud adoption teams as a partner to accelerate adoption efforts. The Cloud Adoption Framework governance model guides the application of governance from foundation through subsequent evolutions. +The journeys demonstrate how to implement a governance MVP. From there, each journey shows how the cloud governance team can work ahead of the cloud adoption teams as a partner to accelerate adoption efforts. The Cloud Adoption Framework governance model guides the application of governance from foundation through subsequent improvements. To begin a governance journey, choose one of the two options below. The options are based on synthesized customer experiences. The titles are based on the size of the enterprise for ease of navigation. However, the reader's decision may be more complex. The following tables outline the differences between the two options. diff --git a/docs/cloud-adoption/governance/journeys/large-enterprise/best-practice-explained.md b/docs/cloud-adoption/governance/journeys/large-enterprise/best-practice-explained.md index 133d6309f58..766ad14e5e4 100644 --- a/docs/cloud-adoption/governance/journeys/large-enterprise/best-practice-explained.md +++ b/docs/cloud-adoption/governance/journeys/large-enterprise/best-practice-explained.md @@ -15,9 +15,9 @@ ms.custom: governance The governance journey starts with a set of initial [corporate policies](./initial-corporate-policy.md). These policies are used to establish a minimum viable product (MVP) for governance that reflects [best practices](./index.md). -In this article, we discuss the high-level strategies that are required to create a governance MVP. The core of the governance MVP is the [Deployment Acceleration](../../deployment-acceleration/index.md) discipline. The tools and patterns applied at this stage will enable the incremental evolutions needed to expand governance in the future. +In this article, we discuss the high-level strategies that are required to create a governance MVP. The core of the governance MVP is the [Deployment Acceleration](../../deployment-acceleration/index.md) discipline. The tools and patterns applied at this stage will enable the incremental improvements needed to expand governance in the future. -## Governance MVP (Cloud Adoption Foundation) +## Governance MVP (initial governance foundation) Rapid adoption of governance and corporate policy is achievable, thanks to a few simple principles and cloud-based governance tooling. These are the first of the three governance disciplines to approach in any governance process. Each discipline will be explained further on in this article. @@ -27,7 +27,7 @@ To establish the starting point, this article will discuss the high-level strate ## Implementation process -The implementation of the governance MVP has dependencies on Identity, Security, and Networking. Once the dependencies are resolved, the Cloud Governance team will decide a few aspects of governance. The decisions from the Cloud Governance team and from supporting teams will be implemented through a single package of enforcement assets. +The implementation of the governance MVP has dependencies on Identity, Security, and Networking. Once the dependencies are resolved, the cloud governance team will decide a few aspects of governance. The decisions from the cloud governance team and from supporting teams will be implemented through a single package of enforcement assets. ![Example of an incremental governance MVP](../../../_images/governance/governance-mvp-implementation-flow.png) @@ -42,7 +42,7 @@ This implementation can also be described using a simple checklist: ## Application of governance-defined patterns -The Cloud Governance team will be responsible for the following decisions and implementations. Many will require inputs from other teams, but the Cloud Governance team is likely to own both the decision and implementation. The following sections outline the decisions made for this use case and details of each decision. +The cloud governance team will be responsible for the following decisions and implementations. Many will require inputs from other teams, but the cloud governance team is likely to own both the decision and implementation. The following sections outline the decisions made for this use case and details of each decision. ### Subscription design @@ -88,19 +88,19 @@ Logging and reporting decisions determine how your store log data and how the mo ## Evolution of governance processes -Some of the policy statements cannot or should not be controlled by automated tooling. Other policies will require periodic effort from IT Security and on-premises Identity Baseline teams. The Cloud Governance team will need to oversee the following processes to implement the last eight policy statements: +Some of the policy statements cannot or should not be controlled by automated tooling. Other policies will require periodic effort from IT Security and on-premises Identity Baseline teams. The cloud governance team will need to oversee the following processes to implement the last eight policy statements: -**Corporate policy changes:** The Cloud Governance team will make changes to the governance MVP design to adopt the new policies. The value of the governance MVP is that it will allow for the automatic enforcement of the new policies. +**Corporate policy changes:** The cloud governance team will make changes to the governance MVP design to adopt the new policies. The value of the governance MVP is that it will allow for the automatic enforcement of the new policies. -**Adoption acceleration:** The Cloud Governance team has been reviewing deployment scripts across multiple teams. They've maintained a set of scripts that serve as deployment templates. Those templates can be used by the cloud adoption teams and DevOps teams to more quickly define deployments. Each script contains the requirements for enforcing governance policies, and additional effort from cloud adoption engineers is not needed. As the curators of these scripts, they can implement policy changes more quickly. Additionally, they are viewed as accelerators of adoption. This ensures consistent deployments without strictly enforcing adherence. +**Adoption acceleration:** The cloud governance team has been reviewing deployment scripts across multiple teams. They've maintained a set of scripts that serve as deployment templates. Those templates can be used by the cloud adoption teams and DevOps teams to more quickly define deployments. Each script contains the requirements for enforcing governance policies, and additional effort from cloud adoption engineers is not needed. As the curators of these scripts, they can implement policy changes more quickly. Additionally, they are viewed as accelerators of adoption. This ensures consistent deployments without strictly enforcing adherence. -**Engineer training:** The Cloud Governance team offers bimonthly training sessions and has created two videos for engineers. Both resources help engineers get up to speed quickly on the governance culture and how deployments are performed. The team is adding training assets to demonstrate the difference between production and nonproduction deployments, which helps engineers understand how the new policies affect adoption. This ensures consistent deployments without strictly enforcing adherence. +**Engineer training:** The cloud governance team offers bimonthly training sessions and has created two videos for engineers. Both resources help engineers get up to speed quickly on the governance culture and how deployments are performed. The team is adding training assets to demonstrate the difference between production and nonproduction deployments, which helps engineers understand how the new policies affect adoption. This ensures consistent deployments without strictly enforcing adherence. -**Deployment planning:** Before deploying any asset containing protected data, the Cloud Governance team will be responsible for reviewing deployment scripts to validate governance alignment. Existing teams with previously approved deployments will be audited using programmatic tooling. +**Deployment planning:** Before deploying any asset containing protected data, the cloud governance team will be responsible for reviewing deployment scripts to validate governance alignment. Existing teams with previously approved deployments will be audited using programmatic tooling. -**Monthly audit and reporting:** Each month, the Cloud Governance team runs an audit of all cloud deployments to validate continued alignment to policy. When deviations are discovered, they are documented and shared with the cloud adoption teams. When enforcement doesn't risk a business interruption or data leak, the policies are automatically enforced. At the end of the audit, the Cloud Governance team compiles a report for the Cloud Strategy team and each cloud adoption team to communicate overall adherence to policy. The report is also stored for auditing and legal purposes. +**Monthly audit and reporting:** Each month, the cloud governance team runs an audit of all cloud deployments to validate continued alignment to policy. When deviations are discovered, they are documented and shared with the cloud adoption teams. When enforcement doesn't risk a business interruption or data leak, the policies are automatically enforced. At the end of the audit, the cloud governance team compiles a report for the cloud strategy team and each cloud adoption team to communicate overall adherence to policy. The report is also stored for auditing and legal purposes. -**Quarterly policy review:** Each quarter, the Cloud Governance team and Cloud Strategy team to review audit results and suggest changes to corporate policy. Many of those suggestions are the result of continuous improvements and the observation of usage patterns. Approved policy changes are integrated into governance tooling during subsequent audit cycles. +**Quarterly policy review:** Each quarter, the cloud governance team and the cloud strategy team to review audit results and suggest changes to corporate policy. Many of those suggestions are the result of continuous improvements and the observation of usage patterns. Approved policy changes are integrated into governance tooling during subsequent audit cycles. ## Alternative patterns @@ -117,9 +117,9 @@ If any of the patterns chosen in this governance journey don't align with the re ## Next steps -Once this guidance is implemented, each cloud adoption team can proceed with a solid governance foundation. The Cloud Governance team will work in parallel to continually update the corporate policies and governance disciplines. +Once this guidance is implemented, each cloud adoption team can proceed with a solid governance foundation. The cloud governance team will work in parallel to continually update the corporate policies and governance disciplines. -Both teams will use the tolerance indicators to identify the next evolution needed to continue supporting cloud adoption. The next step for the company in this journey is to evolve their governance baseline to support applications with legacy or third-party multi-factor authentication requirements. +Both teams will use the tolerance indicators to identify the next set of improvements needed to continue supporting cloud adoption. The next step for the company in this journey is to evolve their governance baseline to support applications with legacy or third-party multi-factor authentication requirements. > [!div class="nextstepaction"] > [Identity Baseline evolution](./identity-baseline-evolution.md) diff --git a/docs/cloud-adoption/governance/journeys/large-enterprise/cost-management-evolution.md b/docs/cloud-adoption/governance/journeys/large-enterprise/cost-management-evolution.md index b5d48ef7a02..f2d7db52257 100644 --- a/docs/cloud-adoption/governance/journeys/large-enterprise/cost-management-evolution.md +++ b/docs/cloud-adoption/governance/journeys/large-enterprise/cost-management-evolution.md @@ -17,7 +17,7 @@ This article evolves the narrative by adding cost controls to the minimum viable ## Evolution of the narrative -Adoption has grown beyond the tolerance indicator defined in the governance MVP. The increases in spending now justifies an investment of time from the Cloud Governance team to monitor and control spending patterns. +Adoption has grown beyond the tolerance indicator defined in the governance MVP. The increases in spending now justifies an investment of time from the cloud governance team to monitor and control spending patterns. As a clear driver of innovation, IT is no longer seen primarily as a cost center. As the IT organization delivers more value, the CIO and CFO agree that the time is right to evolve the role IT plays in the company. Amongst other changes, the CFO wants to test a direct pay approach to cloud accounting for the Canadian branch of one of the business units. One of the two retired datacenters was exclusively hosted assets for that business unit’s Canadian operations. In this model, the business unit’s Canadian subsidiary will be billed directly for the operating expenses related to the hosted assets. This model allows IT to focus less on managing someone else’s spending and more on creating value. However, before this transition can begin Cost Management tooling needs to be in place. @@ -49,7 +49,7 @@ This business risk can be expanded into a few technical risks: The following changes to policy will help remediate the new risks and guide implementation. -1. All cloud costs should be monitored against plan on a weekly basis by the Cloud Governance team. Reporting on deviations between cloud costs and plan is to be shared with IT leadership and finance monthly. All cloud costs and plan updates should be reviewed with IT leadership and finance monthly. +1. All cloud costs should be monitored against plan on a weekly basis by the cloud governance team. Reporting on deviations between cloud costs and plan is to be shared with IT leadership and finance monthly. All cloud costs and plan updates should be reviewed with IT leadership and finance monthly. 2. All costs must be allocated to a business function for accountability purposes. 3. Cloud assets should be continually monitored for optimization opportunities. 4. Cloud Governance tooling must limit Asset sizing options to an approved list of configurations. The tooling must ensure that all assets are discoverable and tracked by the cost monitoring solution. @@ -62,7 +62,7 @@ This section of the article will evolve the governance MVP design to include new 1. Changes in the Azure Enterprise Portal to bill the Department administrator for the Canadian deployment. 2. Implement Azure Cost Management. - 1. Establish the right level of access scope to align with the subscription pattern and resource grouping pattern. Assuming alignment with the governance MVP defined in prior articles, this would require **Enrollment Account Scope** access for the Cloud Governance team executing on high-level reporting. Additional teams outside of governance, like the Canadian procurement team, will require **Resource Group Scope** access. + 1. Establish the right level of access scope to align with the subscription pattern and resource grouping pattern. Assuming alignment with the governance MVP defined in prior articles, this would require **Enrollment Account Scope** access for the cloud governance team executing on high-level reporting. Additional teams outside of governance, like the Canadian procurement team, will require **Resource Group Scope** access. 2. Establish a budget in Azure Cost Management. 3. Review and act on initial recommendations. It's recommended to have a recurring process to support the reporting process. 4. Configure and execute Azure Cost Management Reporting, both initial and recurring. diff --git a/docs/cloud-adoption/governance/journeys/large-enterprise/identity-baseline-evolution.md b/docs/cloud-adoption/governance/journeys/large-enterprise/identity-baseline-evolution.md index 4f385c4f5ac..d246449526b 100644 --- a/docs/cloud-adoption/governance/journeys/large-enterprise/identity-baseline-evolution.md +++ b/docs/cloud-adoption/governance/journeys/large-enterprise/identity-baseline-evolution.md @@ -26,9 +26,9 @@ The business justification for the cloud migration of the two datacenters was ap The first two roadblocks are being managed in parallel. This article will address the resolution of the third and fourth roadblocks. -### Evolution of the Cloud Governance team +### Evolution of the cloud governance team -The Cloud Governance team is expanding. Given the need for additional support regarding identity management, a systems administrator from the Identity Baseline team now participates in a weekly meeting to keep the existing team members aware of changes. +The cloud governance team is expanding. Given the need for additional support regarding identity management, a systems administrator from the Identity Baseline team now participates in a weekly meeting to keep the existing team members aware of changes. ### Evolution of the current state diff --git a/docs/cloud-adoption/governance/journeys/large-enterprise/index.md b/docs/cloud-adoption/governance/journeys/large-enterprise/index.md index daefc2f5574..2817744fd93 100644 --- a/docs/cloud-adoption/governance/journeys/large-enterprise/index.md +++ b/docs/cloud-adoption/governance/journeys/large-enterprise/index.md @@ -13,7 +13,7 @@ ms.custom: governance # Large enterprise governance journey -## Best practice overview +## Overview of best practices This governance journey follows the experiences of a fictional company through various stages of governance maturity. It is based on real customer journeys. The suggested best practices are based on the constraints and needs of the fictional company. @@ -22,9 +22,9 @@ As a quick starting point, this overview defines a minimum viable product (MVP) > [!WARNING] > This MVP is a baseline starting point, based on a set of assumptions. Even this minimal set of best practices is based on corporate policies driven by unique business risks and risk tolerances. To see if these assumptions apply to you, read the [longer narrative](./narrative.md) that follows this article. -### Governance best practice +### Governance best practices -This best practice serves as a foundation that an organization can use to quickly and consistently add governance guardrails across multiple Azure subscriptions. +These best practices serve as a foundation for an organization to quickly and consistently add governance guardrails across multiple Azure subscriptions. ### Resource organization @@ -32,7 +32,7 @@ The following diagram shows the governance MVP hierarchy for organizing resource ![Resource Organization diagram](../../../_images/governance/resource-organization.png) -Every application should be deployed in the proper area of the management group, subscription, and resource group hierarchy. During deployment planning, the Cloud Governance team will create the necessary nodes in the hierarchy to empower the cloud adoption teams. +Every application should be deployed in the proper area of the management group, subscription, and resource group hierarchy. During deployment planning, the cloud governance team will create the necessary nodes in the hierarchy to empower the cloud adoption teams. 1. A management group for each business unit with a detailed hierarchy that reflects geography then environment type (for example, Production or Nonproduction). 2. A subscription for each unique combination of business unit, geography, environment, and "Application Categorization." diff --git a/docs/cloud-adoption/governance/journeys/large-enterprise/initial-corporate-policy.md b/docs/cloud-adoption/governance/journeys/large-enterprise/initial-corporate-policy.md index 9130f419d87..4da0d6ad4ca 100644 --- a/docs/cloud-adoption/governance/journeys/large-enterprise/initial-corporate-policy.md +++ b/docs/cloud-adoption/governance/journeys/large-enterprise/initial-corporate-policy.md @@ -18,11 +18,11 @@ The following corporate policy defines the initial governance position, which is > [!NOTE] >The corporate policy is not a technical document, but it drives many technical decisions. The governance MVP described in the [overview](./index.md) ultimately derives from this policy. Before implementing a governance MVP, your organization should develop a corporate policy based on your own objectives and business risks. -## Cloud Governance team +## Cloud governance team The CIO recently held a meeting with the IT Governance team to understand the history of the PII and mission-critical policies and review the effect of changing those policies. She also discussed the overall potential of the cloud for IT and the company. -After the meeting, two members of the IT Governance team requested permission to research and support the cloud planning efforts. Recognizing the need for governance and an opportunity to limit shadow IT, the Director of IT Governance supported this idea. With that, the Cloud Governance team was born. Over the next several months, they will inherit the cleanup of many mistakes made during exploration in the cloud from a governance perspective. This will earn them the moniker of _cloud custodians_. In later evolutions, this journey will show how their roles change over time. +After the meeting, two members of the IT Governance team requested permission to research and support the cloud planning efforts. Recognizing the need for governance and an opportunity to limit shadow IT, the Director of IT Governance supported this idea. With that, the cloud governance team was born. Over the next several months, they will inherit the cleanup of many mistakes made during exploration in the cloud from a governance perspective. This will earn them the moniker of _cloud custodians_. In later evolutions, this journey will show how their roles change over time. [!INCLUDE [business-risk](../../../includes/governance/business-risks.md)] @@ -39,7 +39,7 @@ The current risk tolerance is high and the appetite for investing in cloud gover ## Next steps -This corporate policy prepares the Cloud Governance team to implement the governance MVP, which will be the foundation for adoption. The next step is to implement this MVP. +This corporate policy prepares the cloud governance team to implement the governance MVP, which will be the foundation for adoption. The next step is to implement this MVP. > [!div class="nextstepaction"] > [Best practice explained](./best-practice-explained.md) diff --git a/docs/cloud-adoption/governance/journeys/large-enterprise/multiple-layers-of-governance.md b/docs/cloud-adoption/governance/journeys/large-enterprise/multiple-layers-of-governance.md index fd1a913e0d1..5d7b50f74c5 100644 --- a/docs/cloud-adoption/governance/journeys/large-enterprise/multiple-layers-of-governance.md +++ b/docs/cloud-adoption/governance/journeys/large-enterprise/multiple-layers-of-governance.md @@ -13,7 +13,7 @@ ms.custom: governance # Multiple layers of governance in large enterprises -When large enterprises require multiple layers of governance, there are greater levels of complexity that must be factored into the governance MVP and later governance evolutions. +When large enterprises require multiple layers of governance, there are greater levels of complexity that must be factored into the governance MVP and later governance improvements. A few common examples of such complexities include: @@ -29,9 +29,9 @@ Large established enterprises often have teams or employees who focus on the dis In many large enterprises, the Five Disciplines of Cloud Governance can be blockers to adoption. Developing cloud expertise in identity, security, operations, deployments, and configuration across an enterprise takes time. Holistically implementing IT governance policy and IT security can slow innovation by months or even years. Balancing the business need to innovate and the governance need to protect existing resources is delicate. -The inherent capabilities of the cloud can remove blockers to innovation but increase risks. In this governance journey, we showed how the example company created guardrails to manage the risks. Rather than tackling each of the disciplines required to protect the environment, the Cloud Governance team leads a risk-based approach to govern what could be deployed, while the other teams build the necessary cloud maturities. Most importantly, as each team reaches cloud maturity, governance applies their solutions holistically. As each team matures and adds to the overall solution, the Cloud Governance team can open stage gates, allowing additional innovation and adoption to thrive. +The inherent capabilities of the cloud can remove blockers to innovation but increase risks. In this governance journey, we showed how the example company created guardrails to manage the risks. Rather than tackling each of the disciplines required to protect the environment, the cloud governance team leads a risk-based approach to govern what could be deployed, while the other teams build the necessary cloud maturities. Most importantly, as each team reaches cloud maturity, governance applies their solutions holistically. As each team matures and adds to the overall solution, the cloud governance team can open stage gates, allowing additional innovation and adoption to thrive. -This model illustrates the growth of a partnership between the Cloud Governance team and existing enterprise teams (Security, IT Governance, Networking, Identity, and others). The journey starts with the governance MVP and grows to a holistic end state through governance evolutions. +This model illustrates the growth of a partnership between the cloud governance team and existing enterprise teams (Security, IT Governance, Networking, Identity, and others). The journey starts with the governance MVP and grows to a holistic end state through governance evolutions. ## Requirements to supporting such a team sport @@ -51,4 +51,4 @@ The important aspect of each of these tools is the ability to apply multiple blu - **Regional or Business Unit IT:** Various IT teams can apply an additional layer of governance by creating their own blueprint. Those blueprints would create additive policies and standards. Once developed, Corporate IT could apply those blueprints to the applicable nodes within the management group hierarchy. - **Cloud adoption teams:** Detailed decisions and implementation about applications or workloads can be made by each cloud adoption team, within the context of governance requirements. At times the team can also request additional Azure Resource Consistency templates to accelerate adoption efforts. -The details regarding governance implementation at each level will require coordination between each team. The governance MVP and governance evolutions outlined in this journey can aid in aligning that coordination. +The details regarding governance implementation at each level will require coordination between each team. The governance MVP and governance improvements outlined in this journey can aid in aligning that coordination. diff --git a/docs/cloud-adoption/governance/journeys/large-enterprise/resource-consistency-evolution.md b/docs/cloud-adoption/governance/journeys/large-enterprise/resource-consistency-evolution.md index 46848fd0672..b7bf88e25cf 100644 --- a/docs/cloud-adoption/governance/journeys/large-enterprise/resource-consistency-evolution.md +++ b/docs/cloud-adoption/governance/journeys/large-enterprise/resource-consistency-evolution.md @@ -54,7 +54,7 @@ This business risk can be expanded into several technical risks: The following changes to policy will help remediate the new risks and guide implementation. The list looks long, but the adoption of these policies may be easier than it would appear. -1. All deployed assets must be categorized by criticality and data classification. Classifications are to be reviewed by the Cloud Governance team and the application owner before deployment to the cloud. +1. All deployed assets must be categorized by criticality and data classification. Classifications are to be reviewed by the cloud governance team and the application owner before deployment to the cloud. 2. Subnets containing mission-critical applications must be protected by a firewall solution capable of detecting intrusions and responding to attacks. 3. Governance tooling must audit and enforce network configuration requirements defined by the Security Baseline team. 4. Governance tooling must validate that all assets related to mission-critical applications or protected data are included in monitoring for resource depletion and optimization. @@ -62,13 +62,13 @@ The following changes to policy will help remediate the new risks and guide impl 6. Governance process must validate that backup, recovery, and SLA adherence are properly implemented for mission-critical applications and protected data. 7. Governance tooling must limit virtual machine deployment to approved images only. 8. Governance tooling must enforce that automatic updates are **prevented** on all deployed assets that support mission-critical applications. Violations must be reviewed with operational management teams and remediated in accordance with operations policies. Assets that are not automatically updated must be included in processes owned by IT operations. -9. Governance tooling must validate tagging related to cost, criticality, SLA, application, and data classification. All values must align to predefined values managed by the Cloud Governance team. +9. Governance tooling must validate tagging related to cost, criticality, SLA, application, and data classification. All values must align to predefined values managed by the cloud governance team. 10. Governance processes must include audits at the point of deployment and at regular cycles to ensure consistency across all assets. 11. Trends and exploits that could affect cloud deployments should be reviewed regularly by the security team to provide updates to Security Baseline tooling used in the cloud. 12. Before release into production, all mission-critical applications and protected data must be added to the designated operational monitoring solution. Assets that cannot be discovered by the chosen IT operations tooling cannot be released for production use. Any changes required to make the assets discoverable must be made to the relevant deployment processes to ensure assets will be discoverable in future deployments. 13. When discovered, asset sizing is to be validated by operational management teams to validate that the asset meets performance requirements. -14. Deployment tooling must be approved by the Cloud Governance team to ensure ongoing governance of deployed assets. -15. Deployment scripts must be maintained in central repository accessible by the Cloud Governance team for periodic review and auditing. +14. Deployment tooling must be approved by the cloud governance team to ensure ongoing governance of deployed assets. +15. Deployment scripts must be maintained in central repository accessible by the cloud governance team for periodic review and auditing. 16. Governance review processes must validate that deployed assets are properly configured in alignment with SLA and recovery requirements. ## Evolution of the best practices @@ -79,8 +79,8 @@ Following the experience of this fictional example, it is assumed that the Prote **Corporate IT subscription:** Add the following to the Corporate IT subscription, which acts as a hub. -1. As an external dependency, the Cloud Operations team will need to define operational monitoring tooling, business continuity and disaster recovery (BCDR) tooling, and automated remediation tooling. The Cloud Governance team can then support necessary discovery processes. - 1. In this use case, the Cloud Operations team chose Azure Monitor as the primary tool for monitoring mission-critical applications. +1. As an external dependency, the cloud operations team will need to define operational monitoring tooling, business continuity and disaster recovery (BCDR) tooling, and automated remediation tooling. The cloud governance team can then support necessary discovery processes. + 1. In this use case, the cloud operations team chose Azure Monitor as the primary tool for monitoring mission-critical applications. 2. The team also chose Azure Site Recovery as the primary BCDR tooling. 2. Azure Site Recovery implementation. 1. Define and deploy Azure Vault for backup and recovery processes. @@ -107,7 +107,7 @@ Adding these processes and changes to the governance MVP helps remediate many of ## Next steps -As cloud adoption continues to evolve and deliver additional business value, the risks and cloud governance needs will also evolve. For the fictional company in this journey, the next trigger is when the scale of deployment exceeds 1,000 assets to the cloud or monthly spending exceeds $10,000 USD per month. At this point, the Cloud Governance team adds Cost Management controls. +As cloud adoption continues to evolve and deliver additional business value, the risks and cloud governance needs will also evolve. For the fictional company in this journey, the next trigger is when the scale of deployment exceeds 1,000 assets to the cloud or monthly spending exceeds $10,000 USD per month. At this point, the cloud governance team adds Cost Management controls. > [!div class="nextstepaction"] > [Cost Management evolution](./cost-management-evolution.md) diff --git a/docs/cloud-adoption/governance/journeys/large-enterprise/security-baseline-evolution.md b/docs/cloud-adoption/governance/journeys/large-enterprise/security-baseline-evolution.md index 6d1b02fb480..4c72168bf57 100644 --- a/docs/cloud-adoption/governance/journeys/large-enterprise/security-baseline-evolution.md +++ b/docs/cloud-adoption/governance/journeys/large-enterprise/security-baseline-evolution.md @@ -21,9 +21,9 @@ The CIO has spent months collaborating with colleagues and the company’s legal For the past 12 months, the cloud adoption teams have cleared most of the 5,000 assets from the two datacenters to be retired. The 350 incompatible assets were moved to an alternate datacenter. Only the 1,250 virtual machines that contain protected data remain. -### Evolution of the Cloud Governance team +### Evolution of the cloud governance team -The Cloud Governance team continues to evolve along with the narrative. The two founding members of the team are now among the most respected cloud architects in the company. The collection of configuration scripts has grown as new teams tackle innovative new deployments. The Cloud Governance team has also grown. Most recently, members of the IT Operations team have joined Cloud Governance team activities to prepare for cloud operations. The cloud architects who helped foster this community are seen both as cloud guardians and cloud accelerators. +The cloud governance team continues to evolve along with the narrative. The two founding members of the team are now among the most respected cloud architects in the company. The collection of configuration scripts has grown as new teams tackle innovative new deployments. The cloud governance team has also grown. Most recently, members of the IT Operations team have joined cloud governance team activities to prepare for cloud operations. The cloud architects who helped foster this community are seen both as cloud guardians and cloud accelerators. While the difference is subtle, it is an important distinction when building a governance-focused IT culture. A cloud custodian cleans up the messes made by innovative cloud architects, and the two roles have natural friction and opposing objectives. A cloud guardian helps keep the cloud safe, so other cloud architects can move more quickly with fewer messes. A cloud accelerator performs both functions but is also involved in the creation of templates to accelerate deployment and adoption, becoming an innovation accelerator as well as a defender of the Five Disciplines of Cloud Governance. @@ -43,8 +43,8 @@ Since then, some things have changed that will affect governance: - Early experiments from the application development and BI teams have shown potential improvements in customer experiences and data-driven decisions. Both teams would like to expand adoption of the cloud over the next 18 months by deploying those solutions to production. - IT has developed a business justification to migrate five more datacenters to Azure, which will further decrease IT costs and provide greater business agility. While smaller in scale, the retirement of those datacenters is expected to double the total cost savings. -- Capital expense and operating expense budgets have approved to implement the required security and governance policies, tools, and processes. The expected cost savings from the datacenter retirement are more than enough to pay for this new initiative. IT and business leadership are confident this investment will accelerate the realization of returns in other areas. The grassroots Cloud Governance team became a recognized team with dedicated leadership and staffing. -- Collectively, the cloud adoption teams, Cloud Governance team, IT Security team, and IT Governance team will implement security and governance requirements to allow cloud adoption teams to migrate protected data into the cloud. +- Capital expense and operating expense budgets have approved to implement the required security and governance policies, tools, and processes. The expected cost savings from the datacenter retirement are more than enough to pay for this new initiative. IT and business leadership are confident this investment will accelerate the realization of returns in other areas. The grassroots cloud governance team became a recognized team with dedicated leadership and staffing. +- Collectively, the cloud adoption teams, the cloud governance team, the IT security team, and the IT governance team will implement security and governance requirements to allow cloud adoption teams to migrate protected data into the cloud. ## Evolution of tangible risks @@ -69,24 +69,24 @@ This business risk can be expanded into a few technical risks: The following changes to policy will help remediate the new risks and guide implementation. The list looks long, but the adoption of these policies may be easier than it would appear. -1. All deployed assets must be categorized by criticality and data classification. Classifications are to be reviewed by the Cloud Governance team and the application before deployment to the cloud. +1. All deployed assets must be categorized by criticality and data classification. Classifications are to be reviewed by the cloud governance team and the application before deployment to the cloud. 2. Applications that store or access protected data are to be managed differently than those that don’t. At a minimum, they should be segmented to avoid unintended access of protected data. 3. All protected data must be encrypted when at rest. -4. Elevated permissions in any segment containing protected data should be an exception. Any such exceptions will be recorded with the Cloud Governance team and audited regularly. +4. Elevated permissions in any segment containing protected data should be an exception. Any such exceptions will be recorded with the cloud governance team and audited regularly. 5. Network subnets containing protected data must be isolated from any other subnets. Network traffic between protected data subnets will be audited regularly. 6. No subnet containing protected data can be directly accessed over the public internet or across datacenters. Access to these subnets must be routed through intermediate subnets. All access into these subnets must come through a firewall solution that can perform packet scanning and blocking functions. 7. Governance tooling must audit and enforce network configuration requirements defined by the Security Management team. 8. Governance tooling must limit VM deployment to approved images only. 9. Whenever possible, node configuration management should apply policy requirements to the configuration of any guest operating system. Node configuration management should respect the existing investment in Group Policy Object (GPO) for resource configuration. 10. Governance tooling will audit that automatic updates are enabled on all deployed assets. When possible, automatic updates will be enforced. When not enforced by tooling, node-level violations must be reviewed with operational management teams and remediated in accordance with operations policies. Assets that are not automatically updated must be included in processes owned by IT Operations. -11. Creation of new subscriptions or management groups for any mission-critical applications or protected data requires a review from the Cloud Governance team to ensure proper blueprint assignment. +11. Creation of new subscriptions or management groups for any mission-critical applications or protected data requires a review from the cloud governance team to ensure proper blueprint assignment. 12. A least-privilege access model will be applied to any subscription that contains mission-critical applications or protected data. 13. The cloud vendor must be capable of integrating encryption keys managed by the existing on-premises solution. 14. The cloud vendor must be capable of supporting the existing edge device solution and any required configurations to protect any publicly exposed network boundary. 15. The cloud vendor must be capable of supporting a shared connection to the global WAN, with data transmission routed through the existing edge device solution. 16. Trends and exploits that could affect cloud deployments should be reviewed regularly by the security team to provide updates to Security Baseline tooling used in the cloud. -17. Deployment tooling must be approved by the Cloud Governance team to ensure ongoing governance of deployed assets. -18. Deployment scripts must be maintained in a central repository accessible by the Cloud Governance team for periodic review and auditing. +17. Deployment tooling must be approved by the cloud governance team to ensure ongoing governance of deployed assets. +18. Deployment scripts must be maintained in a central repository accessible by the cloud governance team for periodic review and auditing. 19. Governance processes must include audits at the point of deployment and at regular cycles to ensure consistency across all assets. 20. Deployment of any applications that require customer authentication must use an approved identity provider that is compatible with the primary identity provider for internal users. 21. Cloud Governance processes must include quarterly reviews with Identity Baseline teams to identify malicious actors or usage patterns that should be prevented by cloud asset configuration. @@ -97,7 +97,7 @@ This section of the article will evolve the governance MVP design to include new The new best practices fall into two categories: Corporate IT (hub) and Cloud Adoption (spoke). -**Establishing a corporate IT hub and spoke subscription to centralize the Security Baseline:** In this best practice, the existing governance capacity is wrapped by a [hub and spoke topology with shared services][shared-services], with a few key additions from the Cloud Governance team. +**Establishing a corporate IT hub and spoke subscription to centralize the Security Baseline:** In this best practice, the existing governance capacity is wrapped by a [hub and spoke topology with shared services][shared-services], with a few key additions from the cloud governance team. 1. Azure DevOps repository. Create a repository in Azure DevOps to store and version all relevant Azure Resource Manager templates and scripted configurations. 2. Hub and spoke template. diff --git a/docs/cloud-adoption/governance/journeys/small-to-medium-enterprise/best-practice-explained.md b/docs/cloud-adoption/governance/journeys/small-to-medium-enterprise/best-practice-explained.md index 1207a57c14c..4bf62a0181c 100644 --- a/docs/cloud-adoption/governance/journeys/small-to-medium-enterprise/best-practice-explained.md +++ b/docs/cloud-adoption/governance/journeys/small-to-medium-enterprise/best-practice-explained.md @@ -17,7 +17,7 @@ The governance journey starts with a set of initial [corporate policies](./initi In this article, we discuss the high-level strategies that are required to create a governance MVP. The core of the governance MVP is the [Deployment Acceleration](../../deployment-acceleration/index.md) discipline. The tools and patterns applied at this stage will enable the incremental evolutions needed to expand governance in the future. -## Governance MVP (Cloud Adoption Foundation) +## Governance MVP (initial governance foundation) Rapid adoption of governance and corporate policy is achievable, thanks to a few simple principles and cloud-based governance tooling. These are the first three disciplines to approach in any governance process. Each discipline will be further described in this article. @@ -27,7 +27,7 @@ To establish the starting point, this article will discuss the high-level strate ## Implementation process -The implementation of the governance MVP has dependencies on Identity, Security, and Networking. Once the dependencies are resolved, the Cloud Governance team will decide a few aspects of governance. The decisions from the Cloud Governance team and from supporting teams will be implemented through a single package of enforcement assets. +The implementation of the governance MVP has dependencies on Identity, Security, and Networking. Once the dependencies are resolved, the cloud governance team will decide a few aspects of governance. The decisions from the cloud governance team and from supporting teams will be implemented through a single package of enforcement assets. ![Example of an incremental governance MVP](../../../_images/governance/governance-mvp-implementation-flow.png) @@ -42,7 +42,7 @@ This implementation can also be described using a simple checklist: ## Application of governance-defined patterns -The Cloud Governance team is responsible for the following decisions and implementations. Many require inputs from other teams, but the Cloud Governance team is likely to own both the decision and the implementation. The following sections outline the decisions made for this use case and details of each decision. +The cloud governance team is responsible for the following decisions and implementations. Many require inputs from other teams, but the cloud governance team is likely to own both the decision and the implementation. The following sections outline the decisions made for this use case and details of each decision. ### Subscription design @@ -85,17 +85,17 @@ Logging and reporting decisions determine how your store log data and how the mo ## Evolution of governance processes -As governance evolves, some policy statements can’t or shouldn’t be controlled by automated tooling. Other policies will result in effort by the IT Security team and the on-premises Identity Management team over time. To help manage new risks as they arise, the Cloud Governance team will oversee the following processes. +As governance evolves, some policy statements can’t or shouldn’t be controlled by automated tooling. Other policies will result in effort by the IT Security team and the on-premises Identity Management team over time. To help manage new risks as they arise, the cloud governance team will oversee the following processes. -**Adoption acceleration:** The Cloud Governance team has been reviewing deployment scripts across multiple teams. They maintain a set of scripts that serve as deployment templates. Those templates are used by the cloud adoption and DevOps teams to define deployments more quickly. Each of those scripts contains the necessary requirements to enforce a set of governance policies with no additional effort from cloud adoption engineers. As the curators of these scripts, the Cloud Governance team can more quickly implement policy changes. As a result of script curation, the Cloud Governance team is seen as a source of adoption acceleration. This creates consistency among deployments, without strictly forcing adherence. +**Adoption acceleration:** The cloud governance team has been reviewing deployment scripts across multiple teams. They maintain a set of scripts that serve as deployment templates. Those templates are used by the cloud adoption and DevOps teams to define deployments more quickly. Each of those scripts contains the necessary requirements to enforce a set of governance policies with no additional effort from cloud adoption engineers. As the curators of these scripts, the cloud governance team can more quickly implement policy changes. As a result of script curation, the cloud governance team is seen as a source of adoption acceleration. This creates consistency among deployments, without strictly forcing adherence. -**Engineer training:** The Cloud Governance team offers bimonthly training sessions and has created two videos for engineers. These materials help engineers quickly learn the governance culture and how things are done during deployments. The team is adding training assets that show the difference between production and nonproduction deployments, so that engineers will understand how the new policies will affect adoption. This creates consistency among deployments, without strictly forcing adherence. +**Engineer training:** The cloud governance team offers bimonthly training sessions and has created two videos for engineers. These materials help engineers quickly learn the governance culture and how things are done during deployments. The team is adding training assets that show the difference between production and nonproduction deployments, so that engineers will understand how the new policies will affect adoption. This creates consistency among deployments, without strictly forcing adherence. -**Deployment planning:** Before deploying any asset containing protected data, the Cloud Governance team will review deployment scripts to validate governance alignment. Existing teams with previously approved deployments will be audited using programmatic tooling. +**Deployment planning:** Before deploying any asset containing protected data, the cloud governance team will review deployment scripts to validate governance alignment. Existing teams with previously approved deployments will be audited using programmatic tooling. -**Monthly audit and reporting:** Each month, the Cloud Governance team runs an audit of all cloud deployments to validate continued alignment to policy. When deviations are discovered, they are documented and shared with the cloud adoption teams. When enforcement doesn't risk a business interruption or data leak, the policies are automatically enforced. At the end of the audit, the Cloud Governance team compiles a report for the Cloud Strategy team and each cloud adoption team to communicate overall adherence to policy. The report is also stored for auditing and legal purposes. +**Monthly audit and reporting:** Each month, the cloud governance team runs an audit of all cloud deployments to validate continued alignment to policy. When deviations are discovered, they are documented and shared with the cloud adoption teams. When enforcement doesn't risk a business interruption or data leak, the policies are automatically enforced. At the end of the audit, the cloud governance team compiles a report for the cloud strategy team and each cloud adoption team to communicate overall adherence to policy. The report is also stored for auditing and legal purposes. -**Quarterly policy review:** Each quarter, the Cloud Governance team and the Cloud Strategy team will review audit results and suggest changes to corporate policy. Many of those suggestions are the result of continuous improvements and the observation of usage patterns. Approved policy changes are integrated into governance tooling during subsequent audit cycles. +**Quarterly policy review:** Each quarter, the cloud governance team and the cloud strategy team will review audit results and suggest changes to corporate policy. Many of those suggestions are the result of continuous improvements and the observation of usage patterns. Approved policy changes are integrated into governance tooling during subsequent audit cycles. ## Alternative patterns @@ -112,7 +112,7 @@ If any of the patterns selected in this governance journey don't align with the ## Next steps -Once this guide is implemented, each cloud adoption team can go forth with a sound governance foundation. The Cloud Governance team will work in parallel to continuously update the corporate policies and governance disciplines. +Once this guide is implemented, each cloud adoption team can go forth with a sound governance foundation. The cloud governance team will work in parallel to continuously update the corporate policies and governance disciplines. The two teams will use the tolerance indicators to identify the next evolution needed to continue supporting cloud adoption. For the fictional company in this journey, the next step is evolving the Security Baseline to support moving protected data to the cloud. diff --git a/docs/cloud-adoption/governance/journeys/small-to-medium-enterprise/cost-management-evolution.md b/docs/cloud-adoption/governance/journeys/small-to-medium-enterprise/cost-management-evolution.md index f021ac97fe6..4857450fd33 100644 --- a/docs/cloud-adoption/governance/journeys/small-to-medium-enterprise/cost-management-evolution.md +++ b/docs/cloud-adoption/governance/journeys/small-to-medium-enterprise/cost-management-evolution.md @@ -17,7 +17,7 @@ This article evolves the narrative by adding cost controls to the governance MVP ## Evolution of the narrative -Adoption has grown beyond the cost tolerance indicator defined in the governance MVP. This is a good thing, as it corresponds with migrations from the "DR" datacenter. The increase in spending now justifies an investment of time from the Cloud Governance team. +Adoption has grown beyond the cost tolerance indicator defined in the governance MVP. This is a good thing, as it corresponds with migrations from the "DR" datacenter. The increase in spending now justifies an investment of time from the cloud governance team. ### Evolution of the current state @@ -62,7 +62,7 @@ The following changes to policy will help remediate the new risks and guide impl This section of the article will evolve the governance MVP design to include new Azure policies and an implementation of Azure Cost Management. Together, these two design changes will fulfill the new corporate policy statements. 1. Implement Azure Cost Management - 1. Establish the right scope of access to align with the subscription pattern and the Resource Consistency discipline. Assuming alignment with the governance MVP defined in prior articles, this requires **Enrollment Account Scope** access for the Cloud Governance team executing on high-level reporting. Additional teams outside of governance may require **Resource Group Scope** access. + 1. Establish the right scope of access to align with the subscription pattern and the Resource Consistency discipline. Assuming alignment with the governance MVP defined in prior articles, this requires **Enrollment Account Scope** access for the cloud governance team executing on high-level reporting. Additional teams outside of governance may require **Resource Group Scope** access. 2. Establish a budget in Azure Cost Management. 3. Review and act on initial recommendations. Have a recurring process to support reporting. 4. Configure and execute Azure Cost Management Reporting, both initial and recurring. diff --git a/docs/cloud-adoption/governance/journeys/small-to-medium-enterprise/index.md b/docs/cloud-adoption/governance/journeys/small-to-medium-enterprise/index.md index f4aeb08ea79..98808b54e28 100644 --- a/docs/cloud-adoption/governance/journeys/small-to-medium-enterprise/index.md +++ b/docs/cloud-adoption/governance/journeys/small-to-medium-enterprise/index.md @@ -22,9 +22,9 @@ As a quick starting point, this overview defines a minimum viable product (MVP) > [!WARNING] > This MVP is a baseline starting point, based on a set of assumptions. Even this minimal set of best practices is based on corporate policies driven by unique business risks and risk tolerances. To see if these assumptions apply to you, read the [longer narrative](./narrative.md) that follows this article. -## Governance best practice +## Governance best practices -This best practice serves as a foundation that an organization can use to quickly and consistently add governance guardrails across multiple Azure subscriptions. +These best practices serve as a foundation for an organization to quickly and consistently add governance guardrails across multiple Azure subscriptions. ### Resource organization @@ -32,7 +32,7 @@ The following diagram shows the governance MVP hierarchy for organizing resource ![Resource Organization diagram](../../../_images/governance/resource-organization.png) -Every application should be deployed in the proper area of the management group, subscription, and resource group hierarchy. During deployment planning, the Cloud Governance team will create the necessary nodes in the hierarchy to empower the cloud adoption teams. +Every application should be deployed in the proper area of the management group, subscription, and resource group hierarchy. During deployment planning, the cloud governance team will create the necessary nodes in the hierarchy to empower the cloud adoption teams. 1. A management group for each type of environment (such as Production, Development, and Test). 2. A subscription for each "application categorization". diff --git a/docs/cloud-adoption/governance/journeys/small-to-medium-enterprise/initial-corporate-policy.md b/docs/cloud-adoption/governance/journeys/small-to-medium-enterprise/initial-corporate-policy.md index 5869ca2889b..3ce79e62d67 100644 --- a/docs/cloud-adoption/governance/journeys/small-to-medium-enterprise/initial-corporate-policy.md +++ b/docs/cloud-adoption/governance/journeys/small-to-medium-enterprise/initial-corporate-policy.md @@ -18,9 +18,9 @@ The following corporate policy defines an initial governance position, which is > [!NOTE] >The corporate policy is not a technical document, but it drives many technical decisions. The governance MVP described in the [overview](./index.md) ultimately derives from this policy. Before implementing a governance MVP, your organization should develop a corporate policy based on your own objectives and business risks. -## Cloud Governance team +## Cloud governance team -In this narrative, the Cloud Governance team is comprised of two systems administrators who have recognized the need for governance. Over the next several months, they will inherit the job of cleaning up the governance of the company’s cloud presence, earning them the title of _cloud custodians_. In subsequent evolutions, this title will likely change. +In this narrative, the cloud governance team is comprised of two systems administrators who have recognized the need for governance. Over the next several months, they will inherit the job of cleaning up the governance of the company’s cloud presence, earning them the title of _cloud custodians_. In subsequent evolutions, this title will likely change. [!INCLUDE [business-risk](../../../includes/governance/business-risks.md)] @@ -36,7 +36,7 @@ The current tolerance for risk is high and the appetite for investing in cloud g ## Next steps -This corporate policy prepares the Cloud Governance team to implement the governance MVP, which will be the foundation for adoption. The next step is to implement this MVP. +This corporate policy prepares the cloud governance team to implement the governance MVP, which will be the foundation for adoption. The next step is to implement this MVP. > [!div class="nextstepaction"] > [Best practice explained](./best-practice-explained.md) diff --git a/docs/cloud-adoption/governance/journeys/small-to-medium-enterprise/multicloud-evolution.md b/docs/cloud-adoption/governance/journeys/small-to-medium-enterprise/multicloud-evolution.md index 438f0ab0bfe..874e9ff00b2 100644 --- a/docs/cloud-adoption/governance/journeys/small-to-medium-enterprise/multicloud-evolution.md +++ b/docs/cloud-adoption/governance/journeys/small-to-medium-enterprise/multicloud-evolution.md @@ -59,7 +59,7 @@ The following changes to policy will help remediate the new risks and guide impl This section of the article will evolve the governance MVP design to include new Azure policies and an implementation of Azure Cost Management. Together, these two design changes will fulfill the new corporate policy statements. -1. Connect the networks. This step is executed by the Networking and IT Security teams, and supported by the Cloud Governance team. Adding a connection from the MPLS/leased-line provider to the new cloud will integrate networks. Adding routing tables and firewall configurations will control access and traffic between the environments. +1. Connect the networks. This step is executed by the Networking and IT Security teams, and supported by the cloud governance team. Adding a connection from the MPLS/leased-line provider to the new cloud will integrate networks. Adding routing tables and firewall configurations will control access and traffic between the environments. 2. Consolidate identity providers. Depending on the workloads being hosted in the secondary cloud, there are a variety of options to identity provider consolidation. The following are a few examples: 1. For applications that authenticate using OAuth 2, users from Active Directory in the secondary cloud can simply be replicated to the existing Azure AD tenant. This ensures all users can be authenticated in the tenant. 2. At the other extreme, federation allows OUs to flow into Active Directory on-premises, then into the Azure AD instance. @@ -80,4 +80,4 @@ As multicloud adoption grows, the design evolution above will continue to mature ## Conclusion -This series of articles outlined the evolution of governance best practices, aligned with the experiences of this fictional company. By starting small, but with the right foundation, the company could move quickly and yet still apply the right amount of governance at the right time. The MVP by itself did not protect the customer. Instead, it created the foundation to manage risks and add protections. From there, layers of governance were applied to remediate tangible risks. The exact journey presented here won't align 100% with the experiences of any reader. Rather, it serves as a pattern for incremental governance. The reader is advised to mold these best practices to fit their own unique constraints and governance requirements. +This series of articles described the incremental development of governance best practices, aligned with the experiences of this fictional company. By starting small, but with the right foundation, the company could move quickly and yet still apply the right amount of governance at the right time. The MVP by itself did not protect the customer. Instead, it created the foundation to manage risks and add protections. From there, layers of governance were applied to remediate tangible risks. The exact journey presented here won't align 100% with the experiences of any reader. Rather, it serves as a pattern for incremental governance. The reader is advised to mold these best practices to fit their own unique constraints and governance requirements. diff --git a/docs/cloud-adoption/governance/journeys/small-to-medium-enterprise/resource-consistency-evolution.md b/docs/cloud-adoption/governance/journeys/small-to-medium-enterprise/resource-consistency-evolution.md index d3b25dc8ff0..492f7f484ff 100644 --- a/docs/cloud-adoption/governance/journeys/small-to-medium-enterprise/resource-consistency-evolution.md +++ b/docs/cloud-adoption/governance/journeys/small-to-medium-enterprise/resource-consistency-evolution.md @@ -57,7 +57,7 @@ This business risk can be expanded into several technical risks: The following changes to policy will help remediate the new risks and guide implementation. The list looks long, but adopting these policies may be easier than it appears. -1. All deployed assets must be categorized by criticality and data classification. Classifications are to be reviewed by the Cloud Governance team and the application owner before deployment to the cloud. +1. All deployed assets must be categorized by criticality and data classification. Classifications are to be reviewed by the cloud governance team and the application owner before deployment to the cloud. 2. Subnets containing mission-critical applications must be protected by a firewall solution capable of detecting intrusions and responding to attacks. 3. Governance tooling must audit and enforce network configuration requirements defined by the Security Management team. 4. Governance tooling must validate that all assets related to mission-critical apps or protected data are included in monitoring for resource depletion and optimization. @@ -67,18 +67,18 @@ The following changes to policy will help remediate the new risks and guide impl 8. Governance tooling must enforce that automatic updates are prevented on all deployed assets that support mission-critical applications. Violations must be reviewed with operational management teams and remediated in accordance with operations policies. Assets that are not automatically updated must be included in processes owned by IT Operations. 9. Governance tooling must validate tagging related to cost, criticality, SLA, application, and data classification. All values must align to predefined values managed by the governance team. 10. Governance processes must include audits at the point of deployment and at regular cycles to ensure consistency across all assets. -11. Trends and exploits that could affect cloud deployments should be reviewed regularly by the Security team to provide updates to security management tooling used in the cloud. +11. Trends and exploits that could affect cloud deployments should be reviewed regularly by the security team to provide updates to security management tooling used in the cloud. 12. Before release into production, all mission-critical apps and protected data must be added to the designated operational monitoring solution. Assets that cannot be discovered by the chosen IT operations tooling, cannot be released for production use. Any changes required to make the assets discoverable must be made to the relevant deployment processes to ensure assets will be discoverable in future deployments. 13. When discovered, operational management teams will size assets, to ensure that assets meet performance requirements. -14. Deployment tooling must be approved by the Cloud Governance team to ensure ongoing governance of deployed assets. -15. Deployment scripts must be maintained in a central repository accessible by the Cloud Governance team for periodic review and auditing. +14. Deployment tooling must be approved by the cloud governance team to ensure ongoing governance of deployed assets. +15. Deployment scripts must be maintained in a central repository accessible by the cloud governance team for periodic review and auditing. 16. Governance review processes must validate that deployed assets are properly configured in alignment with SLA and recovery requirements. ## Evolution of the best practices This section of the article will evolve the governance MVP design to include new Azure policies and an implementation of Azure Cost Management. Together, these two design changes will fulfill the new corporate policy statements. -1. The Cloud Operations team will define operational monitoring tooling and automated remediation tooling. The Cloud Governance team will support those discovery processes. In this use case, the Cloud Operations team chose Azure Monitor as the primary tool for monitoring mission-critical applications. +1. The cloud operations team will define operational monitoring tooling and automated remediation tooling. The cloud governance team will support those discovery processes. In this use case, the cloud operations team chose Azure Monitor as the primary tool for monitoring mission-critical applications. 2. Create a repository in Azure DevOps to store and version all relevant Resource Manager templates and scripted configurations. 3. Azure Vault implementation: 1. Define and deploy Azure Vault for backup and recovery processes. @@ -88,7 +88,7 @@ This section of the article will evolve the governance MVP design to include new 2. Audit and enforce the use of approved images only. 5. Azure Monitor implementation: 1. Once a mission-critical subscription is identified, create an Azure Monitor workspace using PowerShell. This is a predeployment process. - 2. During deployment testing, the Cloud Operations team deploys the necessary agents and tests discovery. + 2. During deployment testing, the cloud operations team deploys the necessary agents and tests discovery. 6. Update Azure Policy for all subscriptions that contain mission-critical applications. 1. Audit and enforce the application of an NSG to all NICs and subnets. Networking and IT Security define the NSG. 2. Audit and enforce the use of approved network subnets and VNets for each network interface. @@ -111,7 +111,7 @@ These additional processes and changes to the governance MVP help remediate many ## Next steps -As cloud adoption continues to evolve and deliver additional business value, risks and cloud governance needs will also evolve. For the fictional company in this journey, the next trigger is when the scale of deployment exceeds 100 assets to the cloud or monthly spending exceeds $1,000 per month. At this point, the Cloud Governance team adds Cost Management controls. +As cloud adoption continues to evolve and deliver additional business value, risks and cloud governance needs will also evolve. For the fictional company in this journey, the next trigger is when the scale of deployment exceeds 100 assets to the cloud or monthly spending exceeds $1,000 per month. At this point, the cloud governance team adds Cost Management controls. > [!div class="nextstepaction"] > [Cost Management evolution](./cost-management-evolution.md) diff --git a/docs/cloud-adoption/governance/journeys/small-to-medium-enterprise/security-baseline-evolution.md b/docs/cloud-adoption/governance/journeys/small-to-medium-enterprise/security-baseline-evolution.md index f346e9ea92d..af6772c0270 100644 --- a/docs/cloud-adoption/governance/journeys/small-to-medium-enterprise/security-baseline-evolution.md +++ b/docs/cloud-adoption/governance/journeys/small-to-medium-enterprise/security-baseline-evolution.md @@ -19,9 +19,9 @@ This article evolves the narrative by adding security controls that support movi IT and business leadership have been happy with results from early stage experimentation by the IT, App Development, and BI teams. To realize tangible business values from these experiments, those teams must be allowed to integrate protected data into solutions. This triggers changes to corporate policy, but also requires an evolution of the cloud governance implementations before protected data can land in the cloud. -### Evolution of the Cloud Governance team +### Evolution of the cloud governance team -Given the effect of the changing narrative and support provided so far, the Cloud Governance team is now viewed differently. The two system administrators who started the team are now viewed as experienced cloud architects. As this narrative develops, the perception of them will shift from being Cloud Custodians to more of a Cloud Guardian role. +Given the effect of the changing narrative and support provided so far, the cloud governance team is now viewed differently. The two system administrators who started the team are now viewed as experienced cloud architects. As this narrative develops, the perception of them will shift from being Cloud Custodians to more of a Cloud Guardian role. While the difference is subtle, it’s an important distinction when building a governance- focused IT culture. A Cloud Custodian cleans up the messes made by innovative cloud architects. The two roles have natural friction and opposing objectives. On the other hand, a Cloud Guardian helps keep the cloud safe, so other cloud architects can move more quickly, with less messes. Additionally, a Cloud Guardian is involved in creating templates that accelerate deployment and adoption, making them an innovation accelerator as well as a defender of the Five Disciplines of Cloud Governance. @@ -40,7 +40,7 @@ Since then, some things have changed that will affect governance: Early experiments by the App Dev and BI teams show potential improvements in customer experiences and data-driven decisions. Both teams want to expand adoption of the cloud over the next 18 months by deploying those solutions to production. -During the remaining six months, the Cloud Governance team will implement security and governance requirements to allow the cloud adoption teams to migrate the protected data in those datacenters. +During the remaining six months, the cloud governance team will implement security and governance requirements to allow the cloud adoption teams to migrate the protected data in those datacenters. The changes to current and future state expose new risks that require new policy statements. @@ -64,21 +64,21 @@ This business risk can be expanded into a few technical risks: The following changes to policy will help remediate the new risks and guide implementation. The list looks long, but adopting these policies may be easier than it appears. -1. All deployed assets must be categorized by criticality and data classification. Classifications are to be reviewed by the Cloud Governance team and the application owner before deployment to the cloud. +1. All deployed assets must be categorized by criticality and data classification. Classifications are to be reviewed by the cloud governance team and the application owner before deployment to the cloud. 2. Applications that store or access protected data are to be managed differently than those that don’t. At a minimum, they should be segmented to avoid unintended access of protected data. 3. All protected data must be encrypted when at rest. -4. Elevated permissions in any segment containing protected data should be an exception. Any such exceptions will be recorded with the Cloud Governance team and audited regularly. +4. Elevated permissions in any segment containing protected data should be an exception. Any such exceptions will be recorded with the cloud governance team and audited regularly. 5. Network subnets containing protected data must be isolated from any other subnets. Network traffic between protected data subnets will be audited regularly. 6. No subnet containing protected data can be directly accessed over the public internet or across datacenters. Access to those subnets must be routed through intermediate subnets. All access into those subnets must come through a firewall solution that can perform packet scanning and blocking functions. 7. Governance tooling must audit and enforce network configuration requirements defined by the security management team. 8. Governance tooling must limit VM deployment to approved images only. 9. Whenever possible, node configuration management should apply policy requirements to the configuration of any guest operating system. 10. Governance tooling must enforce that automatic updates are enabled on all deployed assets. Violations must be reviewed with operational management teams and remediated in accordance with operations policies. Assets that are not automatically updated must be included in processes owned by IT Operations. -11. Creation of new subscriptions or management groups for any mission-critical applications or protected data will require a review from the Cloud Governance team, to ensure that the proper blueprint is assigned. +11. Creation of new subscriptions or management groups for any mission-critical applications or protected data will require a review from the cloud governance team, to ensure that the proper blueprint is assigned. 12. A least-privilege access model will be applied to any management group or subscription that contains mission-critical apps or protected data. 13. Trends and exploits that could affect cloud deployments should be reviewed regularly by the security team to provide updates to security management tooling used in the cloud. -14. Deployment tooling must be approved by the Cloud Governance team to ensure ongoing governance of deployed assets. -15. Deployment scripts must be maintained in a central repository accessible by the Cloud Governance team for periodic review and auditing. +14. Deployment tooling must be approved by the cloud governance team to ensure ongoing governance of deployed assets. +15. Deployment scripts must be maintained in a central repository accessible by the cloud governance team for periodic review and auditing. 16. Governance processes must include audits at the point of deployment and at regular cycles to ensure consistency across all assets. 17. Deployment of any applications that require customer authentication must use an approved identity provider that is compatible with the primary identity provider for internal users. 18. Cloud governance processes must include quarterly reviews with identity management teams. These reviews can help identify malicious actors or usage patterns that should be prevented by cloud asset configuration. @@ -87,8 +87,8 @@ The following changes to policy will help remediate the new risks and guide impl The governance MVP design will evolve to include new Azure policies and an implementation of Azure Cost Management. Together, these two design changes will fulfill the new corporate policy statements. -1. The Networking and IT Security teams will define network requirements. The Cloud Governance team will support the conversation. -2. The Identity and IT Security teams will define identity requirements and make any necessary changes to local Active Directory implementation. The Cloud Governance team will review changes. +1. The Networking and IT Security teams will define network requirements. The cloud governance team will support the conversation. +2. The Identity and IT Security teams will define identity requirements and make any necessary changes to local Active Directory implementation. The cloud governance team will review changes. 3. Create a repository in Azure DevOps to store and version all relevant Azure Resource Manager templates and scripted configurations. 4. Azure Security Center implementation: 1. Configure Azure Security Center for any management group that contains protected data classifications. diff --git a/docs/cloud-adoption/governance/policy-compliance/index.md b/docs/cloud-adoption/governance/policy-compliance/index.md index beadb643bf6..f49d6406ac7 100644 --- a/docs/cloud-adoption/governance/policy-compliance/index.md +++ b/docs/cloud-adoption/governance/policy-compliance/index.md @@ -44,7 +44,7 @@ In the image above, the governance strategy (risk, policy and compliance, monito An incremental approach to cloud governance assumes that it is unacceptable to exceed the [business' tolerance for risk](risk-tolerance.md). Instead, it assumes that the role of governance is to accelerate business change, help engineers understand architecture guidelines, and ensure that [business risks](understanding-business-risk.md) are regularly communicated and remediated. Alternatively, the traditional role of governance can become a barrier to adoption by engineers or by the business as a whole. -With an incremental approach to cloud governance, there is sometimes a natural friction between teams building new business solutions and teams protecting the business from risks. However, in this model those two teams can become peers working in increments or sprints. As peers, the Cloud Governance team and the cloud adoption teams begin to work together to expose, evaluate, and remediate business risks. This effort can create a natural means of reducing friction and building collaboration between teams. +With an incremental approach to cloud governance, there is sometimes a natural friction between teams building new business solutions and teams protecting the business from risks. However, in this model those two teams can become peers working in increments or sprints. As peers, the cloud governance team and the cloud adoption teams begin to work together to expose, evaluate, and remediate business risks. This effort can create a natural means of reducing friction and building collaboration between teams. ## Minimum viable product (MVP) for policy @@ -58,6 +58,6 @@ Policy MVP attempts to define a required foundation for policies needed to deplo Incremental policy growth is the key mechanism to growing policy and cloud governance over time. It is also the key requirement to adopting an incremental model to governance. For this model to work well, the governance team must be committed to an ongoing allocation of time at each sprint, in order to evaluate and implement changing governance disciplines. -**Sprint time requirements:** At the beginning of each iteration, each cloud adoption team creates a list of assets to be migrated or adopted in the current increment. The Cloud Governance team is expected to allow sufficient time to review the list, validate data classifications for assets, evaluate any new risks associated with each asset, update architecture guidelines, and educate the team on the changes. These commitments commonly require 10-30 hours per sprint. It's also expected for this level of involvement to require at least one dedicated employee to manage governance in a large cloud adoption effort. +**Sprint time requirements:** At the beginning of each iteration, each cloud adoption team creates a list of assets to be migrated or adopted in the current increment. The cloud governance team is expected to allow sufficient time to review the list, validate data classifications for assets, evaluate any new risks associated with each asset, update architecture guidelines, and educate the team on the changes. These commitments commonly require 10-30 hours per sprint. It's also expected for this level of involvement to require at least one dedicated employee to manage governance in a large cloud adoption effort. -**Release time requirements:** At the beginning of each release, the cloud adoption teams and the Cloud Strategy team should prioritize a list of applications or workloads to be migrated in the current iteration, along with any business change activities. Those data points allow the Cloud Governance team to understand new business risks early. That allows time to align with the business and gauge the business's tolerance for risk. +**Release time requirements:** At the beginning of each release, the cloud adoption teams and the cloud strategy team should prioritize a list of applications or workloads to be migrated in the current iteration, along with any business change activities. Those data points allow the cloud governance team to understand new business risks early. That allows time to align with the business and gauge the business's tolerance for risk. diff --git a/docs/cloud-adoption/governance/policy-compliance/processes.md b/docs/cloud-adoption/governance/policy-compliance/processes.md index 8fe31fd3b19..1eec0d884cb 100644 --- a/docs/cloud-adoption/governance/policy-compliance/processes.md +++ b/docs/cloud-adoption/governance/policy-compliance/processes.md @@ -19,7 +19,7 @@ ms.custom: governance I've defined policies, I've provided an architecture guide. Now how do I monitor adherence to policy? If there is a violation, how do I enforce the policy? ---> -After establishing your cloud policy statements and drafting a design guide, you'll need to create a strategy for ensuring your cloud deployment stays in compliance with your policy requirements. This strategy will need to encompass your Cloud Governance team's ongoing review and communication processes, establish criteria for when policy violations require action, and defining the requirements for automated monitoring and compliance systems that will detect violations and trigger remediation actions. +After establishing your cloud policy statements and drafting a design guide, you'll need to create a strategy for ensuring your cloud deployment stays in compliance with your policy requirements. This strategy will need to encompass your cloud governance team's ongoing review and communication processes, establish criteria for when policy violations require action, and defining the requirements for automated monitoring and compliance systems that will detect violations and trigger remediation actions. See the corporate policy sections of the [actionable governance journeys](../journeys/index.md) for examples of how policy adherence process fit into a cloud governance plan. @@ -31,19 +31,19 @@ For small deployments consisting of development and test resources, policy requi As a first step in defining your policy adherence strategy, evaluate how the processes discussed below can support your policy requirements. Determine how much effort is worth investing in these processes, and then use this information to establish realistic budget and staffing plans to meet these needs. -## Establish Cloud Governance team processes +## Establish cloud governance team processes -Before defining triggers for policy compliance remediation, you need establish the overall processes that your team will use and how information will be shared and escalated between IT staff and the Cloud Governance team. +Before defining triggers for policy compliance remediation, you need establish the overall processes that your team will use and how information will be shared and escalated between IT staff and the cloud governance team. -### Assign Cloud Governance team members +### Assign cloud governance team members -Your Cloud Governance team will provide ongoing guidance on policy compliance and handle policy-related issues that emerge when deploying and operating your cloud assets. When building this team, invite staff from your organization that have expertise in areas covered by your defined policy statements and identified risks. +Your cloud governance team will provide ongoing guidance on policy compliance and handle policy-related issues that emerge when deploying and operating your cloud assets. When building this team, invite staff from your organization that have expertise in areas covered by your defined policy statements and identified risks. For initial test deployments this can be limited to a few system administrators responsible for establishing the basics of governance. As your governance processes mature, review the cloud guidance team's membership regularly to ensure that you can properly address new potential risks and policy requirements. Identify members of your IT and business staff with relevant experience or interest in specific areas of governance and include them in your teams on a permanent or ad-hoc basis as-needed. ### Reviews and policy iteration -As additional resources and workloads are deployed, the Cloud Governance team will need to ensure that new workloads or assets comply with policy requirements. Evaluate new requirements from workload development teams to ensure their planned deployments will align with your design guides, and update your policies to support these requirements when appropriate. +As additional resources and workloads are deployed, the cloud governance team will need to ensure that new workloads or assets comply with policy requirements. Evaluate new requirements from workload development teams to ensure their planned deployments will align with your design guides, and update your policies to support these requirements when appropriate. Plan to evaluate new potential risks and update policy statements and design guides as needed. Work with IT staff and workload teams to evaluate new Azure features and services on an ongoing basis. Also schedule regular review cycles each of the five governance disciplines to ensure policy is up-to-date and being met. @@ -55,11 +55,11 @@ As policy changes, regularly update documentation and training materials, and en ### Establish escalation paths -If a resource goes out of compliance, who gets notified? If IT staff detect a policy compliance issue, who do they contact? Make sure the escalation process to the Cloud Governance team is clearly defined. Ensure these communication channels are kept updated to reflect staff and organization changes. +If a resource goes out of compliance, who gets notified? If IT staff detect a policy compliance issue, who do they contact? Make sure the escalation process to the cloud governance team is clearly defined. Ensure these communication channels are kept updated to reflect staff and organization changes. ## Violation triggers and actions -After defining your Cloud Governance team and its processes, you need to explicitly define what qualifies as compliance violations that will triggers actions, and what those actions should be. +After defining your cloud governance team and its processes, you need to explicitly define what qualifies as compliance violations that will triggers actions, and what those actions should be. ### Define triggers @@ -70,7 +70,7 @@ For each of your policy statements, review requirements to determine what consti ### Define actions -Each violation trigger should have a corresponding action. Triggered actions should always notify an appropriate IT staff or Cloud Governance team member when a violation occurs. This notification can lead to a manual review of the compliance issue or kickoff a predefined remediation process depending on the type and severity of the detected violation. +Each violation trigger should have a corresponding action. Triggered actions should always notify an appropriate IT staff or cloud governance team member when a violation occurs. This notification can lead to a manual review of the compliance issue or kickoff a predefined remediation process depending on the type and severity of the detected violation. Some examples of violation triggers and actions: diff --git a/docs/cloud-adoption/governance/policy-compliance/risk-tolerance.md b/docs/cloud-adoption/governance/policy-compliance/risk-tolerance.md index 034f40ad45e..41ee6093f85 100644 --- a/docs/cloud-adoption/governance/policy-compliance/risk-tolerance.md +++ b/docs/cloud-adoption/governance/policy-compliance/risk-tolerance.md @@ -31,7 +31,7 @@ True business risks are based on the details of specific transformations. Severa - **Budget control:** Cost models change in the cloud. This change can create risks associated with cost overruns or increases in the cost of goods sold (COGS), especially directly attributed operating expenses. When business works closely with IT, it is feasible to create transparency regarding costs and services consumed by various business units, programs, or projects. [Cost Management](../cost-management/index.md) provides examples of ways business and IT can partner on this topic. -The above are a few of the most common risks mentioned by customers. The Cloud Governance team and the cloud adoption teams can begin to develop a risk profile, as workloads are migrated and readied for production release. Be prepared for conversations to define, refine, and manage risks based on the desired business outcomes and transformation effort. +The above are a few of the most common risks mentioned by customers. The cloud governance team and the cloud adoption teams can begin to develop a risk profile, as workloads are migrated and readied for production release. Be prepared for conversations to define, refine, and manage risks based on the desired business outcomes and transformation effort. ## Understanding risk tolerance @@ -77,7 +77,7 @@ These basic questions will lead to many more. After exploring a healthy dialogue These questions over simplify the technical solutions needed to manage or remove risks. However, these questions communicate those solutions in ways the business can quickly integrate into a decision process. -**Probability of loss:** Questions to determine how likely it is that the risk will become a reality. This is the most difficult area to quantify. Instead it is suggested that the Cloud Governance team create categories for communicating probability, based on the supporting data. The following questions can help create categories that are meaningful to the team. +**Probability of loss:** Questions to determine how likely it is that the risk will become a reality. This is the most difficult area to quantify. Instead it is suggested that the cloud governance team create categories for communicating probability, based on the supporting data. The following questions can help create categories that are meaningful to the team. - Has any research been done regarding the likelihood of this risk being realized? - Can the vendor provide references or statistics on the likelihood of an impact? @@ -85,7 +85,7 @@ These questions over simplify the technical solutions needed to manage or remove - Look further, are there other companies in general that have been hit by this risk? - Is this risk unique to something this company has done poorly? -After answering these questions along with questions as determined by the Cloud Governance team, groupings of probability will likely emerge. The following are a few grouping samples to help get started: +After answering these questions along with questions as determined by the cloud governance team, groupings of probability will likely emerge. The following are a few grouping samples to help get started: - **No indication:** Not enough research has been completed to determine probability. - **Low risk:** Current research indicates realizing the risk is unlikely. diff --git a/docs/cloud-adoption/governance/policy-compliance/understanding-business-risk.md b/docs/cloud-adoption/governance/policy-compliance/understanding-business-risk.md index a4e00faecae..c03d67dd22b 100644 --- a/docs/cloud-adoption/governance/policy-compliance/understanding-business-risk.md +++ b/docs/cloud-adoption/governance/policy-compliance/understanding-business-risk.md @@ -41,9 +41,9 @@ During a cloud transformation, both the business and IT teams have an opportunit ## What is a business risk MVP? -A **minimum viable product** is commonly used to define to define the smallest unit of something that can produce tangible value. In a business risk MVP, the Cloud Governance team starts with the assumption that some assets will be deployed to a cloud environment at some point in time. It's unknown what those assets are at the time, and the team may be unsure what types of data will be stored on those assets. +A **minimum viable product** is commonly used to define to define the smallest unit of something that can produce tangible value. In a business risk MVP, the cloud governance team starts with the assumption that some assets will be deployed to a cloud environment at some point in time. It's unknown what those assets are at the time, and the team may be unsure what types of data will be stored on those assets. -When planning for business risk, the Cloud Governance team could build for the worst case scenario and map every possible policy to the cloud. However, identifying all potential business risks for all cloud usage scenarios can take considerable time and effort, potentially delaying the implementation of governance to your cloud workloads. This is not advised, but is an option. +When planning for business risk, the cloud governance team could build for the worst case scenario and map every possible policy to the cloud. However, identifying all potential business risks for all cloud usage scenarios can take considerable time and effort, potentially delaying the implementation of governance to your cloud workloads. This is not advised, but is an option. Conversely, an MVP approach can allow the team to define an initial starting point and set of assumptions that would be true for most/all assets. This business risk MVP will support initial small scale or test cloud deployments, and then be used as a base for gradually identifying and remediating new risks as business needs arise or additional workloads are added to your cloud environment. This process allows you to apply governance throughout the cloud adoption process. @@ -63,11 +63,11 @@ Once the Business Risk MVP is established, they can be converted to [policies](i As your organization deploys more workloads to the cloud, development teams will make use of increasing amounts of cloud resources. At each iteration, new assets are created and staged. At each release, workloads are readied for production promotion. Each of these cycles has the potential to introduce previously unidentified business risks. -Assuming a business risk MVP is the starting point for your initial cloud adoption efforts, governance can mature in parallel with your increasing use of cloud resources. When the Cloud Governance team operates in parallel with cloud adoption teams, the growth of business risks can be addressed as they are identified, providing a stable ongoing model for developing governance maturity. +Assuming a business risk MVP is the starting point for your initial cloud adoption efforts, governance can mature in parallel with your increasing use of cloud resources. When the cloud governance team operates in parallel with cloud adoption teams, the growth of business risks can be addressed as they are identified, providing a stable ongoing model for developing governance maturity. Each asset staged can easily be classified according to risk. Data classification documents can be built or created in parallel with staging cycles. Risk profile and exposure points can likewise be documented. Over time an extremely clear view of business risk will come into focus across the organization. -With each iteration, the Cloud Governance team can work with the Cloud Strategy team to quickly communicate new risks, mitigation strategies, tradeoffs, and potential costs. This empowers business participants and IT leaders to partner in mature, well-informed decisions. Those decisions then inform policy maturity. When required, the policy changes produce new work items for the maturity of core infrastructure systems. When changes to staged systems are required, the cloud adoption teams have ample time to make changes, while the business tests the staged systems and develops a user adoption plan. +With each iteration, the cloud governance team can work with the cloud strategy team to quickly communicate new risks, mitigation strategies, tradeoffs, and potential costs. This empowers business participants and IT leaders to partner in mature, well-informed decisions. Those decisions then inform policy maturity. When required, the policy changes produce new work items for the maturity of core infrastructure systems. When changes to staged systems are required, the cloud adoption teams have ample time to make changes, while the business tests the staged systems and develops a user adoption plan. This approach minimizes risks, while empowering the team to move quickly. It also ensures that risks are promptly addressed and resolved before deployment. diff --git a/docs/cloud-adoption/governance/resource-consistency/business-risks.md b/docs/cloud-adoption/governance/resource-consistency/business-risks.md index fdbc42563a1..03ea980fbdd 100644 --- a/docs/cloud-adoption/governance/resource-consistency/business-risks.md +++ b/docs/cloud-adoption/governance/resource-consistency/business-risks.md @@ -31,7 +31,7 @@ Initial test deployments may not require much beyond adopting some cursory namin The Resource Consistency discipline attempts to address core operational business risks. Work with your business and IT teams to identify these risks and monitor each of them for relevance as you plan for and implement your cloud deployments. -Risks will differ between organization, but the following serve as common risks that you can use as a starting point for discussions within your Cloud Governance team: +Risks will differ between organization, but the following serve as common risks that you can use as a starting point for discussions within your cloud governance team: - **Unnecessary operational cost.** Obsolete or unused resources, or resources that are overprovisioned during times of low demand, add unnecessary operational costs. - **Underprovisioned resources.** Resources that experience higher than anticipated demand can result in business disruption as cloud resources are overwhelmed by demand. diff --git a/docs/cloud-adoption/governance/resource-consistency/compliance-processes.md b/docs/cloud-adoption/governance/resource-consistency/compliance-processes.md index 4edf75a8fc4..a3c8ca93a29 100644 --- a/docs/cloud-adoption/governance/resource-consistency/compliance-processes.md +++ b/docs/cloud-adoption/governance/resource-consistency/compliance-processes.md @@ -25,17 +25,17 @@ The following is a set of example processes commonly involved in the Resource Co **Deployment planning:** Before deploying any asset, perform a review to identify any new operational risks. Establish resource requirements and expected demand patterns, and identify scalability needs and potential usage optimization opportunities. Also ensure backup and recovery plans are in place. -**Deployment testing:** As part of deployment, the Cloud Governance team, in cooperation with your cloud operations teams, will be responsible for reviewing the deployment to validate Resource Consistency policy compliance. +**Deployment testing:** As part of deployment, the cloud governance team, in cooperation with your cloud operations teams, will be responsible for reviewing the deployment to validate Resource Consistency policy compliance. **Annual planning:** On an annual basis, perform a high-level review of Resource Consistency strategy. Explore future corporate expansion plans or priorities and update cloud adoption strategies to identify potential risk increase or other emerging Resource Consistency needs. Also use this time to review the latest best practices for cloud Resource Consistency and integrate these into your policies and review processes. **Quarterly review and planning:** On a quarterly basis perform a review of operational data and incident reports to identify any changes required in Resource Consistency policy. As part of this process, review changes in resource usage and performance to identify assets that require increases or decreases in resource allocation, and identify any workloads or assets that are candidates for retirement. -This planning process is also a good time to evaluate the current membership of your Cloud Governance team for knowledge gaps related to new or evolving policy and risks related to Resource Consistency as a discipline. Invite relevant IT staff to participate in reviews and planning as either temporary technical advisors or permanent members of your team. +This planning process is also a good time to evaluate the current membership of your cloud governance team for knowledge gaps related to new or evolving policy and risks related to Resource Consistency as a discipline. Invite relevant IT staff to participate in reviews and planning as either temporary technical advisors or permanent members of your team. **Education and training:** On a bimonthly basis, offer training sessions to make sure IT staff and developers are up-to-date on the latest Resource Consistency policy requirements and guidance. As part of this process review and update any documentation or other training assets to ensure they are in sync with the latest corporate policy statements. -**Monthly audit and reporting reviews:** On a monthly basis, perform an audit on all cloud deployments to assure their continued alignment with Resource Consistency policy. Review related activities with IT staff and identify any compliance issues not already handled as part of the ongoing monitoring and enforcement process. The result of this review is a report for the Cloud Strategy team and each cloud adoption team to communicate overall performance and adherence to policy. The report is also stored for auditing and legal purposes. +**Monthly audit and reporting reviews:** On a monthly basis, perform an audit on all cloud deployments to assure their continued alignment with Resource Consistency policy. Review related activities with IT staff and identify any compliance issues not already handled as part of the ongoing monitoring and enforcement process. The result of this review is a report for the cloud strategy team and each cloud adoption team to communicate overall performance and adherence to policy. The report is also stored for auditing and legal purposes. ## Ongoing monitoring processes @@ -45,7 +45,7 @@ Ensure that your IT teams have implemented automated monitoring systems for your ## Violation triggers and enforcement actions -Because Resource Consistency policy compliance can lead to critical service disruption or significant cost overruns risks, the Cloud Governance team should have visibility into noncompliance incidents. Ensure IT staff have clear escalation paths for reporting these issues to the governance team members best suited to identify and verify that policy issues are mitigated once detected. +Because Resource Consistency policy compliance can lead to critical service disruption or significant cost overruns risks, the cloud governance team should have visibility into noncompliance incidents. Ensure IT staff have clear escalation paths for reporting these issues to the governance team members best suited to identify and verify that policy issues are mitigated once detected. When violations are detected, you should take actions to realign with policy as soon as possible. Your IT team can automate most violation triggers using the tools outlined in the [Resource Consistency toolchain for Azure](toolchain.md). @@ -54,7 +54,7 @@ The following triggers and enforcement actions provide examples you can referenc - **Overprovisioned resource detected.** Resources detected using less than 60% of CPU or memory capacity should automatically scale down or deprovisioning resources to reduce costs. - **Underprovisioned resource detected.** Resources detected using more than 80% of CPU or memory capacity should automatically scale up or provisioning additional resources to provide additional capacity. - **Untagged resource creation.** Any request to create a resource without required meta tags will be rejected automatically. -- **Critical resource outage detected.** IT staff are notified on all detected outages of mission-critical outages. If outage is not immediately resolvable, staff will escalate the issue and notify workload owners and the Cloud Governance team. The Cloud Governance team will track the issue until resolution and update guidance if policy revision is necessary to prevent future incidents. +- **Critical resource outage detected.** IT staff are notified on all detected outages of mission-critical outages. If outage is not immediately resolvable, staff will escalate the issue and notify workload owners and the cloud governance team. The cloud governance team will track the issue until resolution and update guidance if policy revision is necessary to prevent future incidents. ## Next steps diff --git a/docs/cloud-adoption/governance/resource-consistency/discipline-improvement.md b/docs/cloud-adoption/governance/resource-consistency/discipline-improvement.md index d9ea3e56871..7ee6ad27a18 100644 --- a/docs/cloud-adoption/governance/resource-consistency/discipline-improvement.md +++ b/docs/cloud-adoption/governance/resource-consistency/discipline-improvement.md @@ -21,7 +21,7 @@ This article outlines some potential tasks your company can engage in to better *Figure 1 - Adoption phases of the incremental approach to cloud governance.* -It's impossible for any one document to account for the requirements of all businesses. As such, this article outlines suggested minimum and potential example activities for each phase of the governance maturation process. The initial objective of these activities is to help you build a [Policy MVP](../journeys/index.md#an-incremental-approach-to-cloud-governance) and establish a framework for incremental policy evolution. Your Cloud Governance team will need to decide how much to invest in these activities to improve your Resource Consistency governance capabilities. +It's impossible for any one document to account for the requirements of all businesses. As such, this article outlines suggested minimum and potential example activities for each phase of the governance maturation process. The initial objective of these activities is to help you build a [Policy MVP](../journeys/index.md#an-incremental-approach-to-cloud-governance) and establish a framework for incremental policy evolution. Your cloud governance team will need to decide how much to invest in these activities to improve your Resource Consistency governance capabilities. > [!CAUTION] > Neither the minimum or potential activities outlined in this article are aligned to specific corporate policies or third-party compliance requirements. This guidance is designed to help facilitate the conversations that will lead to alignment of both requirements with a cloud governance model. @@ -115,7 +115,7 @@ Once the transformation is complete, governance and operations must live on for - Automatically apply and enforce governance requirements during future deployments. - Evaluate underused resources and determine if they're worth continuing. - Detect misalignments and anomalies between planned and actual resource usage. -- Assist the cloud adoption teams and the Cloud Strategy team in understanding and resolving these anomalies. +- Assist the cloud adoption teams and the cloud strategy team in understanding and resolving these anomalies. - Determine if changes need to be made to Resource Consistency for billing and SLAs. - Evaluate logging and monitoring tools to determine whether your on-premises, cloud gateway, or hybrid solution needs adjusting. - For business units and geographically distributed groups, determine if your organization should consider using additional cloud management features such as [Azure management groups](/azure/governance/management-groups) to better apply centralized policy and meet SLA requirements. diff --git a/docs/cloud-adoption/governance/resource-consistency/index.md b/docs/cloud-adoption/governance/resource-consistency/index.md index 77977adee14..3b4aec392ef 100644 --- a/docs/cloud-adoption/governance/resource-consistency/index.md +++ b/docs/cloud-adoption/governance/resource-consistency/index.md @@ -19,7 +19,7 @@ Resource Consistency is one of the [Five Disciplines of Cloud Governance](../gov > [!NOTE] > Resource Consistency governance does not replace the existing IT teams, processes, and procedures that allow your organization to effectively manage cloud-based resources. The primary purpose of this discipline is to identify potential business risks and provide risk-mitigation guidance to the IT staff that are responsible for managing your resources in the cloud. As you develop governance policies and processes make sure to involve relevant IT teams in your planning and review processes. -This section of the Cloud Adoption Framework outlines how to develop a Resource Consistency discipline as part of your cloud governance strategy. The primary audience for this guidance is your organization's cloud architects and other members of your Cloud Governance team. However, the decisions, policies, and processes that emerge from this discipline should involve engagement and discussions with relevant members of the IT teams responsible for implementing and managing your organization's Resource Consistency solutions. +This section of the Cloud Adoption Framework outlines how to develop a Resource Consistency discipline as part of your cloud governance strategy. The primary audience for this guidance is your organization's cloud architects and other members of your cloud governance team. However, the decisions, policies, and processes that emerge from this discipline should involve engagement and discussions with relevant members of the IT teams responsible for implementing and managing your organization's Resource Consistency solutions. If your organization lacks in-house expertise in Resource Consistency strategies, consider engaging external consultants as a part of this discipline. Also consider engaging [Microsoft Consulting Services](https://www.microsoft.com/enterprise/services), the [Microsoft FastTrack](https://azure.microsoft.com/programs/azure-fasttrack) cloud adoption service, or other external cloud adoption experts for discussing how best to organize, track, and optimize your cloud-based assets. @@ -32,7 +32,7 @@ Actionable policy statements and the resulting architecture requirements serve a ## Developing Resource Consistency governance policy statements -The following six steps offer examples and potential options to consider when developing Resource Consistency governance. Use each step as a starting point for discussions within your Cloud Governance team and with affected business, and IT teams across your organization to establish the policies and processes needed to manage Resource Consistency risks. +The following six steps offer examples and potential options to consider when developing Resource Consistency governance. Use each step as a starting point for discussions within your cloud governance team and with affected business, and IT teams across your organization to establish the policies and processes needed to manage Resource Consistency risks. diff --git a/docs/cloud-adoption/governance/resource-consistency/metrics-tolerance.md b/docs/cloud-adoption/governance/resource-consistency/metrics-tolerance.md index c1ec772e828..0b23420fbe5 100644 --- a/docs/cloud-adoption/governance/resource-consistency/metrics-tolerance.md +++ b/docs/cloud-adoption/governance/resource-consistency/metrics-tolerance.md @@ -61,7 +61,7 @@ Once you have a baseline, establish minimum benchmarks representing an unaccepta - **Backup coverage trigger.** A company with _x%_ of mission-critical assets without up-to-date backups in place would benefit from an increased investment in the Resource Consistency discipline to ensure a consistent backup strategy. - **Backup health trigger.** A company experiencing more than _x%_ failure of restore operations should invest in the Resource Consistency discipline to identify problems with backup and ensure important resources are protected. -The exact metrics and triggers you use to gauge risk tolerance and the level of investment in the Resource Consistency discipline will be specific to your organization, but the examples above should serve as a useful base for discussion within your Cloud Governance team. +The exact metrics and triggers you use to gauge risk tolerance and the level of investment in the Resource Consistency discipline will be specific to your organization, but the examples above should serve as a useful base for discussion within your cloud governance team. ## Next steps diff --git a/docs/cloud-adoption/governance/resource-consistency/policy-statements.md b/docs/cloud-adoption/governance/resource-consistency/policy-statements.md index f37c9dde84c..192475520c9 100644 --- a/docs/cloud-adoption/governance/resource-consistency/policy-statements.md +++ b/docs/cloud-adoption/governance/resource-consistency/policy-statements.md @@ -40,7 +40,7 @@ The following sample policy statements address common business risks related to **Technical risk:** Arbitrary creation of subscriptions and management groups can lead to isolated sections of your cloud estate that are not properly subject to your governance policies. -**Policy statement:** Creation of new subscriptions or management groups for any mission-critical applications or protected data will require a review from the Cloud Governance team. Approved changes will be integrated into a proper blueprint assignment. +**Policy statement:** Creation of new subscriptions or management groups for any mission-critical applications or protected data will require a review from the cloud governance team. Approved changes will be integrated into a proper blueprint assignment. **Potential design options:** Lock down administrative access to your organizations [Azure management groups](/azure/governance/management-groups) to only approved governance team members who will control the subscription creation and access control process. @@ -54,12 +54,12 @@ The following sample policy statements address common business risks related to ## Deployment compliance -**Technical risk:** Deployment scripts and automation tooling that is not fully vetted by the Cloud Governance team can result in resource deployments that violate policy. +**Technical risk:** Deployment scripts and automation tooling that is not fully vetted by the cloud governance team can result in resource deployments that violate policy. **Policy statement:** The following policies will be implemented: -- Deployment tooling must be approved by the Cloud Governance team to ensure ongoing governance of deployed assets. -- Deployment scripts must be maintained in central repository accessible by the Cloud Governance team for periodic review and auditing. +- Deployment tooling must be approved by the cloud governance team to ensure ongoing governance of deployed assets. +- Deployment scripts must be maintained in central repository accessible by the cloud governance team for periodic review and auditing. **Potential design options:** Consistent use of [Azure Blueprints](/azure/governance/blueprints) to manage automated deployments allows consistent deployments of Azure resources that adhere to your organization's governance standards and policies. diff --git a/docs/cloud-adoption/governance/security-baseline/business-risks.md b/docs/cloud-adoption/governance/security-baseline/business-risks.md index 9de43d44945..3a640f28484 100644 --- a/docs/cloud-adoption/governance/security-baseline/business-risks.md +++ b/docs/cloud-adoption/governance/security-baseline/business-risks.md @@ -34,7 +34,7 @@ The Security Baseline discipline covers the corporate policies and manual proces The Security Baseline discipline attempts to address core security-related business risks. Work with your business to identify these risks and monitor each of them for relevance as you plan for and implement your cloud deployments. -Risks will differ between organization, but the following serve as common security-related risks that you can use as a starting point for discussions within your Cloud Governance team: +Risks will differ between organization, but the following serve as common security-related risks that you can use as a starting point for discussions within your cloud governance team: - **Data breach:** Inadvertent exposure or loss of sensitive cloud-hosted data can lead to losing customers, contractual issues, or legal consequences. - **Service disruption:** Outages and other performance issues due to insecure infrastructure interrupts normal operations and can result in lost productivity or lost business. diff --git a/docs/cloud-adoption/governance/security-baseline/compliance-processes.md b/docs/cloud-adoption/governance/security-baseline/compliance-processes.md index 8a897b63ddf..309f524990e 100644 --- a/docs/cloud-adoption/governance/security-baseline/compliance-processes.md +++ b/docs/cloud-adoption/governance/security-baseline/compliance-processes.md @@ -13,7 +13,7 @@ ms.custom: governance # Security Baseline policy compliance processes -This article discusses an approach to policy adherence processes that govern [Security Baseline](./index.md). Effective governance of cloud security starts with recurring manual processes designed to detect vulnerabilities and impose policies to remediate those security risks. This requires regular involvement of the Cloud Governance team and interested business and IT stakeholders to review and update policy and ensure policy compliance. In addition, many ongoing monitoring and enforcement processes can be automated or supplemented with tooling to reduce the overhead of governance and allow for faster response to policy deviation. +This article discusses an approach to policy adherence processes that govern [Security Baseline](./index.md). Effective governance of cloud security starts with recurring manual processes designed to detect vulnerabilities and impose policies to remediate those security risks. This requires regular involvement of the cloud governance team and interested business and IT stakeholders to review and update policy and ensure policy compliance. In addition, many ongoing monitoring and enforcement processes can be automated or supplemented with tooling to reduce the overhead of governance and allow for faster response to policy deviation. ## Planning, review, and reporting processes @@ -23,17 +23,17 @@ The best Security Baseline tools in the cloud are only as good as the processes **Deployment planning:** Before deploying any workload or asset, perform a security review to identify any new risks and ensure all access and data security policy requirements are met. -**Deployment testing:** As part of the deployment process for any workload or asset, the Cloud Governance team, in cooperation with your corporate security teams, will be responsible for reviewing the deployment to validate security policy compliance. +**Deployment testing:** As part of the deployment process for any workload or asset, the cloud governance team, in cooperation with your corporate security teams, will be responsible for reviewing the deployment to validate security policy compliance. **Annual planning:** On an annual basis, perform a high-level review of Security Baseline strategy. Explore future corporate priorities and updated cloud adoption strategies to identify potential risk increase and other emerging security needs. Also use this time to review the latest Security Baseline best practices and integrate these into your policies and review processes. **Quarterly review and planning:** On a quarterly basis perform a review of security audit data and incident reports to identify any changes required in security policy. As part of this process, review the current cybersecurity landscape to proactively anticipate emerging threats, and update policy as appropriate. After the review is complete, align design guidance with updated policy. -This planning process is also a good time to evaluate the current membership of your Cloud Governance team for knowledge gaps related to new or evolving policy and risks related to security. Invite relevant IT staff to participate in reviews and planning as either temporary technical advisors or permanent members of your team. +This planning process is also a good time to evaluate the current membership of your cloud governance team for knowledge gaps related to new or evolving policy and risks related to security. Invite relevant IT staff to participate in reviews and planning as either temporary technical advisors or permanent members of your team. **Education and training:** On a bimonthly basis, offer training sessions to make sure IT staff and developers are up-to-date on the latest security policy requirements. As part of this process review and update any documentation, guidance, or other training assets to ensure they are in sync with the latest corporate policy statements. -**Monthly audit and reporting reviews:** On a monthly basis, perform an audit on all cloud deployments to assure their continued alignment with security policy. Review security related activities with IT staff and identify any compliance issues not already handled as part of the ongoing monitoring and enforcement process. The result of this review is a report for the Cloud Strategy team and each cloud adoption team to communicate overall adherence to policy. The report is also stored for auditing and legal purposes. +**Monthly audit and reporting reviews:** On a monthly basis, perform an audit on all cloud deployments to assure their continued alignment with security policy. Review security related activities with IT staff and identify any compliance issues not already handled as part of the ongoing monitoring and enforcement process. The result of this review is a report for the cloud strategy team and each cloud adoption team to communicate overall adherence to policy. The report is also stored for auditing and legal purposes. ## Ongoing monitoring processes @@ -43,7 +43,7 @@ Ensure that your security and IT teams have implemented automated monitoring sys ## Violation triggers and enforcement actions -Because security noncompliance can lead to critical and data exposure and service disruption risks, the Cloud Governance team should have visibility into serious policy violations. Ensure IT staff have clear escalation paths for reporting security issues to the governance team members best suited to identify and verify that policy issues are mitigated. +Because security noncompliance can lead to critical and data exposure and service disruption risks, the cloud governance team should have visibility into serious policy violations. Ensure IT staff have clear escalation paths for reporting security issues to the governance team members best suited to identify and verify that policy issues are mitigated. When violations are detected, you should take actions to realign with policy as soon as possible. Your IT team can automate most violation triggers using the tools outlined in the [Security Baseline toolchain for Azure](toolchain.md). diff --git a/docs/cloud-adoption/governance/security-baseline/discipline-improvement.md b/docs/cloud-adoption/governance/security-baseline/discipline-improvement.md index 3d85afb4734..839bd4a093d 100644 --- a/docs/cloud-adoption/governance/security-baseline/discipline-improvement.md +++ b/docs/cloud-adoption/governance/security-baseline/discipline-improvement.md @@ -21,7 +21,7 @@ This article outlines some potential tasks your company can engage in to better *Figure 1 - Adoption phases of the incremental approach to cloud governance.* -It's impossible for any one document to account for the requirements of all businesses. As such, this article outlines suggested minimum and potential example activities for each phase of the governance maturation process. The initial objective of these activities is to help you build a [Policy MVP](../journeys/index.md#an-incremental-approach-to-cloud-governance) and establish a framework for incremental policy evolution. Your Cloud Governance team will need to decide how much to invest in these activities to improve your Security Baseline governance capabilities. +It's impossible for any one document to account for the requirements of all businesses. As such, this article outlines suggested minimum and potential example activities for each phase of the governance maturation process. The initial objective of these activities is to help you build a [Policy MVP](../journeys/index.md#an-incremental-approach-to-cloud-governance) and establish a framework for incremental policy evolution. Your cloud governance team will need to decide how much to invest in these activities to improve your Security Baseline governance capabilities. > [!CAUTION] > Neither the minimum or potential activities outlined in this article are aligned to specific corporate policies or third-party compliance requirements. This guidance is designed to help facilitate the conversations that will lead to alignment of both requirements with a cloud governance model. diff --git a/docs/cloud-adoption/governance/security-baseline/index.md b/docs/cloud-adoption/governance/security-baseline/index.md index 7ea821966fb..54b1c2b3fcc 100644 --- a/docs/cloud-adoption/governance/security-baseline/index.md +++ b/docs/cloud-adoption/governance/security-baseline/index.md @@ -14,12 +14,12 @@ layout: LandingPage # Security Baseline discipline overview -Security Baseline is one of the [Five Disciplines of Cloud Governance](../governance-disciplines.md) within the [Cloud Adoption Framework governance model](../index.md). Security is a component of any IT deployment, and the cloud introduces unique security concerns. Many businesses are subject to regulatory requirements that make protecting sensitive data a major organizational priority when considering a cloud transformation. Identifying potential security threats to your cloud environment and establishing processes and procedures for addressing these threats should be a priority for any IT Security or Cybersecurity team. The Security Baseline discipline ensures technical requirements and security constraints are consistently applied to cloud environments, as those requirements mature. +Security Baseline is one of the [Five Disciplines of Cloud Governance](../governance-disciplines.md) within the [Cloud Adoption Framework governance model](../index.md). Security is a component of any IT deployment, and the cloud introduces unique security concerns. Many businesses are subject to regulatory requirements that make protecting sensitive data a major organizational priority when considering a cloud transformation. Identifying potential security threats to your cloud environment and establishing processes and procedures for addressing these threats should be a priority for any IT security or cybersecurity team. The Security Baseline discipline ensures technical requirements and security constraints are consistently applied to cloud environments, as those requirements mature. > [!NOTE] > Security Baseline governance does not replace the existing IT teams, processes, and procedures that your organization uses to secure cloud-deployed resources. The primary purpose of this discipline is to identify security-related business risks and provide risk-mitigation guidance to the IT staff responsible for security infrastructure. As you develop governance policies and processes make sure to involve relevant IT teams in your planning and review processes. -This article outlines the approach to developing a Security Baseline discipline as part of your cloud governance strategy. The primary audience for this guidance is your organization's cloud architects and other members of your Cloud Governance team. However, the decisions, policies, and processes that emerge from this discipline should involve engagement and discussions with relevant members of your IT and security teams, especially those technical leaders responsible for implementing networking, encryption, and identity services. +This article outlines the approach to developing a Security Baseline discipline as part of your cloud governance strategy. The primary audience for this guidance is your organization's cloud architects and other members of your cloud governance team. However, the decisions, policies, and processes that emerge from this discipline should involve engagement and discussions with relevant members of your IT and security teams, especially those technical leaders responsible for implementing networking, encryption, and identity services. Making the correct security decisions is critical to the success of your cloud deployments and wider business success. If your organization lacks in-house expertise in cybersecurity, consider engaging external security consultants as a component of this discipline. Also consider engaging [Microsoft Consulting Services](https://www.microsoft.com/enterprise/services), the [Microsoft FastTrack](https://azure.microsoft.com/programs/azure-fasttrack) cloud adoption service, or other external cloud adoption experts to discuss concerns related to this discipline. @@ -32,7 +32,7 @@ Actionable policy statements and the resulting architecture requirements serve a ## Developing Security Baseline governance policy statements -The following six steps offer examples and potential options to consider when developing Security Baseline governance. Use each step as a starting point for discussions within your Cloud Governance team and with affected business, IT, and security teams across your organization to establish the policies and processes needed to manage security-related risks. +The following six steps offer examples and potential options to consider when developing Security Baseline governance. Use each step as a starting point for discussions within your cloud governance team and with affected business, IT, and security teams across your organization to establish the policies and processes needed to manage security-related risks. diff --git a/docs/cloud-adoption/governance/security-baseline/metrics-tolerance.md b/docs/cloud-adoption/governance/security-baseline/metrics-tolerance.md index 3bc3d06e030..bac12372334 100644 --- a/docs/cloud-adoption/governance/security-baseline/metrics-tolerance.md +++ b/docs/cloud-adoption/governance/security-baseline/metrics-tolerance.md @@ -25,7 +25,7 @@ Every organization has different security environments and requirements and diff - **Number of sensitive data stores:** Number of storage end points or databases that contain sensitive data and should be protected. - **Number of unencrypted data stores:** Number of sensitive data stores that are not encrypted. - **Attack surface:** How many total data sources, services, and applications will be cloud-hosted. What percentage of these data sources are classified as sensitive? What percentage of these applications and services are mission-critical? -- **Covered standards:** Number of security standards defined by the Security team. +- **Covered standards:** Number of security standards defined by the security team. - **Covered resources:** Deployed assets that are covered by security standards. - **Overall standards compliance:** Ratio of compliance adherence to security standards. - **Attacks by severity:** How many coordinated attempts to disrupt your cloud-hosted services, such as through Distributed Denial of Service (DDoS) attacks, does your infrastructure experience? What is the size and severity of these attacks? @@ -50,7 +50,7 @@ Once you have a baseline, establish minimum benchmarks representing an unaccepta - **Patching trigger.** A company where deployed virtual machines or services where OS or software patches have not been applied in the last _x_ days. A Security Baseline discipline can be used to ensure patching is kept up-to-date within a required schedule. - **Security-focused.** Some companies will have strong security and data confidentiality requirements even for test and experimental workloads. These companies will need to invest in the Security Baseline discipline before any deployments can begin. -The exact metrics and triggers you use to gauge risk tolerance and the level of investment in the Security Baseline discipline will be specific to your organization, but the examples above should serve as a useful base for discussion within your Cloud Governance team. +The exact metrics and triggers you use to gauge risk tolerance and the level of investment in the Security Baseline discipline will be specific to your organization, but the examples above should serve as a useful base for discussion within your cloud governance team. ## Next steps diff --git a/docs/cloud-adoption/governance/security-baseline/policy-statements.md b/docs/cloud-adoption/governance/security-baseline/policy-statements.md index f1e0310f9a1..66cb93e5979 100644 --- a/docs/cloud-adoption/governance/security-baseline/policy-statements.md +++ b/docs/cloud-adoption/governance/security-baseline/policy-statements.md @@ -25,7 +25,7 @@ The following sample policy statements address common security-related business **Technical risk:** Assets that are not correctly identified as mission-critical or involving sensitive data may not receive sufficient protections, leading to potential data leaks or business disruptions. -**Policy statement:** All deployed assets must be categorized by criticality and data classification. Classifications must be reviewed by the Cloud Governance team and the application owner before deployment to the cloud. +**Policy statement:** All deployed assets must be categorized by criticality and data classification. Classifications must be reviewed by the cloud governance team and the application owner before deployment to the cloud. **Potential design option:** Establish [resource tagging standards](../../decision-guides/resource-tagging/index.md) and ensure IT staff apply them consistently to any deployed resources using [Azure resource tags](/azure/azure-resource-manager/resource-group-using-tags). diff --git a/docs/cloud-adoption/includes/governance/implementation-process.md b/docs/cloud-adoption/includes/governance/implementation-process.md index 2ab1a2aa341..d6467775dcb 100644 --- a/docs/cloud-adoption/includes/governance/implementation-process.md +++ b/docs/cloud-adoption/includes/governance/implementation-process.md @@ -3,7 +3,7 @@ ## Dependent decisions -The following decisions come from teams outside of the Cloud Governance team. The implementation of each will come from those same teams. However, the Cloud Governance team is responsible for implementing a solution to validate that those implementations are consistently applied. +The following decisions come from teams outside of the cloud governance team. The implementation of each will come from those same teams. However, the cloud governance team is responsible for implementing a solution to validate that those implementations are consistently applied. ### Identity Baseline @@ -27,7 +27,7 @@ Given the lack of requirements, IT security is playing it safe and has required In this pattern, cloud networks can only connect to on-premises resources over an existing VPN that is compatible with Azure. Traffic over that connection will be treated like any traffic coming from a demilitarized zone. Additional considerations may be required on the on-premises edge device to securely handle traffic from Azure. -The Cloud Governance team has proactively invited members of the networking and IT security teams to regular meetings, in order to stay ahead of networking demands and risks. +The cloud governance team has proactively invited members of the networking and IT security teams to regular meetings, in order to stay ahead of networking demands and risks. ### Security Baseline: Encryption @@ -53,6 +53,6 @@ The following decisions represent the patterns to be enforced through the policy **Identity Baseline**. Azure Blueprints will set RBAC requirements at a subscription level to ensure that consistent identity is configured for all subscriptions. -**Security Baseline: Networking**. The Cloud Governance team maintains a Resource Manager template for establishing a VPN gateway between Azure and the on-premises VPN device. When an application team requires a VPN connection, the Cloud Governance team will apply the gateway Resource Manager template via Azure Blueprints. +**Security Baseline: Networking**. The cloud governance team maintains a Resource Manager template for establishing a VPN gateway between Azure and the on-premises VPN device. When an application team requires a VPN connection, the cloud governance team will apply the gateway Resource Manager template via Azure Blueprints. **Security Baseline: Encryption**. At this point in the journey, no policy enforcement is required in this area. This will be revisited during later evolutions. \ No newline at end of file diff --git a/docs/cloud-adoption/includes/governance/policy-statements.md b/docs/cloud-adoption/includes/governance/policy-statements.md index 5d152d6c5be..f1edec7d9b5 100644 --- a/docs/cloud-adoption/includes/governance/policy-statements.md +++ b/docs/cloud-adoption/includes/governance/policy-statements.md @@ -8,7 +8,7 @@ The following policy statements establish the requirements needed to remediate t Cost Management: - For tracking purposes, all assets must be assigned to an application owner within one of the core business functions. -- When cost concerns arise, additional governance requirements will be established with the Finance team. +- When cost concerns arise, additional governance requirements will be established with the finance team. Security Baseline: @@ -34,7 +34,7 @@ Deployment Acceleration: ## Processes -No budget has been allocated for ongoing monitoring and enforcement of these governance policies. Because of that, the Cloud Governance team has some ad hoc ways to monitor adherence to policy statements. +No budget has been allocated for ongoing monitoring and enforcement of these governance policies. Because of that, the cloud governance team has some ad hoc ways to monitor adherence to policy statements. -- **Education:** The Cloud Governance team is investing time to educate the cloud adoption teams on the governance journeys that support these policies. -- **Deployment reviews:** Before deploying any asset, the Cloud Governance team will review the governance journey with the cloud adoption teams. +- **Education:** The cloud governance team is investing time to educate the cloud adoption teams on the governance journeys that support these policies. +- **Deployment reviews:** Before deploying any asset, the cloud governance team will review the governance journey with the cloud adoption teams. diff --git a/docs/cloud-adoption/index.md b/docs/cloud-adoption/index.md index df28db72104..9b7ad186e5c 100644 --- a/docs/cloud-adoption/index.md +++ b/docs/cloud-adoption/index.md @@ -1,8 +1,8 @@ --- title: "Microsoft Cloud Adoption Framework for Azure" description: An overview of the Microsoft Cloud Adoption Framework for Azure. -ms.service: architecture-center -ms.subservice: enterprise-cloud-adoption +ms.service: cloud-adoption-framework +ms.subservice: overview ms.custom: homepage layout: LandingPage ms.topic: landing-page @@ -12,19 +12,19 @@ ms.date: 07/04/2019 # Microsoft Cloud Adoption Framework for Azure -The Microsoft Cloud Adoption Framework for Azure is the One Microsoft voice for cloud adoption, consolidating and sharing best practices from Microsoft employees, partners, and customers. The framework gives enterprise customers tools, guidance, and narratives that help shape technology, business, and people strategies for driving desired business outcomes during their adoption effort. This lifecycle "product" aligns guidance to various stages and iterations of the typical cloud adoption lifecycle, ensuring easy access to the right guidance at the right time. +The Cloud Adoption Framework is the One Microsoft approach to cloud adoption in Azure, consolidating and sharing best practices from Microsoft employees, partners, and customers. The framework gives enterprise customers a set of tools, guidance, and narratives that help shape technology, business, and people strategies for driving desired business outcomes during their adoption effort. This guidance aligns to various stages and iterations of the typical cloud adoption lifecycle, ensuring easy access to the right guidance at the right time. ![Cloud Adoption Framework overview](./_images/cloud-adoption-framework-overview.png) ## Getting started: Executive summaries -To customers who are new to the Cloud Adoption Framework, we offer three introductory articles: [Migrate](./getting-started/migrate.md), [Innovate](./getting-started/innovate.md), and [Enable](./getting-started/enable.md). Each article provides an executive summary and a high-level journey through an enterprise's adoption lifecycle. +For customers who are new to the Cloud Adoption Framework, we offer three introductory articles: [Migrate](./getting-started/migrate.md), [Innovate](./getting-started/innovate.md), and [Enable](./getting-started/enable.md). Each article provides an executive summary and a high-level journey through an enterprise's adoption lifecycle. -For more specific guidance, see the following section, which lists and provides links to each of the various stages of the adoption lifecycle. +For more specific guidance, continue reading for links to each stage of the adoption lifecycle. -## Cloud Adoption Framework throughout the adoption lifecycle +## Use the Cloud Adoption Framework throughout the adoption lifecycle -Each section of the Cloud Adoption Framework maps to the preceding overview diagram. The list here can help you align to the section of the Cloud Adoption Framework that best matches your current stage in the cloud adoption lifecycle. +Each section of the Cloud Adoption Framework maps to the overview diagram above. This list will help you align to the section that best matches your current stage in the cloud adoption lifecycle. @@ -98,7 +98,7 @@ Each section of the Cloud Adoption Framework maps to the preceding overview diag

Migrate

- Migrate and modernize existing workloads + Migrate and modernize existing workloads.
@@ -154,7 +154,7 @@ The Cloud Adoption Framework is currently offered as a public preview. The frame - [Cloud migration](./migrate/index.md) - [Cloud governance](./governance/journeys/index.md) -We'll expand the Cloud Adoption Framework frequently as it moves closer to the GA release. The expansion will add both depth in each section and new sections of content. For more information, see the [Cloud Adoption Framework roadmap](./appendix/roadmap.md). +We'll expand the Cloud Adoption Framework frequently as it moves closer to the GA release. The expansion will add depth to each section as well as new sections of content. For more information, see the [Cloud Adoption Framework roadmap](./appendix/roadmap.md). ## Intent @@ -162,7 +162,7 @@ The cloud fundamentally changes how enterprises procure and use technology resou However, cloud adoption is only a means to an end. Successful cloud adoption starts well before a cloud platform vendor is selected. It begins when business and IT decision makers realize that the cloud can accelerate a specific business transformation objective. The Cloud Adoption Framework can help them align strategies for business, culture, and technical change to achieve their desired business outcomes. -The Cloud Adoption Framework provides technical guidance for Microsoft Azure. Because enterprise customers might still be in the process of choosing a cloud vendor, the framework provides cloud-agnostic guidance for higher-level decisions whenever possible. +The Cloud Adoption Framework provides technical guidance for Microsoft Azure. Because enterprise customers might still be in the process of choosing a cloud vendor, the framework provides cloud-agnostic guidance for strategic decisions whenever possible. ## Intended audience @@ -170,7 +170,7 @@ This guidance affects the business, technology, and culture of enterprises. The Enter the **Cloud Architect**. The Cloud Architect serves as the thought leader and facilitator to bring these audiences together. We've designed this collection of guides to help Cloud Architects facilitate the right conversations with the right audiences and drive decision-making. Business transformation that's empowered by the cloud depends on the Cloud Architect role to help guide decisions throughout the business and IT. -Each section of the Cloud Adoption Framework represents a different specialization or variant of the Cloud Architect role. These sections also create opportunities to share cloud architecture responsibilities across a team of Cloud Architects. For example, the governance section is designed for Cloud Architects who have a passion for mitigating technical risks. Some cloud providers refer to these specialists as cloud custodians; we prefer the term _cloud guardian_ or, collectively, the _Cloud Governance team_. +Each section of the Cloud Adoption Framework represents a different specialization or variant of the Cloud Architect role. These sections also create opportunities to share cloud architecture responsibilities across a team of Cloud Architects. For example, the governance section is designed for Cloud Architects who have a passion for mitigating technical risks. Some cloud providers refer to these specialists as cloud custodians; we prefer the term _cloud guardian_ or, collectively, the _cloud governance team_. ## How to use the Microsoft Cloud Adoption Framework for Azure diff --git a/docs/cloud-adoption/migrate/about.md b/docs/cloud-adoption/migrate/about.md index d9a3dc7e984..79c379129b4 100644 --- a/docs/cloud-adoption/migrate/about.md +++ b/docs/cloud-adoption/migrate/about.md @@ -21,11 +21,11 @@ The guidance in this section of the Cloud Adoption Framework is designed for two - Provide actionable migration guides that represent common experiences that customers often encounter. Each guide encapsulates the process and tools needed to be successful in a cloud migration effort. By necessity, the design guidance is specific to Azure. All other guidance in these journeys could be applied as part of a cloud-agnostic or multicloud approach. - Help readers create personalized migration plans that can meet a variety of business needs, including migration to multiple public clouds, through detailed guidance on the development of processes, role and responsibilities, and change management controls. -This content is intended for the Cloud Adoption team. It is also relevant to cloud architects that need to develop a strong foundation in cloud migration. +This content is intended for the cloud adoption team. It is also relevant to cloud architects that need to develop a strong foundation in cloud migration. ## Intended Audience -The guidance in the Cloud Adoption Framework affects the business, technology, and culture of enterprises. This section significantly affects application owners, change management personnel (such as PMO and agile management personnel) finance and line-of-business leaders, and the Cloud Adoption team. There are various dependencies on these personas that will require facilitation by the cloud architects using this guidance. Facilitation with these teams may be a one-time effort, but in some cases, it will result in recurring interactions with these other personas. +The guidance in the Cloud Adoption Framework affects the business, technology, and culture of enterprises. This section significantly affects application owners, change management personnel (such as PMO and agile management personnel) finance and line-of-business leaders, and the cloud adoption team. There are various dependencies on these personas that will require facilitation by the cloud architects using this guidance. Facilitation with these teams may be a one-time effort, but in some cases, it will result in recurring interactions with these other personas. The Cloud Architect serves as the thought leader and facilitator to bring these audiences together. The content in this collection of guides is designed to help the Cloud Architect facilitate the right conversation, with the right audience, to drive necessary decisions. Business transformation that is empowered by the cloud depends on the Cloud Architect role to help guide decisions throughout the business and IT. diff --git a/docs/cloud-adoption/migrate/expanded-scope/balance-the-portfolio.md b/docs/cloud-adoption/migrate/expanded-scope/balance-the-portfolio.md index 3dace6f3952..1fd32b7fe46 100644 --- a/docs/cloud-adoption/migrate/expanded-scope/balance-the-portfolio.md +++ b/docs/cloud-adoption/migrate/expanded-scope/balance-the-portfolio.md @@ -34,17 +34,17 @@ The following table can help document and share desired business outcomes. It's > [!IMPORTANT] > The above table is a fictional example and should not used to set priorities. In many cases, this table could considered an antipattern by placing cost savings above customer experiences. -The above table could accurately represent the priorities of the cloud strategy team and cloud adoption team overseeing a cloud migration. Due to short-term constraints, this team is placing a higher emphasis on IT cost reduction and prioritizing a datacenter exit as a means to achieve the desired IT cost reductions. However, by documenting the competing priorities in this table, the Cloud Adoption team is empowered to help the Cloud Strategy team identify opportunities to better align implementation of the overarching portfolio strategy. +The above table could accurately represent the priorities of the cloud strategy team and the cloud adoption team overseeing a cloud migration. Due to short-term constraints, this team is placing a higher emphasis on IT cost reduction and prioritizing a datacenter exit as a means to achieve the desired IT cost reductions. However, by documenting the competing priorities in this table, the cloud adoption team is empowered to help the cloud strategy team identify opportunities to better align implementation of the overarching portfolio strategy. ### Move fast while maintaining balance -The guidance regarding [incremental rationalization of the digital estate](../../digital-estate/index.md) suggests an approach in which the rationalization starts with an unbalanced position. The Cloud Strategy team should evaluate every workload for compatibility with a rehost approach. Such an approach is suggested because it allows for the rapid evaluation of a complex digital estate based on quantitative data. Making such an initial assumption allows the Cloud Adoption team to engage quickly, reducing time to business outcomes. However, as stated in that article, qualitative questions will provide the necessary balance in the portfolio. This article documents the process for creating the promised balance. +The guidance regarding [incremental rationalization of the digital estate](../../digital-estate/index.md) suggests an approach in which the rationalization starts with an unbalanced position. The cloud strategy team should evaluate every workload for compatibility with a rehost approach. Such an approach is suggested because it allows for the rapid evaluation of a complex digital estate based on quantitative data. Making such an initial assumption allows the cloud adoption team to engage quickly, reducing time to business outcomes. However, as stated in that article, qualitative questions will provide the necessary balance in the portfolio. This article documents the process for creating the promised balance. ### Importance of sunset and retire decisions The table in the [documenting business outcomes](#documenting-business-outcomes) section above misses a key outcome that would support the number one objective of reducing IT costs. When IT costs reductions rank anywhere in the list of business outcomes, it is important to consider the potential to sunset or retire workloads. In some scenarios, cost savings can come from NOT migrating workloads that don't warrant a short-term investment. Some customers have reported cost savings in excess of 20% total cost reductions by retiring underutilized workloads. -To balance the portfolio, better reflecting sunset and retire decisions, the cloud strategy team and cloud adoption team are encouraged to ask the following questions of each workload within assess and migrate processes: +To balance the portfolio, better reflecting sunset and retire decisions, the cloud strategy team and the cloud adoption team are encouraged to ask the following questions of each workload within assess and migrate processes: - Has the workload been used by end users in the past six months? - Is end-user traffic consistent or growing? @@ -74,7 +74,7 @@ Based on the data from the table in the [documenting business outcomes](#documen To reduce complexity, it is advised that the reader follow a traditional approach to portfolio rationalization, but in an iterative model. The following steps outline a qualitative model to such an approach: - The cloud strategy team maintains a prioritized backlog of workloads to be migrated. -- The cloud strategy team and cloud adoption team host a release planning meeting prior to the completion of each release. +- The cloud strategy team and the cloud adoption team host a release planning meeting prior to the completion of each release. - In the release planning meeting, the teams agree on the top 5 to 10 workloads in the prioritized backlog. - Outside of the release planning meeting, the cloud adoption team asks the following questions of application owners and subject matter experts: - Could this application be replaced with a platform as a service (PaaS) equivalent? @@ -102,7 +102,7 @@ Portfolio rationalization requires diversity of technical effort. It is tempting It is advised that these diverse efforts are segmented across two or more cloud adoption teams. Using a two team model as an example mode of execution, Team 1 is the Migration Team and Team 2 is the Innovation Team. For larger efforts, these teams could be further segmented to address other approaches like Replace/PaaS efforts or Minor Refactoring. The following outlines the skills and roles needed to Rehost, Refactor, or Minor Refactoring: -**Rehost:** Rehost requires team members to implement infrastructure focused changes. Generally using a tool like Azure Site Recovery to migrate VMs or other assets to Azure. This work aligns well to datacenter admins or IT implementors. The Cloud Migration team is well structured to deliver this work at high scale. This is the fastest approach to migrate existing assets in most scenarios. +**Rehost:** Rehost requires team members to implement infrastructure focused changes. Generally using a tool like Azure Site Recovery to migrate VMs or other assets to Azure. This work aligns well to datacenter admins or IT implementors. The cloud migration team is well structured to deliver this work at high scale. This is the fastest approach to migrate existing assets in most scenarios. **Refactor:** Refactor requires team members to modify source code, change the architecture of an application, or adopt new cloud services. Generally this effort would use development tools like Visual Studio and deployment pipeline tools like Azure DevOps to redeploy modernized applications to Azure. This work aligns well to application development roles or DevOps pipeline development roles. Cloud Innovation Team is best structured to deliver this work. It can take longer to replace existing assets with cloud assets in this approach, but the apps can take advantage of cloud-native features. diff --git a/docs/cloud-adoption/migrate/expanded-scope/governance-or-compliance.md b/docs/cloud-adoption/migrate/expanded-scope/governance-or-compliance.md index a495052eb0f..1742112e7ba 100644 --- a/docs/cloud-adoption/migrate/expanded-scope/governance-or-compliance.md +++ b/docs/cloud-adoption/migrate/expanded-scope/governance-or-compliance.md @@ -39,7 +39,7 @@ Microsoft Services provides solution offerings that can align to the Cloud Adopt ## Assess process changes -During assessment, additional decisions are required to align to the required governance approach. The Cloud Governance team should provide all members of the Cloud Adoption team with any policy statements, architectural guidance, or governance/compliance requirements prior to the assessment of a workload. +During assessment, additional decisions are required to align to the required governance approach. The cloud governance team should provide all members of the cloud adoption team with any policy statements, architectural guidance, or governance/compliance requirements prior to the assessment of a workload. ### Suggested action during the assess process @@ -57,11 +57,11 @@ For guidance on developing governance guidance based on the Cloud Adoption Frame ## Optimize and promote process changes -During the optimization and promotion processes, it is advised that the Cloud Governance team invest time to test and validate adherence to governance and compliance standards. Additionally, this step is a good time to inject processes for the Cloud Governance team to curate templates that could provide additional [deployment acceleration](/azure/architecture/cloud-adoption/governance/deployment-acceleration) for future projects. +During the optimization and promotion processes, it is advised that the cloud governance team invest time to test and validate adherence to governance and compliance standards. Additionally, this step is a good time to inject processes for the cloud governance team to curate templates that could provide additional [deployment acceleration](/azure/architecture/cloud-adoption/governance/deployment-acceleration) for future projects. ### Suggested action during the optimize and promote process -During this process, it is advised that the project plan includes time allocations for the Cloud Governance team to execute a compliance review for each workload planned for production promotion. +During this process, it is advised that the project plan includes time allocations for the cloud governance team to execute a compliance review for each workload planned for production promotion. ## Next steps diff --git a/docs/cloud-adoption/migrate/expanded-scope/index.md b/docs/cloud-adoption/migrate/expanded-scope/index.md index c8f5cac59fb..903a93dff48 100644 --- a/docs/cloud-adoption/migrate/expanded-scope/index.md +++ b/docs/cloud-adoption/migrate/expanded-scope/index.md @@ -50,14 +50,14 @@ To help you understand each scope expansion scenario, the following list will br ### Business-driven scope changes -- **Balancing the cloud adoption portfolio:** The Cloud Strategy team is interested in investing more heavily in migration (rehosting existing workloads and applications with a minimum of modifications) or innovation (refactoring or rebuilding those workloads and applications using modern cloud technology). Often, a balance between the two priorities is the key to success. In this guide, the topic of balancing the cloud adoption portfolio is a common one, addressed in each of the migrate processes. +- **Balancing the cloud adoption portfolio:** The cloud strategy team is interested in investing more heavily in migration (rehosting existing workloads and applications with a minimum of modifications) or innovation (refactoring or rebuilding those workloads and applications using modern cloud technology). Often, a balance between the two priorities is the key to success. In this guide, the topic of balancing the cloud adoption portfolio is a common one, addressed in each of the migrate processes. - **Support global markets:** The business operates in multiple geographic regions with disparate data sovereignty requirements. To meet those requirements, additional considerations should be factored into the prerequisite review and distribution of assets during migration. ### Culture-driven scope changes - **Change management and approval processes:** When your organization's culture is complex, highly matrixed, or siloed the processes related to change management and approvals becomes challenging. Guidance on managing this complexity can be found in assess, migrate, and optimize processes. - **Executive readiness:** Proper levels of executive support and leadership are critical to the success of a migration effort. If the executive team is not ready to engage, then support is unlikely to follow. This complexity is addressed during the prerequisite and assess processes. -- **Skills readiness:** When the Cloud Adoption team or other supporting teams are not ready to execute, it can quickly inject complexity throughout the migration effort. This challenge is addressed during each of the migration processes in a specific page on skills readiness. +- **Skills readiness:** When the cloud adoption team or other supporting teams are not ready to execute, it can quickly inject complexity throughout the migration effort. This challenge is addressed during each of the migration processes in a specific page on skills readiness. - **Aligning support (Partner, service, and support options):** Within each of the the processes outlined, there are ways in which a partner, services from the cloud vendor, and support from the cloud vendor can aid in execution. In each of the processes sections a page on support alignment will discuss the options further. ### Technical strategy-driven scope changes @@ -66,7 +66,7 @@ To help you understand each scope expansion scenario, the following list will br - **Migrating at scale:** Migrations exceeding 2,000 assets are likely to run into constraints that require additional planning and a disciplined approach to execution. The Assess and Migrate processes are adjusted to account for scale complexity. - **Multiple datacenters:** Migration of multiple datacenters adds a great deal of complexity. During the Assess, Migrate, Optimization, and Manage processes, additional considerations are discussed. - **Change management and solution documentation:** Large digital estate inventories, complex solution architectures, long standing technical debt, and interdependencies can create a complexity that should be addressed during assess, migrate, and optimize processes. -- **Governance or compliance strategy:** When governance and compliance are vital to the success of a migration, additional alignment between IT Governance teams and the Cloud Adoption team is required. +- **Governance or compliance strategy:** When governance and compliance are vital to the success of a migration, additional alignment between IT Governance teams and the cloud adoption team is required. ### Workload-specific scope changes diff --git a/docs/cloud-adoption/migrate/expanded-scope/multiple-datacenters.md b/docs/cloud-adoption/migrate/expanded-scope/multiple-datacenters.md index 0e8a0c63d4e..b2ff3bb2be4 100644 --- a/docs/cloud-adoption/migrate/expanded-scope/multiple-datacenters.md +++ b/docs/cloud-adoption/migrate/expanded-scope/multiple-datacenters.md @@ -24,7 +24,7 @@ Before beginning the migration, you should create epics within the project manag Within each epic, the workloads to be assessed and migrated would be managed as features. Each asset within that workload would be managed as a user story. The work required to assess, migrate, optimize, promote, secure, and manage each asset would be represented as tasks for each asset. -Sprints or iterations would be then consist of a series of tasks required to migrate the assets and user stories committed to by the Cloud Adoption team. Releases would then consist of one or more workloads or features to be promoted to production. +Sprints or iterations would be then consist of a series of tasks required to migrate the assets and user stories committed to by the cloud adoption team. Releases would then consist of one or more workloads or features to be promoted to production. ## Assess process changes diff --git a/docs/cloud-adoption/migrate/expanded-scope/multiple-regions.md b/docs/cloud-adoption/migrate/expanded-scope/multiple-regions.md index 0a88725375c..ba14087fb83 100644 --- a/docs/cloud-adoption/migrate/expanded-scope/multiple-regions.md +++ b/docs/cloud-adoption/migrate/expanded-scope/multiple-regions.md @@ -43,7 +43,7 @@ The following table can aid in documenting the findings from the steps above: Around the world, government organizations have begun establishing data sovereignty requirements, like General Data Protection Regulation (GDPR). Compliance requirements of this nature often require localization within a specific region or even within a specific country to protect their citizens. In some cases, data pertaining to customers, employees, or partners must be stored on a cloud platform within the same region as the end user. -Addressing this challenge has been a significant motivation for cloud migrations for companies that operate on a global scale. To maintain compliance requirements, some companies have chosen to deploy duplicate IT assets to cloud providers within the region. In the example table above, Germany would be a good example of this scenario. In this example, there are customer, partners, and employees in Germany, but no existing IT assets. This company may choose to deploy some assets to a datacenter within the GDPR area, potentially even using the German Azure datacenters. An understanding of the data affected by GDPR would help the Cloud Adoption team understand the best migration approach in this case. +Addressing this challenge has been a significant motivation for cloud migrations for companies that operate on a global scale. To maintain compliance requirements, some companies have chosen to deploy duplicate IT assets to cloud providers within the region. In the example table above, Germany would be a good example of this scenario. In this example, there are customer, partners, and employees in Germany, but no existing IT assets. This company may choose to deploy some assets to a datacenter within the GDPR area, potentially even using the German Azure datacenters. An understanding of the data affected by GDPR would help the cloud adoption team understand the best migration approach in this case. ### Why is the location of end users relevant? @@ -65,9 +65,9 @@ This approach is driven by quantifiable information. As such, the following appr ## Suggested prerequisites -It is suggested that the Cloud Adoption team begin with the migration of a simple workload using the [Azure migration guide](../azure-migration-guide/index.md), before attempting to address global scale. This will ensure the team is familiar with the general process of cloud migration prior to attempting a more complex migration scenario. +It is suggested that the cloud adoption team begin with the migration of a simple workload using the [Azure migration guide](../azure-migration-guide/index.md), before attempting to address global scale. This will ensure the team is familiar with the general process of cloud migration prior to attempting a more complex migration scenario. -When scope for a migration includes multiple regions, the following readiness considerations should be evaluated by the Cloud Adoption team: +When scope for a migration includes multiple regions, the following readiness considerations should be evaluated by the cloud adoption team: - Data sovereignty might require localization of some assets, but there are a many assets that may not be governed by those compliance constraints. Things like logging, reporting, network routing, identity, and other central IT services may be eligible to be hosted as shared services across multiple subscriptions or even multiple regions. It is advised that the cloud adoption team evaluate a share service model to those services, as outlined in the [reference architecture for a hub and spoke topology with shared services](/azure/architecture/reference-architectures/hybrid-networking/shared-services) - When deploying multiple instances of similar environments, an environment factory could create consistency, improve governance, and accelerate deployment. The [large enterprise governance journey](../../governance/journeys/large-enterprise/index.md) establishes an approach that creates an environment factory that scales across multiple regions. @@ -79,7 +79,7 @@ Once the team is comfortable with the baseline approach and readiness is aligned - **Initial digital estate rationalization:** Whenever complexity is introduced into a migration strategy, an initial digital estate rationalization should be completed. See the guidance on [digital estate rationalization](../../digital-estate/index.md) for assistance. - **Additional digital estate requirements:** Establish tagging policies to identify any workload affected by data sovereignty requirements. Required tags should begin in the digital estate rationalization and carry through to the migrated assets. - **Evaluate a hub and spoke model:** Distributed systems often share common dependencies. Those dependencies can often be addressed through the implementation of a hub and spoke model. While such a model is out of scope for the migration process, it should be flagged for consideration during future iterations of the [Ready processes](../../ready/index.md). -- **Prioritization of the migration backlog:** When network changes are required to support the production deployment of a workload that supports multiple regions, it is important for the Cloud Strategy team to track and manage escalations regarding those network changes. The higher level of executive support will aid in accelerating the change. However, the more important impact is that it gives the strategy team an ability to reprioritize the backlog to ensure that global workloads aren't blocked by network changes. Such workloads should only be prioritized, after the network changes are complete. +- **Prioritization of the migration backlog:** When network changes are required to support the production deployment of a workload that supports multiple regions, it is important for the cloud strategy team to track and manage escalations regarding those network changes. The higher level of executive support will aid in accelerating the change. However, the more important impact is that it gives the strategy team an ability to reprioritize the backlog to ensure that global workloads aren't blocked by network changes. Such workloads should only be prioritized, after the network changes are complete. These prerequisites will help establish processes that can address this complexity during execution of the migration strategy. @@ -103,7 +103,7 @@ When dealing with global asset and user base complexities, there are a few key a ## Migrate process changes -When migrating an application that must be deployed to multiple regions, there are a few considerations the Cloud Adoption team must take into account. These considerations consist of Azure Site Recovery vault design, configuration/process server design, network bandwidth designs, and data synchronization. +When migrating an application that must be deployed to multiple regions, there are a few considerations the cloud adoption team must take into account. These considerations consist of Azure Site Recovery vault design, configuration/process server design, network bandwidth designs, and data synchronization. ### Suggested action during the migrate process @@ -133,7 +133,7 @@ Addressing global complexity during optimization and promotion could require dup **Business testing:** In conjunction with the business change plan, business testing may be required in each region to ensure adequate performance and adherence to the modified networking routing patterns. -**Promotion flights:** Often promotion happens as a single activity, rerouting production traffic to the migrated workloads. In the case of global release efforts, it is advised that promotion be delivered in flights (or predefined collections of users). This allows the Cloud Strategy team and Cloud Adoption team to better observe performance and improve support of users in each region. Promotion flights are often controlled at the networking level by changing the routing of specific IP ranges from the source workload assets to the newly migrated assets. After a specified collection of end users have been migrated, the next group can be rerouted. +**Promotion flights:** Often promotion happens as a single activity, rerouting production traffic to the migrated workloads. In the case of global release efforts, it is advised that promotion be delivered in flights (or predefined collections of users). This allows the cloud strategy team and the cloud adoption team to better observe performance and improve support of users in each region. Promotion flights are often controlled at the networking level by changing the routing of specific IP ranges from the source workload assets to the newly migrated assets. After a specified collection of end users have been migrated, the next group can be rerouted. **Flight optimization:** One of the benefits of promotion flights, is that it allows for deeper observations and additional optimization of the deployed assets. After a brief period of production usage by the first flight, additional refinement of the migrated assets is suggested, when allowed by IT operation procedures. diff --git a/docs/cloud-adoption/migrate/migration-considerations/assess/approve.md b/docs/cloud-adoption/migrate/migration-considerations/assess/approve.md index 70825fcf41a..3182ae38e03 100644 --- a/docs/cloud-adoption/migrate/migration-considerations/assess/approve.md +++ b/docs/cloud-adoption/migrate/migration-considerations/assess/approve.md @@ -27,13 +27,13 @@ Prior to migration, it is important to prepare the workload’s business owner f 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. +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 Your IT teams likely have existing mechanisms for managing change involving your on-premises assets. Typically these mechanisms are governed by traditional Information Technology Infrastructure Library–based (ITIL-based) change management processes. In many enterprise migrations, these processes involve a Change Advisory Board (CAB) that is responsible for reviewing, documenting, and approving all IT-related requests for changes (RFC). -The CAB generally includes experts from multiple IT and Business teams, offering a variety of perspectives and detailed review for all IT-related changes. 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. +The CAB generally includes experts from multiple IT and business teams, offering a variety of perspectives and detailed review for all IT-related changes. 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 @@ -41,29 +41,29 @@ Organizational readiness for the approval of technical change is among the most ### 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. +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. -However, the scale and frequency of change during a cloud migration doesn't fit well with the nature of ITIL processes. 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. As such, it could be difficult for the team to provide the types of data needed to pass a CAB approval. +However, the scale and frequency of change during a cloud migration doesn't fit well with the nature of ITIL processes. 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. As such, it could be difficult for the team to provide the types of data needed to pass a CAB approval. 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. For organizations that are migrating a few hundred VMs or a few dozen workloads, either approach can be properly managed. 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 require diverse skillsets and a significant variety of changes, and these tasks create dependencies on human efforts at scale. Each of these dependencies injects risk into the migration effort. +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. For organizations that are migrating a few hundred VMs or a few dozen workloads, either approach can be properly managed. 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 require diverse skillsets and a significant variety of changes, and these tasks create dependencies on human efforts at scale. Each of these dependencies injects risk into the migration effort. The article on [digital estate rationalization](../../../digital-estate/rationalize.md) discusses the agility and time-saving impact of basic assumptions when rationalizing a digital estate. There is an additional benefit of standardized change. 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. +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. +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](../migrate/index.md). +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](../migrate/index.md). > [!div class="nextstepaction"] > [Migrate workloads](../migrate/index.md) diff --git a/docs/cloud-adoption/migrate/migration-considerations/assess/business-priorities.md b/docs/cloud-adoption/migrate/migration-considerations/assess/business-priorities.md index 991b25ddf76..4bfb99597ba 100644 --- a/docs/cloud-adoption/migrate/migration-considerations/assess/business-priorities.md +++ b/docs/cloud-adoption/migrate/migration-considerations/assess/business-priorities.md @@ -24,29 +24,29 @@ The ability to execute processes and technical transitions requires a consistent ## How can business and technical priorities stay aligned during a migration? -The Cloud Adoption team and the Cloud Governance team focus on the execution of the current iteration and current release. Iterations provide stable increments of technical work, thus avoiding costly disruptions that would otherwise slow the progress of migration efforts. Releases ensure that the technical effort and energy stay focused on the business objectives of the workload migration. A migration project could require many releases over an extended period. By the time it is completed, market conditions have likely changed significantly. +The cloud adoption team and the cloud governance team focus on the execution of the current iteration and current release. Iterations provide stable increments of technical work, thus avoiding costly disruptions that would otherwise slow the progress of migration efforts. Releases ensure that the technical effort and energy stay focused on the business objectives of the workload migration. A migration project could require many releases over an extended period. By the time it is completed, market conditions have likely changed significantly. -In parallel, the Cloud Strategy team focuses on executing the business change plan and preparing for the next release. The Cloud Strategy team generally looks at least one release ahead, and it monitors for changing market conditions and adjusts the migration backlog accordingly. This focus of managing transformation and adjusting the plan creates natural pivots around the technical work. When business priorities change, adoption is only one release behind, creating technical and business agility. +In parallel, the cloud strategy team focuses on executing the business change plan and preparing for the next release. The cloud strategy team generally looks at least one release ahead, and it monitors for changing market conditions and adjusts the migration backlog accordingly. This focus of managing transformation and adjusting the plan creates natural pivots around the technical work. When business priorities change, adoption is only one release behind, creating technical and business agility. ## Business alignment questions -The following questions can help the Cloud Strategy team shape and prioritize the migration backlog to help ensure that the transformation effort best aligns with current business needs. +The following questions can help the cloud strategy team shape and prioritize the migration backlog to help ensure that the transformation effort best aligns with current business needs. -- Has the Cloud Adoption team identified a list of workloads ready for migration? -- Has the Cloud Adoption team selected a single candidate for an initial migration from that list of workloads? -- Do the Cloud Adoption team and Cloud Governance team have all of the necessary data regarding the workload and cloud environment to be successful? +- Has the cloud adoption team identified a list of workloads ready for migration? +- Has the cloud adoption team selected a single candidate for an initial migration from that list of workloads? +- Do the cloud adoption team and the cloud governance team have all of the necessary data regarding the workload and cloud environment to be successful? - Does the candidate workload deliver the most relevant impact for the business in the next release? - Are there other workloads that are better candidates for migration? ## Tangible actions -During the execution of the business change plan, the Cloud Strategy team monitors for positive and negative results. When those observations require technical change, the adjustments are added as work items to the release backlog to be prioritized in the next iteration. +During the execution of the business change plan, the cloud strategy team monitors for positive and negative results. When those observations require technical change, the adjustments are added as work items to the release backlog to be prioritized in the next iteration. -When the market changes, the Cloud Strategy team works with the business to understand how to best respond to the changes. When that response requires a change in migration priorities, the migration backlog is adjusted. This moves up workloads that were previously lower in priority. +When the market changes, the cloud strategy team works with the business to understand how to best respond to the changes. When that response requires a change in migration priorities, the migration backlog is adjusted. This moves up workloads that were previously lower in priority. ## Next steps -With properly aligned business priorities, the Cloud Adoption team can confidently begin to [evaluate workloads](./evaluate.md) to develop architecture and migration plans. +With properly aligned business priorities, the cloud adoption team can confidently begin to [evaluate workloads](./evaluate.md) to develop architecture and migration plans. > [!div class="nextstepaction"] > [Evaluate workloads](./evaluate.md) diff --git a/docs/cloud-adoption/migrate/migration-considerations/assess/evaluate.md b/docs/cloud-adoption/migrate/migration-considerations/assess/evaluate.md index 44e1d1dfcd3..2562ff1657c 100644 --- a/docs/cloud-adoption/migrate/migration-considerations/assess/evaluate.md +++ b/docs/cloud-adoption/migrate/migration-considerations/assess/evaluate.md @@ -12,7 +12,7 @@ ms.subservice: migrate # Evaluate workload readiness -This activity focuses on evaluating readiness of a workload to migrate to the cloud. During this activity, the Cloud Adoption team validates that all assets and associated dependencies are compatible with the chosen deployment model and cloud provider. During the process, the team documents any efforts required to [remediate](../migrate/remediate.md) compatibility issues. +This activity focuses on evaluating readiness of a workload to migrate to the cloud. During this activity, the cloud adoption team validates that all assets and associated dependencies are compatible with the chosen deployment model and cloud provider. During the process, the team documents any efforts required to [remediate](../migrate/remediate.md) compatibility issues. ## Evaluation assumptions diff --git a/docs/cloud-adoption/migrate/migration-considerations/assess/index.md b/docs/cloud-adoption/migrate/migration-considerations/assess/index.md index 5271b8c5098..058a98fcedc 100644 --- a/docs/cloud-adoption/migrate/migration-considerations/assess/index.md +++ b/docs/cloud-adoption/migrate/migration-considerations/assess/index.md @@ -12,11 +12,11 @@ ms.subservice: migrate # Assess assets prior to migration -Many of your existing workloads are ideal candidates for cloud migration, but not every asset is compatible with cloud platforms and not all workloads can benefit from hosting in the cloud. [Digital estate planning](../../../digital-estate/index.md) allows you to generate an overall [migration backlog](../prerequisites/technical-complexity.md#migration-backlog-aligning-business-priorities-and-timing) of potential workloads to migrate. However, this planning effort is high-level. It relies on assumptions made by the Cloud Strategy team and does not dig deeply into technical considerations. +Many of your existing workloads are ideal candidates for cloud migration, but not every asset is compatible with cloud platforms and not all workloads can benefit from hosting in the cloud. [Digital estate planning](../../../digital-estate/index.md) allows you to generate an overall [migration backlog](../prerequisites/technical-complexity.md#migration-backlog-aligning-business-priorities-and-timing) of potential workloads to migrate. However, this planning effort is high-level. It relies on assumptions made by the cloud strategy team and does not dig deeply into technical considerations. -As a result, before migrating a workload to the cloud it's critical to assess the individual assets associated with that workload for their migration suitability. During this assessment, your Cloud Adoption team should evaluate technical compatibility, required architecture, performance/sizing expectations, and dependencies to ensure that the migrated workload can be deployed to the cloud effectively. +As a result, before migrating a workload to the cloud it's critical to assess the individual assets associated with that workload for their migration suitability. During this assessment, your cloud adoption team should evaluate technical compatibility, required architecture, performance/sizing expectations, and dependencies to ensure that the migrated workload can be deployed to the cloud effectively. -The *Assess* process is the first of four incremental activities that occur within an iteration. As discussed in the prerequisite article regarding [technical complexity and change management](../prerequisites/technical-complexity.md), a decision should be made in advance to determine how this phase is executed. In particular, will assessments be completed by the Cloud Adoption team during the same sprint as the actual migration effort? Alternatively, will a wave or factory model be used to complete assessments in a separate iteration? If the answer to this basic process question can't be answered by every member of the team, it may be wise to revisit the [Prerequisites](../prerequisites/index.md)" section. +The *Assess* process is the first of four incremental activities that occur within an iteration. As discussed in the prerequisite article regarding [technical complexity and change management](../prerequisites/technical-complexity.md), a decision should be made in advance to determine how this phase is executed. In particular, will assessments be completed by the cloud adoption team during the same sprint as the actual migration effort? Alternatively, will a wave or factory model be used to complete assessments in a separate iteration? If the answer to this basic process question can't be answered by every member of the team, it may be wise to revisit the [Prerequisites](../prerequisites/index.md)" section. ## Objective @@ -27,31 +27,31 @@ Assess a migration candidate, evaluating the workload, associated assets, and de This process is complete when the following are known about a single migration candidate: - The path from on-premises to cloud, including production promotion approach decision, has been defined. -- Any required approvals, changes, cost estimates, or validation processes have been completed to allow the Cloud Adoption team to execute the migration. +- Any required approvals, changes, cost estimates, or validation processes have been completed to allow the cloud adoption team to execute the migration. ## Accountability during assessment -The Cloud Adoption team is accountable for the entire assessment process. However, members of the Cloud Strategy team has a few responsibilities, as listed in the following section. +The cloud adoption team is accountable for the entire assessment process. However, members of the cloud strategy team has a few responsibilities, as listed in the following section. ## Responsibilities during assessment In addition to the high-level accountability, there are actions that an individual or group needs to be directly responsible for. The following are a few activities that require assignments to responsible parties: - **Business priority.** The team understands the purpose for migrating this workload, including any intended impact to the business. - - A member of the Cloud Strategy team should carry final responsibility for this activity, under the direction of the Cloud Adoption team. + - A member of the cloud strategy team should carry final responsibility for this activity, under the direction of the cloud adoption team. - **Stakeholder alignment.** The team aligns expectations and priorities with internal stakeholders, identifying success criteria for the migration. What does success look like post-migration? - **Cost.** The cost of the target architecture has been estimated, and the overall budget has been adjusted. - **Migration support.** The team has decided how the technical work of the migration will be completed, including decisions regarding partner or Microsoft support. - **Evaluation.** The workload is evaluated for compatibility and dependencies. - This activity should be assigned to a subject matter expert who is familiar with the architecture and operations of the candidate workload. - **Architect.** The team has agreed on the final state architecture for the migrated workload. -- **Backlog alignment.** The Cloud Adoption team reviews requirements and commits to the migration of the candidate workload. After commitment, the release backlog and iteration backlog are to be updated accordingly. +- **Backlog alignment.** The cloud adoption team reviews requirements and commits to the migration of the candidate workload. After commitment, the release backlog and iteration backlog are to be updated accordingly. - **Work breakdown structure or work-back schedule.** The team establishes a schedule of major milestones identifying goals for when planning, implementation, and review processes are completed. - **Final approval.** Any necessary approvers have reviewed the plan and have signed off on the approach to migrate the asset. - To avoid surprises later in the process, at least one representative of the business should be involved in the approval process. > [!CAUTION] -> This full list of responsibilities and actions can support large and complex migrations involving multiple roles with varying levels of responsibility, and requiring a detailed approval process. Smaller and simpler migration efforts may not require all of roles and actions described here. To determine which of these activities add value and which are unnecessary overhead, your Cloud Adoption team and the Cloud Strategy team are advised to use this full process as part of your first workload migration. After the workload has been verified and tested, the team can evaluate this process and choose which actions to use moving forward. +> This full list of responsibilities and actions can support large and complex migrations involving multiple roles with varying levels of responsibility, and requiring a detailed approval process. Smaller and simpler migration efforts may not require all of roles and actions described here. To determine which of these activities add value and which are unnecessary overhead, your cloud adoption team and the cloud strategy team are advised to use this full process as part of your first workload migration. After the workload has been verified and tested, the team can evaluate this process and choose which actions to use moving forward. ## Next steps diff --git a/docs/cloud-adoption/migrate/migration-considerations/assess/partnership-options.md b/docs/cloud-adoption/migrate/migration-considerations/assess/partnership-options.md index b882f2bdb8a..2f1f9da3454 100644 --- a/docs/cloud-adoption/migrate/migration-considerations/assess/partnership-options.md +++ b/docs/cloud-adoption/migrate/migration-considerations/assess/partnership-options.md @@ -12,7 +12,7 @@ ms.subservice: migrate # Understand partnership options -During migration, the Cloud Adoption team performs the actual migration of workloads to the cloud. Unlike the collaborative and problem-solving tasks when defining the [digital estate](../../../digital-estate/index.md) or building the core cloud infrastructure, migration tends to be a series of repetitive execution tasks. Beyond the repetitive aspects, there are likely testing and tuning efforts that require deep knowledge of the chosen cloud provider. The repetitive nature of this process can sometimes be best addressed by a partner, reducing strain on full-time staff. Additionally, partners may be able to better align deep technical expertise when the repetitive processes encounter execution anomalies. +During migration, the cloud adoption team performs the actual migration of workloads to the cloud. Unlike the collaborative and problem-solving tasks when defining the [digital estate](../../../digital-estate/index.md) or building the core cloud infrastructure, migration tends to be a series of repetitive execution tasks. Beyond the repetitive aspects, there are likely testing and tuning efforts that require deep knowledge of the chosen cloud provider. The repetitive nature of this process can sometimes be best addressed by a partner, reducing strain on full-time staff. Additionally, partners may be able to better align deep technical expertise when the repetitive processes encounter execution anomalies. Partners tend to be closely aligned with a single cloud vendor or a small number of cloud vendors. To better illustrate partnership options, the remainder of this article assumes that Microsoft Azure is the chosen cloud provider. diff --git a/docs/cloud-adoption/migrate/migration-considerations/assess/release-iteration-backlog.md b/docs/cloud-adoption/migrate/migration-considerations/assess/release-iteration-backlog.md index ff302458b84..cc85076104d 100644 --- a/docs/cloud-adoption/migrate/migration-considerations/assess/release-iteration-backlog.md +++ b/docs/cloud-adoption/migrate/migration-considerations/assess/release-iteration-backlog.md @@ -16,21 +16,21 @@ This article assumes that migration processes are incremental in nature, running ## Release backlog -A *release backlog* consists of a series of assets (VMs, databases, files, and applications, among others) that must be migrated before a workload can be released for production usage in the cloud. During each iteration, the Cloud Adoption team documents and estimates the efforts required to move each asset to the cloud. See the "Iteration backlog" section that follows. +A *release backlog* consists of a series of assets (VMs, databases, files, and applications, among others) that must be migrated before a workload can be released for production usage in the cloud. During each iteration, the cloud adoption team documents and estimates the efforts required to move each asset to the cloud. See the "Iteration backlog" section that follows. ## Iteration backlog An *iteration backlog* is a list of the detailed work required to migrate a specific number of assets from the existing digital estate to the cloud. The entries on this list are often stored in an agile management tool, like Azure DevOps, as work items. -Prior to starting the first iteration, the Cloud Adoption team specifies an iteration duration, usually two to four weeks. This time box is important to create a start and finish time period for each set of committed activities. Maintaining consistent execution windows makes it easy to gauge velocity (pace of migration) and alignment to evolving business needs. +Prior to starting the first iteration, the cloud adoption team specifies an iteration duration, usually two to four weeks. This time box is important to create a start and finish time period for each set of committed activities. Maintaining consistent execution windows makes it easy to gauge velocity (pace of migration) and alignment to evolving business needs. -Prior to each iteration, the team reviews the release backlog, estimating the effort and priorities of assets to be migrated. It then commits to deliver a specific number of agreed-on migrations. After this is agreed to by the Cloud Adoption team, the list of activities becomes the *current iteration backlog*. +Prior to each iteration, the team reviews the release backlog, estimating the effort and priorities of assets to be migrated. It then commits to deliver a specific number of agreed-on migrations. After this is agreed to by the cloud adoption team, the list of activities becomes the *current iteration backlog*. During each iteration, team members work as a self-organizing team to fulfill commitments in the current iteration backlog. ## Next steps -After an iteration backlog is defined and accepted by the Cloud Adoption team, [change management approvals](./approve.md) can be finalized. +After an iteration backlog is defined and accepted by the cloud adoption team, [change management approvals](./approve.md) can be finalized. > [!div class="nextstepaction"] > [Approve architecture changes prior to migration](./approve.md) diff --git a/docs/cloud-adoption/migrate/migration-considerations/index.md b/docs/cloud-adoption/migrate/migration-considerations/index.md index c9228f692c6..6a1d8d97365 100644 --- a/docs/cloud-adoption/migrate/migration-considerations/index.md +++ b/docs/cloud-adoption/migrate/migration-considerations/index.md @@ -21,7 +21,7 @@ Cloud migration is a portfolio management effort, cleverly disguised as a techni The Cloud Adoption Framework migration model depends on your organization having completed a process of business readiness for cloud adoption. Make sure you have reviewed [Plan](../../business-strategy/index.md) and [Ready](../../ready/index.md) guidance in the Cloud Adoption Framework to determine the business drivers or other justification for a cloud migration, as well as any required organizational planning or training required before executing a migration process at scale. > [!NOTE] -> While business planning is important, a growth mindset is equally important. In parallel to broader business planning efforts by the Cloud Strategy team, it's suggested that the Cloud Adoption team begin migrating a first workload as a precursor to wider scale migration efforts. This initial migration will allow the team to gain practical experience with the business and technical issues involved in a migration. +> While business planning is important, a growth mindset is equally important. In parallel to broader business planning efforts by the cloud strategy team, it's suggested that the cloud adoption team begin migrating a first workload as a precursor to wider scale migration efforts. This initial migration will allow the team to gain practical experience with the business and technical issues involved in a migration. ## Establishing an end state diff --git a/docs/cloud-adoption/migrate/migration-considerations/migrate/index.md b/docs/cloud-adoption/migrate/migration-considerations/migrate/index.md index db0ec5ed9f7..2db1dee0355 100644 --- a/docs/cloud-adoption/migrate/migration-considerations/migrate/index.md +++ b/docs/cloud-adoption/migrate/migration-considerations/migrate/index.md @@ -26,14 +26,14 @@ This definition of *done* can vary, depending on your testing and release proces ## Accountability during migration -The Cloud Adoption team is accountable for the entire migration process. However, members of the Cloud Strategy team have a few responsibilities, as discussed in the following section. +The cloud adoption team is accountable for the entire migration process. However, members of the cloud strategy team have a few responsibilities, as discussed in the following section. ## Responsibilities during migration In addition to the high-level accountability, there are actions that an individual or group needs to be directly responsible for. The following are a few activities that require assignments to responsible parties: - **Remediation.** Resolve any compatibility issues that prevent the workload from being migrated to the cloud. - - As discussed in the prerequisite article regarding [technical complexity and change management](../prerequisites/technical-complexity.md), a decision should be made in advance to determine how this activity is to be executed. In particular, will remediation be completed by the Cloud Adoption team during the same sprint as the actual migration effort? Alternatively, will a wave or factory model be used to complete remediation in a separate iteration? If the answer to this basic process question can't be answered by every member of the team, it may be wise to revisit the section on [prerequisites](../prerequisites/index.md). + - As discussed in the prerequisite article regarding [technical complexity and change management](../prerequisites/technical-complexity.md), a decision should be made in advance to determine how this activity is to be executed. In particular, will remediation be completed by the cloud adoption team during the same sprint as the actual migration effort? Alternatively, will a wave or factory model be used to complete remediation in a separate iteration? If the answer to this basic process question can't be answered by every member of the team, it may be wise to revisit the section on [prerequisites](../prerequisites/index.md). - **Replication.** Create a copy of each asset in the cloud to synchronize VMs, data, and applications with resources in the cloud. - Depending on the promotion model, different tools may be required to complete this activity. - **Staging.** After all assets for a workload have been replicated and verified, the workload can be staged for business testing and execution of a business change plan. diff --git a/docs/cloud-adoption/migrate/migration-considerations/migrate/promotion-models.md b/docs/cloud-adoption/migrate/migration-considerations/migrate/promotion-models.md index db917c77277..aca52d4bfb2 100644 --- a/docs/cloud-adoption/migrate/migration-considerations/migrate/promotion-models.md +++ b/docs/cloud-adoption/migrate/migration-considerations/migrate/promotion-models.md @@ -26,7 +26,7 @@ In each of the following promotion models, the chosen migration tool replicates - **Staged.** In a *staged* promotion model, the workload is considered migrated after it is staged, but it is not yet promoted. Prior to promotion, the migrated workload undergoes a series of performance tests, business tests, and optimization changes. It is then promoted at a future date in conjunction with a business test plan. This approach improves the balance between cost and performance, while making it easier to obtain business validation. - **Flight.** The *flight* promotion model combines single-step and staged models. In a flight model, the assets in the workload are treated like production after landing in staging. After a condensed period of automated testing, production traffic is routed to the workload. However, it is a subset of the traffic. That traffic serves as the first flight of production and testing. Assuming the workload performs from a feature and performance perspective, additional traffic is migrated. After all production traffic has been moved onto the new assets, the workload is considered fully promoted. -The chosen promotion model affects the sequence of activities to be performed. It also affects the roles and responsibilities of the Cloud Adoption team. It may even impact the composition of a sprint or multiple sprints. +The chosen promotion model affects the sequence of activities to be performed. It also affects the roles and responsibilities of the cloud adoption team. It may even impact the composition of a sprint or multiple sprints. ## Single-step promotion @@ -46,7 +46,7 @@ This model uses migration automation tools to replicate, stage, and promote asse ## Staged promotion -In this model, the staging sandbox managed by the migration tool is used for limited testing purposes. The replicated assets are then deployed into the cloud environment, which serves as an extended staging environment. The migrated assets run in the cloud, while additional assets are replicated, staged, and migrated. When full workloads become available, richer testing is initiated. When all assets associated with a subscription have been migrated, the subscription and all hosted workloads are promoted to production. In this scenario, there is no change to the workloads during the promotion process. Instead, the changes tend to be at the network and identity layers, routing users to the new environment and revoking access of the Cloud Adoption team. +In this model, the staging sandbox managed by the migration tool is used for limited testing purposes. The replicated assets are then deployed into the cloud environment, which serves as an extended staging environment. The migrated assets run in the cloud, while additional assets are replicated, staged, and migrated. When full workloads become available, richer testing is initiated. When all assets associated with a subscription have been migrated, the subscription and all hosted workloads are promoted to production. In this scenario, there is no change to the workloads during the promotion process. Instead, the changes tend to be at the network and identity layers, routing users to the new environment and revoking access of the cloud adoption team. **Pros.** Positive benefits of this approach include: @@ -76,7 +76,7 @@ This model is similar to the staged promotion model. However, there is one funda ## Next steps -After a promotion model is defined and accepted by the Cloud Adoption team, [remediation of assets](./remediate.md) can begin. +After a promotion model is defined and accepted by the cloud adoption team, [remediation of assets](./remediate.md) can begin. > [!div class="nextstepaction"] > [Remediating assets prior to migration](./remediate.md) diff --git a/docs/cloud-adoption/migrate/migration-considerations/optimize/business-change-plan.md b/docs/cloud-adoption/migrate/migration-considerations/optimize/business-change-plan.md index c1f099b570d..8c6db585e2c 100644 --- a/docs/cloud-adoption/migrate/migration-considerations/optimize/business-change-plan.md +++ b/docs/cloud-adoption/migrate/migration-considerations/optimize/business-change-plan.md @@ -41,7 +41,7 @@ A business change plan looks beyond the technical change and assumes that every - Does the business change plan maximize impact but minimize business disruption? - Is downtime expected? Has a downtime window been communicated to end users? -**Downstream questions.** After the adoption is complete, the business change can begin. Unfortunately, this is where many user adoption plans end. Downstream questions help the Cloud Strategy team maintain a focus on transformation after technical change is completed: +**Downstream questions.** After the adoption is complete, the business change can begin. Unfortunately, this is where many user adoption plans end. Downstream questions help the cloud strategy team maintain a focus on transformation after technical change is completed: - Are business users responding well to the changes? - Has performance anticipation been maintained, now that the technical change has been adopted? diff --git a/docs/cloud-adoption/migrate/migration-considerations/optimize/decommission.md b/docs/cloud-adoption/migrate/migration-considerations/optimize/decommission.md index 0f10de51c1c..316d910ced5 100644 --- a/docs/cloud-adoption/migrate/migration-considerations/optimize/decommission.md +++ b/docs/cloud-adoption/migrate/migration-considerations/optimize/decommission.md @@ -32,7 +32,7 @@ It's not uncommon for migrations to miss data during replication processes. This ## Next steps -After retired assets are decommissioned, the migration is completed. This creates a good opportunity to improve the migration process, and a [retrospective](./retrospective.md) engages the Cloud Adoption team in a review of the release in an effort to learn and improve. +After retired assets are decommissioned, the migration is completed. This creates a good opportunity to improve the migration process, and a [retrospective](./retrospective.md) engages the cloud adoption team in a review of the release in an effort to learn and improve. > [!div class="nextstepaction"] > [Retrospective](./retrospective.md) diff --git a/docs/cloud-adoption/migrate/migration-considerations/optimize/index.md b/docs/cloud-adoption/migrate/migration-considerations/optimize/index.md index b75507c6ed1..2e60838f6b4 100644 --- a/docs/cloud-adoption/migrate/migration-considerations/optimize/index.md +++ b/docs/cloud-adoption/migrate/migration-considerations/optimize/index.md @@ -22,7 +22,7 @@ The optimization process is complete when a workload has been properly configure ## Accountability during optimization -The Cloud Adoption team is accountable for the entire optimization process. However, members of the Cloud Strategy team, Cloud Operations team, and Cloud Governance team should also be responsible for activities within this process. +The cloud adoption team is accountable for the entire optimization process. However, members of the cloud strategy team, the cloud operations team, and the cloud governance team should also be responsible for activities within this process. ## Responsibilities during optimization @@ -31,14 +31,14 @@ In addition to the high-level accountability, there are actions that an individu - **Business testing.** Resolve any compatibility issues that prevent the workload from completing its migration to the cloud. - Power users from within the business should participate heavily in testing of the migrated workload. Depending on the degree of optimization attempted, multiple testing cycles may be required. - **Business change plan.** Development of a plan for user adoption, changes to business processes, and modification to business KPIs or learning metrics as a result of the migration effort. -- **Benchmark and optimize.** Study of the business testing and automated testing to benchmark performance. Based on usage, the Cloud Adoption team refines sizing of the deployed assets to balance cost and performance against expected production requirements. +- **Benchmark and optimize.** Study of the business testing and automated testing to benchmark performance. Based on usage, the cloud adoption team refines sizing of the deployed assets to balance cost and performance against expected production requirements. - **Ready for production.** Prepare the workload and environment for the support of the workload's ongoing production usage. - **Promote.** Redirect production traffic to the migrated and optimized workload. This activity represents the completion of a release cycle. In addition to core activities, there are a few parallel activities that require specific assignments and execution plans: - **Decommission.** Generally, cost savings can be realized from a migration, when the previous production assets are decommissioned and properly disposed of. -- **Retrospective.** Every release creates an opportunity for deeper learning and adoption of a growth mindset. When each release cycle is completed, the Cloud Adoption team should evaluate the processes used during migration to identify improvements. +- **Retrospective.** Every release creates an opportunity for deeper learning and adoption of a growth mindset. When each release cycle is completed, the cloud adoption team should evaluate the processes used during migration to identify improvements. ## Next steps diff --git a/docs/cloud-adoption/migrate/migration-considerations/optimize/optimize.md b/docs/cloud-adoption/migrate/migration-considerations/optimize/optimize.md index 3a9c60a4362..a8a0230b27a 100644 --- a/docs/cloud-adoption/migrate/migration-considerations/optimize/optimize.md +++ b/docs/cloud-adoption/migrate/migration-considerations/optimize/optimize.md @@ -16,7 +16,7 @@ Monitoring usage and spending is critically important for cloud infrastructures. In the traditional on-premises models of IT, requisition of IT systems is costly and time consuming. The processes often require lengthy capital expenditure review cycles and may even require an annual planning process. As such, it is common practice to buy more than is needed. It is equally common for IT administrators to then overprovision assets in preparation for anticipated future demands. -In the cloud, the accounting and provisioning models eliminate the time delays that lead to overbuying. When an asset needs additional resources, it can be scaled up or out almost instantly. This means that assets can safely be reduced in size to minimize resources and costs consumed. During benchmarking and optimization, the Cloud Adoption team seeks to find the balance between performance and costs, provisioning assets to be no larger and no smaller than necessary to meet production demands. +In the cloud, the accounting and provisioning models eliminate the time delays that lead to overbuying. When an asset needs additional resources, it can be scaled up or out almost instantly. This means that assets can safely be reduced in size to minimize resources and costs consumed. During benchmarking and optimization, the cloud adoption team seeks to find the balance between performance and costs, provisioning assets to be no larger and no smaller than necessary to meet production demands. diff --git a/docs/cloud-adoption/migrate/migration-considerations/prerequisites/culture-complexity.md b/docs/cloud-adoption/migrate/migration-considerations/prerequisites/culture-complexity.md index cf1108205c1..5201cda2c40 100644 --- a/docs/cloud-adoption/migrate/migration-considerations/prerequisites/culture-complexity.md +++ b/docs/cloud-adoption/migrate/migration-considerations/prerequisites/culture-complexity.md @@ -25,14 +25,14 @@ In any migration, there are a few key functions that are best executed by the bu | Assess | Business goals | Define the desired business outcomes of the migration effort. | | Assess | Priorities | Ensure alignment with changing business priorities and market conditions. | | Assess | Justification | Validate assumptions that drive evolving business justifications. | -| Assess | Risk | Help the Cloud Adoption team understand the impact of tangible business risks. | +| Assess | Risk | Help the cloud adoption team understand the impact of tangible business risks. | | Assess | Approve | Review and approve the business impact of proposed architecture changes. | | Optimize | Change plan | Define a plan for consumption of change within the business, including periods of low activities and change freezes. | | Optimize | Testing | Align power users capable of validating performance and functionality. | -| Secure and manage | Interruption impact | Aid the Cloud Adoption team in quantifying the impact of a business process interruption. | -| Secure and manage | Service-level agreement (SLA) validation | Aid the Cloud Adoption team in defining service level agreements and acceptable tolerances for business outages. | +| Secure and manage | Interruption impact | Aid the cloud adoption team in quantifying the impact of a business process interruption. | +| Secure and manage | Service-level agreement (SLA) validation | Aid the cloud adoption team in defining service level agreements and acceptable tolerances for business outages. | -Ultimately, the Cloud Adoption team is accountable for each of these activities. However, establishing responsibilities and a regular cadence with the business for the completion of these activities on an established rhythm can improve stakeholder alignment and cohesiveness with the business. +Ultimately, the cloud adoption team is accountable for each of these activities. However, establishing responsibilities and a regular cadence with the business for the completion of these activities on an established rhythm can improve stakeholder alignment and cohesiveness with the business. ## Common roles and responsibilities @@ -43,21 +43,21 @@ Each process within the discussion of the Cloud Adoption Framework migration pri | Process | Activity | Description | Accountable party | |---------|---------|---------|---------| -| Prerequisite | Digital estate | Align the existing inventory to basic assumptions, based on business outcomes. | Cloud Strategy team | -| Prerequisite | Migration backlog | Prioritize the sequence of workloads to be migrated. | Cloud Strategy team | -| Assess | Architecture | Challenge initial assumptions to define the target architecture based on usage metrics. | Cloud Adoption team | -| Assess | Approval | Approve the proposed architecture. | Cloud Strategy team | -| Migrate | Replication access | Access to existing on-premises hosts and assets to establish replication processes. | Cloud Adoption team | -| Optimize | Ready | Validate that the system meets performance and cost requirements prior to promotion. | Cloud Adoption team | -| Optimize | Promote | Permissions to promote a workload to production and redirect production traffic. | Cloud Adoption team | -| Secure and manage | Ops transition | Document production systems prior to production operations. | Cloud Adoption team | +| Prerequisite | Digital estate | Align the existing inventory to basic assumptions, based on business outcomes. | cloud strategy team | +| Prerequisite | Migration backlog | Prioritize the sequence of workloads to be migrated. | cloud strategy team | +| Assess | Architecture | Challenge initial assumptions to define the target architecture based on usage metrics. | cloud adoption team | +| Assess | Approval | Approve the proposed architecture. | cloud strategy team | +| Migrate | Replication access | Access to existing on-premises hosts and assets to establish replication processes. | cloud adoption team | +| Optimize | Ready | Validate that the system meets performance and cost requirements prior to promotion. | cloud adoption team | +| Optimize | Promote | Permissions to promote a workload to production and redirect production traffic. | cloud adoption team | +| Secure and manage | Ops transition | Document production systems prior to production operations. | cloud adoption team | > [!CAUTION] > For these activities, permissions and authorization heavily influence the accountable party, who must have direct access to production systems in the existing environment or must have means of securing access through other responsible actors. Determining this accountable party directly affects the promotion strategy during the migrate and optimize processes. ## Next steps -When the team has a general understanding of roles and responsibilities, it’s time to begin preparing the technical details of the migration. Understanding [technical complexity and change management](./technical-complexity.md) can help prepare the Cloud Adoption team for the technical complexity of migration by aligning to an incremental change management process. +When the team has a general understanding of roles and responsibilities, it’s time to begin preparing the technical details of the migration. Understanding [technical complexity and change management](./technical-complexity.md) can help prepare the cloud adoption team for the technical complexity of migration by aligning to an incremental change management process. > [!div class="nextstepaction"] > [Technical complexity and change management](./technical-complexity.md) diff --git a/docs/cloud-adoption/migrate/migration-considerations/prerequisites/decisions.md b/docs/cloud-adoption/migrate/migration-considerations/prerequisites/decisions.md index 3c9c0a85d39..a009bc777f1 100644 --- a/docs/cloud-adoption/migrate/migration-considerations/prerequisites/decisions.md +++ b/docs/cloud-adoption/migrate/migration-considerations/prerequisites/decisions.md @@ -24,7 +24,7 @@ The objective or goal of any adoption effort can have a significant impact on th No business would pursue just one of these outcomes. Without operations, there are no customers, and vice versa. Cloud adoption is no different. Companies commonly work to achieve each of these outcomes, but trying to focus on all of them simultaneously can spread your efforts too thin and slow progress on work that could most benefit your business needs. -This prerequisite isn't a demand for you to pick one of these three goals, but instead to help your Cloud Strategy team and Cloud Adoption team establish a set of operational priorities that will guide execution for the next three to six months. These priorities are set by ranking each of the three itemized options from *most significant* to *least significant*, as they relate to the efforts this team can contribute to in the next one or two quarters. +This prerequisite isn't a demand for you to pick one of these three goals, but instead to help your cloud strategy team and your cloud adoption team establish a set of operational priorities that will guide execution for the next three to six months. These priorities are set by ranking each of the three itemized options from *most significant* to *least significant*, as they relate to the efforts this team can contribute to in the next one or two quarters. ### Acting on migration outcomes @@ -72,7 +72,7 @@ Often, migrations are driven by a compelling business event that is time sensiti ## Recap -Before proceeding, document the following assumptions and share them with the Cloud Strategy and Cloud Adoption teams: +Before proceeding, document the following assumptions and share them with the cloud strategy team and the cloud adoption teams: - Business outcomes. - Roles. This will be documented and refined for the *Assess*, *Migrate*, *Optimize*, and *Secure and Manage* migration processes. diff --git a/docs/cloud-adoption/migrate/migration-considerations/prerequisites/index.md b/docs/cloud-adoption/migrate/migration-considerations/prerequisites/index.md index de7cf1998c7..c284b37b6f3 100644 --- a/docs/cloud-adoption/migrate/migration-considerations/prerequisites/index.md +++ b/docs/cloud-adoption/migrate/migration-considerations/prerequisites/index.md @@ -29,8 +29,8 @@ Before beginning any cloud migration, review the [Plan](../../../business-strate Prerequisites are completed when the following are true: -- **Business readiness.** The Cloud Strategy team has defined and prioritized a high-level migration backlog representing the portion of the digital estate to be migrated in the next two or three releases. The Cloud Strategy team and Cloud Adoption team have agreed to an initial strategy for managing change. -- **Culture readiness.** The roles, responsibilities, and expectations of the Cloud Adoption team, Cloud Strategy team, and affected users have been agreed on regarding the workloads to be migrated in the next two or three releases. +- **Business readiness.** The cloud strategy team has defined and prioritized a high-level migration backlog representing the portion of the digital estate to be migrated in the next two or three releases. The cloud strategy team and the cloud adoption team have agreed to an initial strategy for managing change. +- **Culture readiness.** The roles, responsibilities, and expectations of the cloud adoption team, cloud strategy team, and affected users have been agreed on regarding the workloads to be migrated in the next two or three releases. - **Technical readiness.** The landing zone (or allocated hosting space in the cloud) that will receive the migrated assets meets minimum requirements to host the first migrated workload. > [!CAUTION] @@ -42,8 +42,8 @@ Prerequisites are completed when the following are true: Two teams are accountable for readiness during the prerequisites phase: -- **Cloud Strategy team.** This team is responsible for identifying and prioritizing the first two or three workloads to serve as migration candidates. -- **Cloud Adoption team.** This team is responsible for validating readiness of the technical environment and the feasibility of migrating the proposed workloads. +- **Cloud strategy team:** This team is responsible for identifying and prioritizing the first two or three workloads to serve as migration candidates. +- **Cloud adoption team:** This team is responsible for validating readiness of the technical environment and the feasibility of migrating the proposed workloads. A single member of each team should be identified as accountable for each of the three definitions of done statements in the prior section. diff --git a/docs/cloud-adoption/migrate/migration-considerations/prerequisites/migration-backlog-review.md b/docs/cloud-adoption/migrate/migration-considerations/prerequisites/migration-backlog-review.md index 0b8fa9d20f1..67ddcea49c9 100644 --- a/docs/cloud-adoption/migrate/migration-considerations/prerequisites/migration-backlog-review.md +++ b/docs/cloud-adoption/migrate/migration-considerations/prerequisites/migration-backlog-review.md @@ -12,7 +12,7 @@ ms.subservice: migrate # Migration Backlog Review -The actionable output of the plan phase is a migration backlog, which influences all of the prerequisites discussed so far. Development of the migration backlog should be completed as a first prerequisite. This article serves as a milestone to complete prerequisite activities. The Cloud Strategy team is accountable for the care and maintenance of the digital estate. However, the realization of the resultant backlog is the responsibility of every member of the migration effort. As a final prerequisite, the Cloud Strategy team and the Cloud Adoption team should review and understand the migration backlog. During that review, the members of both teams must gain sufficient knowledge to articulate the following key points in the migration backlog. +The actionable output of the plan phase is a migration backlog, which influences all of the prerequisites discussed so far. Development of the migration backlog should be completed as a first prerequisite. This article serves as a milestone to complete prerequisite activities. The cloud strategy team is accountable for the care and maintenance of the digital estate. However, the realization of the resultant backlog is the responsibility of every member of the migration effort. As a final prerequisite, the cloud strategy team and the cloud adoption team should review and understand the migration backlog. During that review, the members of both teams must gain sufficient knowledge to articulate the following key points in the migration backlog. ## Business outcomes and metrics @@ -22,11 +22,11 @@ Tracking migration progress is equally important to the motivation of the team a ## Business priorities -Sometimes, prioritizing one workload over another may seem illogical to the Cloud Adoption team. Understanding the business priorities that drove those decisions can help maintain the team's motivation. It also allows the team to make a stronger contribution to the prioritization process. +Sometimes, prioritizing one workload over another may seem illogical to the cloud adoption team. Understanding the business priorities that drove those decisions can help maintain the team's motivation. It also allows the team to make a stronger contribution to the prioritization process. ## Core assumptions -The article on [digital estate rationalization](../../../digital-estate/rationalize.md) discusses the agility and time-saving impact of basic assumptions when evaluating a digital estate. To fully realize those values, the Cloud Adoption team needs to understand the assumptions and the reasons that they were established. That knowledge better equips the Cloud Adoption team to challenge those assumptions. +The article on [digital estate rationalization](../../../digital-estate/rationalize.md) discusses the agility and time-saving impact of basic assumptions when evaluating a digital estate. To fully realize those values, the cloud adoption team needs to understand the assumptions and the reasons that they were established. That knowledge better equips the cloud adoption team to challenge those assumptions. ## Next steps diff --git a/docs/cloud-adoption/migrate/migration-considerations/prerequisites/planning-checklist.md b/docs/cloud-adoption/migrate/migration-considerations/prerequisites/planning-checklist.md index 76ca3164d0d..71e1440376c 100644 --- a/docs/cloud-adoption/migrate/migration-considerations/prerequisites/planning-checklist.md +++ b/docs/cloud-adoption/migrate/migration-considerations/prerequisites/planning-checklist.md @@ -22,7 +22,7 @@ This article and checklist assume a _rehost_ or _cloud transition_ approach to c ## Governance alignment -The first and most important decision regarding any migration-ready environment is the choice of governance alignment. Has a consensus been achieved regarding alignment of governance with the migration foundation? At minimum, the Cloud Adoption team should understand whether this migration is landing in a single environment with limited governance, a fully governed environment factory, or some variant in between. For more options and guidance on governance alignment, see the article on [Governance and compliance alignment](../../expanded-scope/governance-or-compliance.md). +The first and most important decision regarding any migration-ready environment is the choice of governance alignment. Has a consensus been achieved regarding alignment of governance with the migration foundation? At minimum, the cloud adoption team should understand whether this migration is landing in a single environment with limited governance, a fully governed environment factory, or some variant in between. For more options and guidance on governance alignment, see the article on [Governance and compliance alignment](../../expanded-scope/governance-or-compliance.md). ## Cloud readiness implementation @@ -47,7 +47,7 @@ A consistent approach for naming resources, along with consistent naming schemas ### Resource governance -A decision regarding the tools to govern resources should be made prior to migration. The tools do not need to be fully implemented, but a direction should be selected and tested. It is advised that the Cloud Governance team define and require the implementation of a minimum viable product (MVP) for governance tooling prior to migration. +A decision regarding the tools to govern resources should be made prior to migration. The tools do not need to be fully implemented, but a direction should be selected and tested. It is advised that the cloud governance team define and require the implementation of a minimum viable product (MVP) for governance tooling prior to migration. ## Network diff --git a/docs/cloud-adoption/migrate/migration-considerations/prerequisites/technical-complexity.md b/docs/cloud-adoption/migrate/migration-considerations/prerequisites/technical-complexity.md index a5312df06f8..6721f9a412b 100644 --- a/docs/cloud-adoption/migrate/migration-considerations/prerequisites/technical-complexity.md +++ b/docs/cloud-adoption/migrate/migration-considerations/prerequisites/technical-complexity.md @@ -37,7 +37,7 @@ This acronym is not intended as a basis for rigid adherence but should help guid ## Migration backlog: Aligning business priorities and timing -The migration backlog allows you to track your top-level portfolio of migratable workloads. Prior to migration, the Cloud Strategy team and Cloud Adoption team are encouraged to perform a review of the current [digital estate](../../../digital-estate/index.md), and agree to a prioritized list of workloads to be migrated. This list forms the basis of the initial migration backlog. +The migration backlog allows you to track your top-level portfolio of migratable workloads. Prior to migration, the cloud strategy team and the cloud adoption team are encouraged to perform a review of the current [digital estate](../../../digital-estate/index.md), and agree to a prioritized list of workloads to be migrated. This list forms the basis of the initial migration backlog. Initially, workloads on the migration backlog are unlikely to meet the INVEST criteria outlined in the previous section. Instead, they serve as a logical grouping of assets from an initial inventory as a placeholder for future work. Those placeholders may not be technically accurate, but they serve as the basis for coordination with the business. @@ -60,15 +60,15 @@ In any migration backlog, the change management team should strive to obtain the ## Release backlog: Aligning business change and technical coordination -In the context of a migration, a _release_ is an activity that deploys one or more workloads into production. A release generally covers several iterations or technical work. However, it represents a single iteration of business change. After one or more workloads have been prepared for production promotion, a release occurs. The decision to package a release is made when the workloads migrated represent enough business value to justify injecting change into a business environment. Releases are executed in conjunction with a [business change plan](../optimize/business-change-plan.md), after [business testing](../optimize/business-test.md) has been completed. The Cloud Strategy team is responsible for planning and overseeing the execution of a release to ensure that the desired business change is released. +In the context of a migration, a _release_ is an activity that deploys one or more workloads into production. A release generally covers several iterations or technical work. However, it represents a single iteration of business change. After one or more workloads have been prepared for production promotion, a release occurs. The decision to package a release is made when the workloads migrated represent enough business value to justify injecting change into a business environment. Releases are executed in conjunction with a [business change plan](../optimize/business-change-plan.md), after [business testing](../optimize/business-test.md) has been completed. The cloud strategy team is responsible for planning and overseeing the execution of a release to ensure that the desired business change is released. -A *release backlog* is the future state plan that defines a coming release. Release backlog is the pivot point between business change management (*migration backlog*) and technical change management (*sprint backlog*). A release backlog consists of a list of workloads from the migration backlog that align to a specific subset of business outcome realization. Definition and submission of a release backlog to the Cloud Adoption team serve as a trigger for deeper analysis and migration planning. After the Cloud Adoption team has verified the technical details associated with a release, it can choose to commit to the release, establishing a release timeline based on current knowledge. +A *release backlog* is the future state plan that defines a coming release. Release backlog is the pivot point between business change management (*migration backlog*) and technical change management (*sprint backlog*). A release backlog consists of a list of workloads from the migration backlog that align to a specific subset of business outcome realization. Definition and submission of a release backlog to the cloud adoption team serve as a trigger for deeper analysis and migration planning. After the cloud adoption team has verified the technical details associated with a release, it can choose to commit to the release, establishing a release timeline based on current knowledge. -Given the degree of analysis required to validate a release, the Cloud Strategy team should maintain a running list of the next two to four releases. The team should also attempt to validate as much of the following information as possible, before defining and submitting a release. A disciplined Cloud Strategy team capable of maintaining the next four releases can significantly increase the consistency and accuracy of release timeline estimates. +Given the degree of analysis required to validate a release, the cloud strategy team should maintain a running list of the next two to four releases. The team should also attempt to validate as much of the following information as possible, before defining and submitting a release. A disciplined cloud strategy team capable of maintaining the next four releases can significantly increase the consistency and accuracy of release timeline estimates. ### Release backlog data points -A partnership between the Cloud Strategy team and the Cloud Adoption team collaborates to add the following data points for any workloads in the release backlog: +A partnership between the cloud strategy team and the cloud adoption team collaborates to add the following data points for any workloads in the release backlog: - **Refined inventory.** Validation of required assets to be migrated. Often validated through log or monitoring data at the host, network, or OS level to ensure an accurate understanding of network and hardware dependencies of each asset under standard load. - **Usage patterns.** An understanding of the patterns of usage from end users. These patterns often include an analysis of end-user geographical distribution, network routes, seasonal usage spikes, daily/hourly usage spikes, and end-user composition (interval versus external). @@ -76,14 +76,14 @@ A partnership between the Cloud Strategy team and the Cloud Adoption team collab - **Dependencies.** Analysis of network traffic and application usage patterns to identify any additional workload dependencies, which should be factored into sequencing and environmental readiness. Don't include a workload in a release until one of the following criteria can be met: - All dependent workloads have been migrated. - Network and security configurations have been implemented to allow the workload to access all dependencies in alignment with existing performance expectations. -- **Desired migration approach.** At the migration backlog level, the assumed migration effort is the only consideration used in analysis. For instance, if the business outcome is an exit from an existing datacenter, all migrations are assumed to be a rehost scenario in the migration backlog. In the release backlog, the Cloud Strategy team and Cloud Adoption team should evaluate the long-term value of additional features, modernization, and continued development investments to evaluate whether a more modern approach should be involved. +- **Desired migration approach.** At the migration backlog level, the assumed migration effort is the only consideration used in analysis. For instance, if the business outcome is an exit from an existing datacenter, all migrations are assumed to be a rehost scenario in the migration backlog. In the release backlog, the cloud strategy team and the cloud adoption team should evaluate the long-term value of additional features, modernization, and continued development investments to evaluate whether a more modern approach should be involved. - **Business testing criteria.** After a workload is added to the migration backlog, testing criteria should be mutually agreed on. In some cases, testing criteria can be limited to a performance test with a defined power user group. However, for statistical validation, an automated performance test is desired and should be included. The existing instance of the application often has no automated testing capabilities. Should this prove accurate, it is not uncommon for the cloud architects to work with power users to create a baseline load test against the existing solution to establish a benchmark to be used during migration. ### Release backlog cadence -In mature migrations, releases come in a regular cadence. The velocity of the Cloud Adoption team often normalizes, producing a release every two to four iterations (approximately every one or two months). However, this should be an organic outcome. Creating artificial release cadences can negatively affect the Cloud Adoption team’s ability to achieve consistent throughput. +In mature migrations, releases come in a regular cadence. The velocity of the cloud adoption team often normalizes, producing a release every two to four iterations (approximately every one or two months). However, this should be an organic outcome. Creating artificial release cadences can negatively affect the cloud adoption team’s ability to achieve consistent throughput. -To stabilize business impact, the Cloud Strategy team should establish a monthly release process with the business to maintain regular dialogue but should also establish the expectation that it will be several months before a regular release cadence can be predicted. +To stabilize business impact, the cloud strategy team should establish a monthly release process with the business to maintain regular dialogue but should also establish the expectation that it will be several months before a regular release cadence can be predicted. ## Sprint or iteration backlog: Aligning technical change and effort @@ -91,7 +91,7 @@ A *sprint*, or *iteration*, is a consistent, time-bound unit of work. In the mig A *sprint backlog*, or *iteration backlog*, consists of the technical work to be completed in a single sprint or iteration, dealing with migrating individual assets. That work should be derived from the list of workloads being migrated. When using tools like Azure DevOps (previously Visual Studio Online) for project management, the work items in a sprint would be children of the product backlog Items in a release backlog and the epics in a migration backlog. Such a parent-child relationship allows for clarity at all levels of change management. -Within a single sprint or iteration, the Cloud Adoption team would work to deliver the committed amount of technical work, driving toward the migration of a defined workload. This is the end result of the change management strategy. When complete, these efforts can be tested by validating production readiness of a workload staged in the cloud. +Within a single sprint or iteration, the cloud adoption team would work to deliver the committed amount of technical work, driving toward the migration of a defined workload. This is the end result of the change management strategy. When complete, these efforts can be tested by validating production readiness of a workload staged in the cloud. ### Large or complex sprint structures @@ -112,7 +112,7 @@ The outcome of a sprint captures and documents the changes made to a workload, t - **Performance metrics.** Output of automated testing or business testing performed to validate performance at the time of deployment. - **Unique requirements or configuration.** Any unique aspects of the deployment, configuration, or technical requirements necessary to operate the workload. - **Operational approval.** Sign-off of validating operational readiness from the application owner and the IT operations staff responsible for managing the workload post deployment. -- **Architecture approval.** Sign-off from the workload owner and Cloud Adoption team to validate any architecture changes required to host each asset. +- **Architecture approval.** Sign-off from the workload owner and the cloud adoption team to validate any architecture changes required to host each asset. ## Next steps diff --git a/docs/cloud-adoption/operating-model/index.md b/docs/cloud-adoption/operating-model/index.md index 0f81e0f8f1a..752ac614064 100644 --- a/docs/cloud-adoption/operating-model/index.md +++ b/docs/cloud-adoption/operating-model/index.md @@ -1,7 +1,7 @@ --- title: "Introduction to the operating model" titleSuffix: Microsoft Cloud Adoption Framework for Azure -description: Understand the operating model for the Cloud Adoption Framework. +description: Understand the operating model of the Cloud Adoption Framework. author: BrianBlanchard ms.author: brblanch ms.date: 05/19/2019 @@ -11,23 +11,23 @@ ms.subservice: overview ms.custom: operating-model --- -# Operating model for the cloud +# Establish an operating model for the cloud -Cloud adoption defines what you do or how you use the cloud during transformation projects that realize the desired business value. The operating model is who you are or how you function on a daily basis while cloud adoption is being delivered and long after. +Cloud adoption defines what you do and how you use the cloud during transformation projects that yield desired business value. The operating model is who you are and how you function on a daily basis, during and after cloud adoption. -## Establish an operating model +## Establish your operating model -Current operating models can scale to support your desire to adopt the cloud. A modern operating model can help you solve nontechnical blockers to cloud adoption. +Current operating models can scale to support your adoption of the cloud. A modern operating model will help you remove nontechnical blockers to cloud adoption. -This section of the Cloud Adoption Framework is designed to help you by presenting an actionable operating model to guide nontechnical decisions. This operating model consists of three methodologies that can aid in creation of your own cloud operating model: +This section of the Cloud Adoption Framework provides an actionable operating model to guide nontechnical decisions. This operating model consists of three methodologies to aid in creating your own cloud operating model: - [Govern](../governance/index.md): Ensure consistency across adoption efforts. Align to governance or compliance requirements to maintain a well-managed cross-cloud environment. - [Organize](../organization/index.md): Align the organization to ensure success across the operating model and various cloud adoption efforts. -- [Manage](../operations/index.md): Alignment of ongoing processes for operational management of the technology to maximize value attainment and minimize disruptions. +- [Manage](../operations/index.md): Align ongoing processes for operational management of the technology to maximize value attainment and minimize disruptions. ## Next steps -Governance is often the first step that you take toward an operating model for the cloud. +Governance is a common first step toward establishing an operating model for the cloud. > [!div class="nextstepaction"] -> [Get started with governance](../governance/index.md) +> [Learn about cloud governance](../governance/index.md) diff --git a/docs/cloud-adoption/operations/azure-server-management/prerequisites.md b/docs/cloud-adoption/operations/azure-server-management/prerequisites.md index e5b83fe2169..f499a3b2289 100644 --- a/docs/cloud-adoption/operations/azure-server-management/prerequisites.md +++ b/docs/cloud-adoption/operations/azure-server-management/prerequisites.md @@ -73,7 +73,7 @@ For larger environments that span multiple subscriptions and have a central IT d ### Decentralized placement -In an alternative model for large environments, responsibility for patching and management can lie with the Application team. In this case, you should place the workspace and Automation accounts pairs in the application team subscriptions alongside their other resources. +In an alternative model for large environments, responsibility for patching and management can lie with the application development team. In this case, you should place the workspace and Automation accounts pairs in the application team subscriptions alongside their other resources. ![Workspace account model for decentralized environments](./media/workspace-model-decentralized.png) diff --git a/docs/cloud-adoption/organization/cloud-governance.md b/docs/cloud-adoption/organization/cloud-governance.md index 54550db5631..9f60333a711 100644 --- a/docs/cloud-adoption/organization/cloud-governance.md +++ b/docs/cloud-adoption/organization/cloud-governance.md @@ -82,7 +82,7 @@ Another fundamental difference between a cloud custodian and a governance volunt While the difference is subtle, it is an important distinction when building a governance-focused IT culture. A cloud custodian cleans up the messes made by innovative cloud architects, and the two roles have natural friction and opposing objectives. A cloud guardian helps keep the cloud safe, so other cloud architects can move more quickly with fewer messes. -Cloud guardians begin using more advanced governance approaches to accelerate platform deployment and help teams self-service their environmental needs, so they can move faster. Examples of these more advanced functions are seen in the evolutions of the governance MVP, such as [evolution of the security baseline](../governance/journeys/large-enterprise/security-baseline-evolution.md). +Cloud guardians begin using more advanced governance approaches to accelerate platform deployment and help teams self-service their environmental needs, so they can move faster. Examples of these more advanced functions are seen in the incremental improvements to the governance MVP, such as [improvement of the security baseline](../governance/journeys/large-enterprise/security-baseline-evolution.md). **Cloud accelerators:** Cloud guardians and cloud custodians naturally harvest scripts and automations that accelerate the deployment of environments, platforms, or even components of various applications. Curating and sharing these scripts in addition to centralized governance responsibilities develops a high degree of respect for these architects throughout IT. diff --git a/docs/cloud-adoption/organization/cost-conscious-organization.md b/docs/cloud-adoption/organization/cost-conscious-organization.md index 7c055610ec7..8adcfc3eeba 100644 --- a/docs/cloud-adoption/organization/cost-conscious-organization.md +++ b/docs/cloud-adoption/organization/cost-conscious-organization.md @@ -39,7 +39,7 @@ Building cost consciousness into cloud-adoption efforts starts at the leadership - **Visibility:** The cloud strategy team and [cloud governance team](./cloud-governance.md) need to know the actual costs of the cloud-adoption efforts. Given the executive-level view of this team, they should have access to multiple cost scopes to analyze spending decisions. Typically, an executive needs visibility into the total costs across all cloud "spend." But as active members of the cloud strategy team, they should also be able to view costs per business unit or per billing unit to validate showback, chargeback, or other [cloud accounting models](../business-strategy/cloud-accounting.md). -- **Accountability:** Budgets should be established between the cloud strategy, [cloud governance](./cloud-governance.md), and [cloud adoption](./cloud-adoption.md) teams based on expected adoption activities. When deviations from budget occur, the cloud strategy and cloud governance teams must partner to quickly determine the best course of action to remediate the deviations. +- **Accountability:** Budgets should be established between the cloud strategy, [cloud governance](./cloud-governance.md), and [cloud adoption](./cloud-adoption.md) teams based on expected adoption activities. When deviations from budget occur, the cloud strategy team and the cloud governance team must partner to quickly determine the best course of action to remediate the deviations. - **Optimization:** During optimization efforts, the cloud strategy team can represent the investment and return value of specific workloads. If a workload has strategic value or financial impact on the business, cost-optimization efforts should be monitored closely. If there's no strategic impact on the organization and no inherent cost for poor performance of a workload, the cloud strategy team may approve overoptimization. To drive these decisions, the team must be able to view costs on a per-project scope. @@ -54,7 +54,7 @@ The [cloud adoption team](./cloud-adoption.md) is at the center of all adoption - **Accountability:** The cloud adoption team needs to be aware of any preset budgets that are associated with their adoption efforts. When real costs don't align with the budget, there's an opportunity to create accountability. Accountability doesn't equate to penalizing the adoption team for exceeding budget, because budget excess can result from necessary performance decisions. Instead, accountability means educating the team about the goals and how their decisions affect those goals. Additionally, accountability includes providing a dialog in which the team can communicate about decisions that led to overspending. If those decisions are misaligned with the goals of the project, this effort provides a good opportunity to partner with the cloud strategy team to make better decisions. -- **Optimization:** This effort is a balancing act, as optimization of resources can reduce the performance of the workloads that they support. Sometimes anticipated or budgeted savings can't be realized for a workload because the workload doesn't perform adequately with the budgeted resources. In those cases, the cloud adoption team has to make wise decisions and report changes to the cloud strategy and cloud governance teams so that budgets or optimization decisions can be corrected. +- **Optimization:** This effort is a balancing act, as optimization of resources can reduce the performance of the workloads that they support. Sometimes anticipated or budgeted savings can't be realized for a workload because the workload doesn't perform adequately with the budgeted resources. In those cases, the cloud adoption team has to make wise decisions and report changes to the cloud strategy team and the cloud governance team so that budgets or optimization decisions can be corrected. ## Cloud governance team @@ -64,7 +64,7 @@ This effort focuses on the following activities that are related to the developm - **Visibility:** The cloud governance team works as a peer of the cloud strategy team to plan cloud-adoption budgets. These two teams also work together to regularly review actual expenses. The cloud governance team is responsible for ensuring consistent, reliable cost reporting and performance telemetry. -- **Accountability:** When budget deviations occur, the cloud strategy and cloud governance teams partner to quickly determine the best course of action to remediate the deviations. Generally, the cloud governance team will act on those decisions. Sometimes the action may be simple retraining for the affected [cloud adoption team](./cloud-adoption.md). The cloud governance team can also help optimize deployed assets, change discounting options, or even implement automated cost-control options like blocking deployment of unplanned assets. +- **Accountability:** When budget deviations occur, the cloud strategy team and the cloud governance team must partner to quickly determine the best course of action to remediate the deviations. Generally, the cloud governance team will act on those decisions. Sometimes the action may be simple retraining for the affected [cloud adoption team](./cloud-adoption.md). The cloud governance team can also help optimize deployed assets, change discounting options, or even implement automated cost-control options like blocking deployment of unplanned assets. - **Optimization:** After assets are migrated to or created in the cloud, you can employ monitoring tools to assess performance and utilization of those assets. Proper monitoring and performance data can identify assets that should be optimized. The cloud governance team is responsible for ensuring that the monitoring and cost-reporting tools are consistently deployed. They can also help the adoption teams identify opportunities to optimize based on performance and cost telemetry. diff --git a/docs/cloud-adoption/organization/fiefdoms-silos.md b/docs/cloud-adoption/organization/fiefdoms-silos.md index a9f5ba8e7ae..d7312ee5661 100644 --- a/docs/cloud-adoption/organization/fiefdoms-silos.md +++ b/docs/cloud-adoption/organization/fiefdoms-silos.md @@ -129,7 +129,7 @@ Alignment with business stakeholders, business motivations, and business outcome ## Next steps -Disrupting organizational antipatterns is a team effort. To begin acting on this guidance, review the organizational readiness introduction for help with identifying the right team structures and participants: +Disrupting organizational antipatterns is a team effort. To act on this guidance, review the organizational readiness introduction to identify the right team structures and participants: > [!div class="nextstepaction"] > [Identify the right team structures and participants](./index.md) diff --git a/docs/cloud-adoption/plan/adapt-roles-skills-processes.md b/docs/cloud-adoption/plan/adapt-roles-skills-processes.md index 55bbb5f9704..6b795c3eef4 100644 --- a/docs/cloud-adoption/plan/adapt-roles-skills-processes.md +++ b/docs/cloud-adoption/plan/adapt-roles-skills-processes.md @@ -12,7 +12,7 @@ ms.subservice: plan # Adapt existing roles, skills, and processes for the cloud -At each evolutionary phase of the IT industry's history, the most notable changes have often been marked by changes in staff roles. One example is the transition from mainframe computing to client/server computing. The role of the computer operator during this transition has largely disappeared, replaced by the system administrator role. When virtualization arrived, the requirement for individuals working with physical servers was replaced with a need for virtualization specialists. +At each phase of the IT industry's history, the most notable changes have often been marked by changes in staff roles. One example is the transition from mainframe computing to client/server computing. The role of the computer operator during this transition has largely disappeared, replaced by the system administrator role. When virtualization arrived, the requirement for individuals working with physical servers was replaced with a need for virtualization specialists. Roles will likely change as institutions similarly shift to cloud computing. For example, datacenter specialists might be replaced with cloud administrators or cloud architects. In some cases, though IT job titles haven't changed, the daily work of these roles has evolved significantly. @@ -49,7 +49,7 @@ Track these dependencies and make note of the processes that will support them. ## Next steps -Ensuring proper support for the translated roles is a team effort. To begin acting on this guidance, review the [organizational readiness intro](./index.md) for help with identifying the right team structures and participants. +Ensuring proper support for the translated roles is a team effort. To act on this guidance, review the [organizational readiness introduction](../organization/index.md) to identify the right team structures and participants. > [!div class="nextstepaction"] > [Identify the right team structures](./index.md) diff --git a/docs/cloud-adoption/plan/review-rationalization.md b/docs/cloud-adoption/plan/review-rationalization.md index 9f1745b1d14..3f8a3b8744d 100644 --- a/docs/cloud-adoption/plan/review-rationalization.md +++ b/docs/cloud-adoption/plan/review-rationalization.md @@ -12,7 +12,7 @@ ms.subservice: plan # Review rationalization decisions -During initial strategy and planning phases, we suggest you apply an [incremental rationalization](../digital-estate/rationalize.md#incremental-rationalization) approach to the digital estate. But this approach embeds some assumptions into the resulting decisions. We advise the cloud strategy and cloud adoption teams to review those decisions in light of expanded-workload documentation. This review is also a good time to involve business stakeholders and the executive sponsor in future state decisions. +During initial strategy and planning phases, we suggest you apply an [incremental rationalization](../digital-estate/rationalize.md#incremental-rationalization) approach to the digital estate. But this approach embeds some assumptions into the resulting decisions. We advise the cloud strategy team and the cloud adoption teams to review those decisions in light of expanded-workload documentation. This review is also a good time to involve business stakeholders and the executive sponsor in future state decisions. > [!IMPORTANT] > Further validation of the rationalization decisions will occur during the assessment phase of migration. This validation focuses on business review of the rationalization to align resources appropriately. diff --git a/docs/cloud-adoption/plan/workloads.md b/docs/cloud-adoption/plan/workloads.md index 6dd6de6e2b7..2dac19142aa 100644 --- a/docs/cloud-adoption/plan/workloads.md +++ b/docs/cloud-adoption/plan/workloads.md @@ -30,7 +30,7 @@ The strategic inputs from the prerequisites checklist make the following tasks m During the process of [incremental rationalization](../digital-estate/rationalize.md), your team should agree on a "Power of 10" approach, which consists of 10 priority workloads. These workloads serve as an initial boundary for adoption planning. -If you decide that a digital estate rationalization isn't needed, we recommend that the cloud adoption and cloud strategy teams agree on a list of 10 applications to serve as the initial focus of the migration. We recommend further that these 10 workloads contain a mixture of simple workloads (fewer than 10 assets in a self-contained deployment) and more complex workloads. Those 10 workloads will start the workload prioritization process. +If you decide that a digital estate rationalization isn't needed, we recommend that the cloud adoption teams and the cloud strategy team agree on a list of 10 applications to serve as the initial focus of the migration. We recommend further that these 10 workloads contain a mixture of simple workloads (fewer than 10 assets in a self-contained deployment) and more complex workloads. Those 10 workloads will start the workload prioritization process. > [!NOTE] > The Power of 10 serves as an initial boundary for planning, to focus the energy and investment in early-stage analysis. However, the act of analyzing and defining workloads is likely to cause changes in the list of priority workloads. @@ -94,7 +94,7 @@ After initial priorities have been defined and workloads have been added to the ## Confirm priorities -Based on the assembled data, the cloud strategy team and cloud adoption team should meet to reevaluate priorities. Clarification of business data points might prompt changes in priorities. Technical complexity or dependencies might result in changes related to staffing allocations, timelines, or sequencing of technical efforts. +Based on the assembled data, the cloud strategy team and the cloud adoption team should meet to reevaluate priorities. Clarification of business data points might prompt changes in priorities. Technical complexity or dependencies might result in changes related to staffing allocations, timelines, or sequencing of technical efforts. After a review, both teams should be comfortable with confirming the resulting priorities. This set of documented, validated, and confirmed priorities is the prioritized cloud adoption backlog. diff --git a/docs/cloud-adoption/ready/initial-org-alignment.md b/docs/cloud-adoption/ready/initial-org-alignment.md index cdbf892f4b3..e77b4cf2f37 100644 --- a/docs/cloud-adoption/ready/initial-org-alignment.md +++ b/docs/cloud-adoption/ready/initial-org-alignment.md @@ -34,11 +34,11 @@ The high-level process for the digital transformation is: The first step in your enterprise's digital transformation is engaging business leaders from across the organization to create a cloud strategy team (CST). This team consists of business leaders from finance, IT infrastructure, and application groups. These teams can help with the cloud analysis and experimentation phase. -For instance, a Cloud Strategy team could be driven by the CTO and consist of members of the enterprise architecture team, IT finance, senior technologists from various IT applications groups (HR, finance, and so on), and leaders from the infrastructure, security, and networking teams. +For instance, a cloud strategy team could be driven by the CTO and consist of members of the enterprise architecture team, IT finance, senior technologists from various IT applications groups (HR, finance, and so on), and leaders from the infrastructure, security, and networking teams. It's also important to form two other high-level teams: a governance team and a security team. These teams are responsible for designing, implementing, and the ongoing audit of the enterprise's governance and security policies. The governance team requires members that have worked with asset protection, cost management, group policy, and related topics. The security team requires members that are well versed in current industry security standards as well as the enterprise's security requirements. -![Cloud Strategy team, with governance and security teams](../_images/getting-started-overview-1.png) +![Cloud strategy team, with governance and security teams](../_images/getting-started-overview-1.png) The governance team is responsible for designing and implementing the enterprise's governance model in the cloud, as well as deploying and maintaining the shared infrastructure assets that are part of the digital transformation. These assets include hardware, software, and cloud resources necessary to connect the on-premises network to virtual networking in the cloud. @@ -56,7 +56,7 @@ For advanced learning, the governance team should review the concepts and design ## Step 3: Identify gaps in business strategy -The next step is for the Cloud Strategy team to enumerate the business problems that require a digital transformation solution. For example, an enterprise may have an existing on-premises datacenter with end-of-life hardware that requires replacement. In another example, an enterprise may be experiencing difficulty with time-to-market for new features and services and may be falling behind to competition. These gaps represent the _goals_ of your enterprise's digital transformation. +The next step is for the cloud strategy team to enumerate the business problems that require a digital transformation solution. For example, an enterprise may have an existing on-premises datacenter with end-of-life hardware that requires replacement. In another example, an enterprise may be experiencing difficulty with time-to-market for new features and services and may be falling behind to competition. These gaps represent the _goals_ of your enterprise's digital transformation. Gaps in business strategy can be classified into the following categories: @@ -88,7 +88,7 @@ Now that the goals of the digital transformation have been enumerated, prioritiz The teams take the prioritized lists and work through each high-level solution to design each solution. The design process will involve the specification of new infrastructure and new workloads. There may also be changes to the roles of the people and the processes they follow. It's also important at this stage for each of the design teams to include both the governance and security teams for review of each design. Each design must fall within with the policies and procedures defined by the governance and security teams, and these teams must be included in the final approval of each design. -![Cloud Strategy team delivers high-level solutions to design and implementation teams.](../_images/getting-started-overview-3.png) +![cloud strategy team delivers high-level solutions to design and implementation teams.](../_images/getting-started-overview-3.png) The design of each solution is a nontrivial task. As designs are created, they must be considered in the context of other solution designs from other teams. For example, if several of the designs result in a migration of existing on-premises applications and services to the cloud, it may be more efficient to group these together and design an overall migration strategy. In another example, it may not be possible to migrate some existing on-premises applications and services and the solution may be to replace them with either new development or third-party services. In this case, it may be more efficient to group these together and determine the overlap between them to determine if a third-party service can be used for more than one solution. @@ -96,7 +96,7 @@ Once the design of the solution is complete, the team moves on to the implementa ## Step 5: Adapt existing roles, skills, and process for the cloud -At each evolutionary phase during the history of the IT industry, the most notable industry changes are often marked by changes in staff roles. During the transition from mainframes to the client/server model, the role of the computer operator largely disappeared, replaced by the system administrator. When the age of virtualization arrived, the requirement for individuals working with physical servers diminished, replaced with a need for virtualization specialists. Similarly, as institutions shift to cloud computing, roles will likely change again. For example, datacenter specialists might be replaced with cloud financial analysts. Even in cases where IT job titles have not changed, the daily work roles have evolved significantly. +At each phase of the history of the IT industry, the most notable industry changes are often marked by changes in staff roles. During the transition from mainframes to the client/server model, the role of the computer operator largely disappeared, replaced by the system administrator. When the age of virtualization arrived, the requirement for individuals working with physical servers diminished, replaced with a need for virtualization specialists. Similarly, as institutions shift to cloud computing, roles will likely change again. For example, datacenter specialists might be replaced with cloud financial analysts. Even in cases where IT job titles have not changed, the daily work roles have evolved significantly. IT staff members may feel anxious about their roles and positions as they realize that a different set of skills is needed for the support of cloud solutions. But agile employees who explore and learn new cloud technologies don’t need to have that fear. They can lead the adoption of cloud services and help the organization understand and embrace the associated changes. diff --git a/docs/cloud-adoption/ready/technical-skills.md b/docs/cloud-adoption/ready/technical-skills.md index 43a90d136fa..44d72f902ee 100644 --- a/docs/cloud-adoption/ready/technical-skills.md +++ b/docs/cloud-adoption/ready/technical-skills.md @@ -16,7 +16,7 @@ Cloud adoption requires retooling for some IT roles. This section of the Cloud A ## Migration skill building -During cloud migration efforts, all members of the cloud adoption teams and Cloud Strategy team can use Microsoft Learn modules to develop necessary skills. +During cloud migration efforts, all members of the cloud adoption teams and the cloud strategy team can use Microsoft Learn modules to develop necessary skills. [Business users](/learn/browse/?roles=business-user) may experience a steep learning curve when asked to participate in planning, testing, and adoption of cloud-based technology. Microsoft Learn helps business users with modules focused on adopting cloud models and tools for better managing the business through cloud-based services. diff --git a/docs/microservices/ci-cd-kubernetes.md b/docs/microservices/ci-cd-kubernetes.md index 760bb9a3b63..973e6590ec6 100644 --- a/docs/microservices/ci-cd-kubernetes.md +++ b/docs/microservices/ci-cd-kubernetes.md @@ -200,6 +200,9 @@ Consider using Helm to manage building and deploying services. Here are some of For more information about using Container Registry as a Helm repository, see [Use Azure Container Registry as a Helm repository for your application charts](/azure/container-registry/container-registry-helm-repos). +> [!IMPORTANT] +> This feature is currently in preview. Previews are made available to you on the condition that you agree to the [supplemental terms of use](https://azure.microsoft.com/support/legal/preview-supplemental-terms/). Some aspects of this feature may change prior to general availability (GA). + A single microservice may involve multiple Kubernetes configuration files. Updating a service can mean touching all of these files to update selectors, labels, and image tags. Helm treats these as a single package called a chart and allows you to easily update the YAML files by using variables. Helm uses a template language (based on Go templates) to let you write parameterized YAML configuration files. For example, here's part of a YAML file that defines a deployment: @@ -394,4 +397,4 @@ The following diagram shows the end-to-end CI/CD process described in this artic This article was based on a reference implementation that you can find on [GitHub][ri]. -[ri]: https://github.com/mspnp/microservices-reference-implementation \ No newline at end of file +[ri]: https://github.com/mspnp/microservices-reference-implementation diff --git a/docs/multitenant-identity/tailspin.md b/docs/multitenant-identity/tailspin.md index 3e13cb1061c..2b704c6d3c3 100644 --- a/docs/multitenant-identity/tailspin.md +++ b/docs/multitenant-identity/tailspin.md @@ -12,7 +12,7 @@ ms.subservice: reference-architecture [![GitHub](../_images/github.png) Sample code][sample application] -Tailspin is a fictitious company that is developing a SaaS application named Surveys. This application enables organizations to create and publish online surveys. +Tailspin is a fictional company that is developing a SaaS application named Surveys. This application enables organizations to create and publish online surveys. * An organization can sign up for the application. * After the organization is signed up, users can sign into the application with their organizational credentials. diff --git a/docs/service-fabric/migrate-from-cloud-services.md b/docs/service-fabric/migrate-from-cloud-services.md index a73f0bf0404..5988e85107d 100644 --- a/docs/service-fabric/migrate-from-cloud-services.md +++ b/docs/service-fabric/migrate-from-cloud-services.md @@ -20,7 +20,7 @@ Before reading this article, it will be useful to understand the basics of Servi ## About the Surveys application -A fictitious company named Tailspin created an application called the Surveys app that allows customers to create surveys. After a customer signs up for the application, users can create and publish surveys, and collect the results for analysis. The application includes a public website where people can take a survey. Read more about the original Tailspin scenario [here][tailspin-scenario]. +A fictional company named Tailspin created an application called the Surveys app that allows customers to create surveys. After a customer signs up for the application, users can create and publish surveys, and collect the results for analysis. The application includes a public website where people can take a survey. Read more about the original Tailspin scenario [here][tailspin-scenario]. Now Tailspin wants to move the Surveys application to a microservices architecture, using Service Fabric running on Azure. Because the application is already deployed as a Cloud Services application, Tailspin adopts a multi-phase approach: diff --git a/docs/vdc/networking-virtual-datacenter.md b/docs/vdc/networking-virtual-datacenter.md index c52128e2504..4ccefd94e73 100644 --- a/docs/vdc/networking-virtual-datacenter.md +++ b/docs/vdc/networking-virtual-datacenter.md @@ -62,7 +62,7 @@ The key to unlock the advantages of VDC is a centralized hub and spoke network t Any Azure customer that has decided to adopt the cloud can benefit from the efficiency of configuring a set of resources for common use by all applications. Depending on the magnitude, even single applications can benefit from using the patterns and components used to build a VDC implementation. -If your organization has a centralized IT, Network, Security, and/or Compliance team/department, implementing a VDC can help enforce policy points, segregation of duty, and ensure uniformity of the underlying common components while giving application teams as much freedom and control as is appropriate for your requirements. +If your organization has centralized teams or departments for IT, networking, security, or compliance, implementing a VDC can help enforce policy points, segregation of duty, and ensure uniformity of the underlying common components while giving application teams as much freedom and control as is appropriate for your requirements. Organizations that are looking to DevOps can also use the VDC concepts to provide authorized pockets of Azure resources and ensure they have total control within that group (either subscription or resource group in a common subscription), but the network and security boundaries stay compliant as defined by a centralized policy in a hub VNet and resource group. @@ -195,7 +195,7 @@ The presence of different Azure AD tenants enforces the separation between envir #### Component type: Infrastructure -This component type is where most of the supporting infrastructure resides. It's also where your centralized IT, Security, and/or Compliance teams spend most of their time. +This component type is where most of the supporting infrastructure resides. It's also where your centralized IT, security, and compliance teams spend most of their time. [![6]][6]