(DOCSP-43337) Landing Zone Design (#23)

* (DOCSP-43337) Landing Zone Design

* nit on wording

* Copy review changes

Author: sarahsimpers

source/includes/images/LandingZone.png

@@ -9,9 +9,254 @@ Landing Zone Design
 .. contents:: On this page
    :local:
    :backlinks: none
-   :depth: 1
+   :depth: 2
    :class: onecol
 
-Intro statement
+This page:
 
-Content here
+- Introduces the concept of a landing zone, why you need one, and the
+  considerations that influence a landing zone's design.
+- Helps you design a starter landing zone that gives
+  prescriptive guidance on:
+
+  - How your teams can implement {+service+} in accordance with both
+    the {+waf+} pillars and your organization's unique requirements.
+  - How {+service+} fits into your organization's larger ecosystem.
+
+MongoDB's Professional Services team partners with enterprise
+customers to create custom landing zones for {+service+}. If you're
+working with MongoDB's Professional Services, the resources on this
+page can also help you plan for those discussions.
+
+Landing Zone Overview
+---------------------
+
+What is a Landing Zone?
+~~~~~~~~~~~~~~~~~~~~~~~
+
+A landing zone is a well-architected and pre-configured environment for
+working in the cloud that conforms to your organization's unique
+requirements. A landing zone is often a prerequisite for enterprises to
+move workloads to the cloud, and it is is often provisioned
+programatically using an API or tools like Terraform.
+
+An {+service+} landing zone defines how your team will work in
+{+service+}, including the internal settings and tools they should use,
+and how {+service+} will integrate with your other tools.
+
+Why Do You Need a Landing Zone?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Establishing a landing zone gives you confidence that
+every workload your team deploys aligns with your requirements around
+security, performance, reliability, operational efficiency, and cost
+optimization. Designing and sharing out a landing zone helps
+ensure alignment across all teams and stakeholders on how your
+organization will work in {+service+}, and it prevents developers on 
+all of your teams following different standards.
+
+.. _landing-zone-considerations:
+
+What are some Important Landing Zone Considerations?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Consider the following organization-specific
+requirements when you create a landing zone:
+
+.. list-table::
+   :header-rows: 1
+   :widths: 20 40
+
+   * - Consideration
+     - Description
+   
+   * - System Partition Requirements
+     - Identify how you will partition systems for management. For
+       example, clarify how your team should arrange {+service+}
+       projects or {+service+} organizations. 
+       
+       To get recommendations and learn more about this topic, see
+       :ref:`arch-center-hierarchy`.
+   * - Access Controls
+     - Identify MongoDB {+service+} Control Plane access controls, and
+       database access controls for both workload and workforce principals. Create a comprehensive list of principals and mechanisms for how you will authenticate and authorize. Define {+service+} API key access controls, including authorizations and expiration rules.
+   * - Change Control and Auditability Requirements
+     - Clarify any change control or audit controls requirements. This
+       can include change approval processes and tools, along with
+       reporting guidelines.
+
+       To get recommendations and learn more about this topic, see
+       :ref:`arch-center-auditing-logging`.
+   * - Data Residency Requirements
+     - Identify data residency requirements, such as data sovereignty
+       requirements, or application data partitioning rules.
+   * - Network Topology Requirements
+     - Identify network topology requirements, including Cloud Provider
+       regions, private connectivity options, and application
+       deployment topology.
+
+       To get recommendations and learn more about this topic, see
+       :ref:`arch-center-network-security`.
+   * - High Availability Requirements
+     - Identify high availability requirements such as cluster topology
+       with node count and priority per region, global write
+       requirements, and partitioning tolerances.
+
+       To get recommendations and learn more about this topic, see
+       :ref:`arch-center-high-availability`.
+   * - Data Retention Requirements
+     - Identify and record your data retention policies. This may
+       require creating a classification for automation, including
+       creation of archive or purge automation. In some cases, data
+       must be preserved for a certain duration, whereas in other cases
+       data must be purged after some duration. Identify performance
+       characteristics of retrieval of archived records.
+   * - Disaster Recovery Requirements
+     - Identify all disaster recovery requirements, including:
+
+       - Identify and record your current disaster recovery plan. 
+       - Define backup snapshot schedules and retentions.
+       - Identify Restore Time Objective (RTO) and Restore Point
+         Objective (RPO). 
+       - Define backup snapshot locations. 
+       - Identify Point-in-time restore option selection. 
+       - Define recovery methodologies such as restore, queryable
+         backups, document versioning, region shifting, and cloud
+         provider pivot.
+
+       To get recommendations and learn more about this topic, see
+       :ref:`arch-center-backups`.
+   * - Alert Requirements
+     - Identify required alert events, thresholds, recipients, and
+       alert delivery mechanism(s).
+
+       To get recommendations and learn more about this topic, see
+       :ref:`arch-center-monitoring-alerts`.
+   * - Integration Requirements
+     - Identify requirements for external system integrations, such as
+       Log File ingestion, Change Streams, {+service+} Streams, Activity
+       Feed, Audit Log integration, Alerts, and/or Metrics.
+   * - Security, Legal, and Compliance Requirements
+     - Identify and define any specific security, legal, or compliance
+       requirements not clearly articulated within other requirements
+       definitions. Consider integration requirements with Security
+       Information and Event Management (SIEM) systems.
+
+       To learn more about compliance, see
+       :ref:`arch-center-compliance`.
+   * - Maintenance Requirements
+     - Identify whether you have any specific requirements regarding
+       Maintenance windows or upgrade deferments.
+   * - Backup Snapshot Requirements
+     - Identify all backup snapshot requirements, including:
+     
+       - Identify snapshot schedule, retention, and multi-region
+         distribution requirements.  
+       - Identify Point-in-time (PIT) backup requirements. 
+       - Identify Encryption at rest requirements for backup snapshots.
+       - Identify snapshot access requirements (for example, should
+         snapshot download be allowed?).
+
+       To get recommendations and learn more about this topic, see
+       :ref:`arch-center-backups`.
+   * - Billing Requirements
+     - Identify any specific requirements to billing aspects of any
+       systems where definition will drive automation. Consider {+service+}
+       cross-org billing, including department charge-backs. Consider
+       billing systems integrations.
+
+       To get recommendations and learn more about this topic, see
+       :ref:`arch-center-billing-data`.
+
+Finally, prioritize requirements based on their importance and impact.
+
+Design Your Landing Zone
+------------------------
+
+Use the following resources to design an {+service+} landing zone.
+We recommend that you compile all diagrams, recommendations, and
+examples in a document and adjust them to meet your organization's
+requirements.
+
+Designing a landing zone is an iterative process that involves reviewing
+and realigning based on changing requirements. The following resources
+provide a starting point to begin your organization's first {+service+}
+landing zone.
+
+Example Landing Zone Diagram
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The following example diagram unifies many of the architectural diagrams
+across the {+atlas-arch-center+} in one image to visualize your
+landing zone. You can download
+the `SVG of the example diagram in Github 
+<https://github.com/mongodb/docs-atlas-architecture/blob/main/source/includes/images/LandingZone.svg>`__, upload it to an SVG editor,
+and adjust it as needed to customize it for your organization.
+
+**DIAGRAM BELOW TO BE CHANGED FOR FINAL DIAGRAM**
+
+.. If you update the following diagram PNG file, you must also update
+.. the SVG file with the same name in /includes/images/.
+.. Customers can download the SVG from Github and edit it.
+
+.. image:: /includes/images/LandingZone.png
+   :alt: "A diagram showing an example {+service+} landing zone."
+   :width: 750px
+   :align: center
+
+Information in the {+atlas-arch-center+}
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+To begin, :ref:`plan your migration tools and strategy
+<arch-center-migration>` to move your on-premise deployments to {+service+}. This plan should be included in your landing zone document.
+
+After you plan your migration, copy the relevant guidance and examples in :ref:`arch-center-hierarchy`, which helps you create your first foundational components in {+service+}.
+
+Then, review the guidance and examples for each of the pages nested under each {+waf+} pillar in the {+atlas-arch-center+}. Copy the
+diagrams, recommendations, tools, and examples that are relevant for
+your organization:
+
+- Operational Efficiency
+
+  - :ref:`arch-center-automation`
+  - :ref:`arch-center-monitoring-alerts`
+- Security
+
+  - :ref:`arch-center-network-security`
+  - :ref:`arch-center-auth`
+  - :ref:`arch-center-data-encryption`
+  - :ref:`arch-center-compliance`
+  - :ref:`arch-center-auditing-logging`
+- Reliability
+
+  - :ref:`arch-center-high-availability`
+  - :ref:`arch-center-resiliency`
+  - :ref:`arch-center-backups`
+- Performance
+
+  - :ref:`arch-center-scalability`
+- Cost Optimization
+
+  - :ref:`arch-center-cost-saving-config`
+  - :ref:`arch-center-billing-data`
+
+Your Organization's Requirements
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Adjust the example landing zone diagram, recommendations, and examples
+that you copied from the {+atlas-arch-center+} to fit your
+organization's specific requirements. For example, if you use only 
+{+gcp+} as a cloud provider, your landing zone should specify that
+requirement and you should exclude any recommendations and examples
+applicable only to |aws| and |azure|.
+
+To identify more considerations and requirements specific to your
+organization, see the previous section on
+:ref:`landing-zone-considerations`.
+
+Next Steps
+----------
+
+See the :ref:`arch-center-migration` page to plan your migration
+to {+service+} or use the left
+navigation to find features and best practices for each {+waf+} pillar.

source/includes/images/LandingZone.svg

@@ -122,4 +122,10 @@ Cutover
 
 .. include:: /includes/cloud-docs/shared-migration-cutover-description.rst
 
-To learn more, see :ref:`monitor-migrations`.
+To learn more, see :ref:`monitor-migrations`.
+
+Next Steps
+----------
+
+See the :ref:`arch-center-hierarchy` page to learn about the building blocks of your {+service+} enterprise estate or use the left
+navigation to find features and best practices for each {+waf+} pillar.