Moving quickly does not remove responsibilities
This is a retrospective examination of 2018, written and published in 2026. It addresses programme decisions around a cloud landing zone: the shared foundation in which teams deploy applications. It is not a certified architecture. The industrial group, participants, figures and incidents are fictional and used solely for learning.
Olivier, programme director, discovers ten cloud accounts created by ten teams. Each migration has a presentation, quote and working environment. None knows who owns emergency access, where logs are retained or how to recover an application after the administrator who installed it leaves. Finance receives infrastructure bills but cannot distinguish experiments from production services. Rapid provisioning has simply moved the lack of a framework elsewhere.
A landing zone is therefore more than a network ready for machines. It defines autonomy boundaries: who can create, access, connect, expose, back up, pay for and delete resources. The programme needs agreement on that division before accelerating waves. Otherwise, each application brings its own security, billing and operating variant that support must learn separately.
Start with a representative service
Olivier selects an order-tracking application using corporate identity, ERP file exchanges and restoration. It does not represent every system, but crosses several responsibility boundaries. The team describes three journeys: signed-in user, overnight processing and recovery after error. It specifies exchanged data, useful service hours, consuming sites and teams able to act during an incident.
Selecting only a showcase without sensitive data would create false confidence. Starting with the most constrained production system would immobilise delivery before the foundation is tested. A pilot needs meaningful difficulties, manageable risk and a way back. The business confirms those conditions; security accepts the exposure class; operations accepts the scope it will inherit.
The application is treated as a service with an owner and operating window. Naming a cloud provider fills neither role. The division between provider, integrator and client varies with the chosen services. It must be documented for the actual components, not inferred from a generic diagram.
Five decisions for the foundation
First, separate environments and name account or subscription owners. A developer can have test autonomy without authority to modify production directly. Privileged access is individual and traceable. Emergency access is exercised by somebody other than its configurator. An essential exception has an expiry date and an owner.
Second, arrange connections to existing identity and networks. Check required flows, DNS dependencies, ERP routes and site restrictions. An application available on the Internet is not necessarily reachable from a filtered factory network. Rules opened temporarily during the pilot must be closed or explicitly accepted.
Third, define logs, monitoring and alerts. An alert without an available recipient does not establish a monitored service. Fourth, specify backup and restoration, including what each mechanism actually covers. Fifth, allocate cost, capacity and retirement of unused resources. Every rule has an operator, checker and execution evidence. Programme leadership resolves conflicts; it does not replace design expertise.
Application admission checks
| Control | Requirement | Evidence |
|---|---|---|
| Identity | Named administrators; no permanent shared emergency account. | Normal login and identity-unavailability scenario tested. |
| Network | ERP and pilot site reachable using only necessary flows. | Signed flow matrix and test from the site network. |
| Logs | Access events and critical operations available to support. | Find one transaction and one privileged modification. |
| Recovery | Illustrative business objective: service restored within four hours. | Timed restoration and order checks. |
| Cost | Cost centre and owner recorded; test environment stopped overnight. | Allocation report and shutdown check. |
| Exit | Data and configuration needed for recovery exportable. | Readable export and restoration in the rehearsal environment. |
The day the administrator is unavailable
The team wants to close the pilot after a successful demonstration. Olivier requests a rehearsal: the main administrator stays out, and operations selects the backup for recovery. Support finds the files but not ERP exchange configuration. The application is online while orders remain blocked. The technical clock stops; the business clock continues.
The record preserves that distinction. The integrator provides configuration recovery; the business owner specifies reconciliation before resumption; support replays the procedure. A second rehearsal uses only permissions planned for the future service. Project privileges would mask exactly the dependency being removed.
The sponsor receives a bounded choice: approve the next wave after evidence, or retain a limited pilot with priced temporary assistance. There is no abstract demand to “make it more secure.” Additional time is tied to a specific recovery capability, and temporary assistance has an end date.
Understand the cost of what has actually moved
The financial comparison separates cloud consumption, network, backup, monitoring, licences, integration and operating effort. A cheaper machine does not establish a cheaper end-to-end service. The old environment may still be billed if remaining dependencies prevent retirement. Avoided cost is distinguished from commitments remaining after migration.
Here, monthly service cost is €6,000, including €1,200 for test resources. Overnight shutdown reduces some of the latter, not fixed commitments or retained storage. The proposed unit measure is service cost divided by orders actually processed, with volume and period shown. Moving from 20,000 to 30,000 orders changes the ratio without any technical optimisation.
The owner receives an alert when estimated monthly cost exceeds budget by 15% or more than 5% of resources lack an identifiable allocation. These are educational figures. Review distinguishes useful volume growth, configuration drift and incident cost. Automatically stopping an unknown component can be more damaging than paying for it: shutdown requires qualification and ownership.
Avoid a foundation that becomes a ticket factory
The next temptation is central approval of every deployment. Migrations slow down; business teams create parallel accounts. The foundation should provide sufficiently complete standard paths: environment, identity, connectivity, logs and support. Autonomy operates inside those tested limits.
A non-standard request is classified by reason: business requirement, provider limitation, inherited debt or local preference. The central team publishes a review time and decision authority. The programme tracks live and expired exceptions. A forgotten exemption is a parallel architecture; a regularly reviewed one may be a rational compromise.
Keep the catalogue deliberately small. Three proven paths are worth more than fifteen templates that cover no recovery. After each wave, support describes difficulties and the platform removes unnecessary rules. Foundation changes are themselves versioned, tested and communicated to applications already migrated.
Industry, finance and services need different entry checks
In a plant, examine dependencies on external connectivity and local equipment. A link outage can make an intact cloud service unusable. Degraded operation specifies what operators can still do, how data will be reconciled and who authorises normal resumption. A production constraint cannot be solved simply by enlarging a remote machine.
In finance, closing or payment processing may require a window, access separation and particular recovery checks. Evidence extends beyond server availability to reconciled results. For a service exposed to demand peaks, test volumes and difficult behaviour together with associated cost. Holding traffic at the price of uncontrolled spending does not establish an operable model.
These adaptations do not change the shared-foundation principle. They change admission criteria, tests and ownership. Deferring an application until these are met need not mean the entire cloud programme has failed.
Decide the next wave with operators
Before expansion, operations can find a trace, handle an alert, recover the service, obtain data verification and understand cost. Pilot defects have owners and decisions. Candidate applications are compared with proven paths; significant differences are estimated separately. Migration speed becomes a consequence of available rules rather than an achievement gained by transferring problems into operations.
Olivier can explain what is standard, what remains exceptional and why certain applications wait. That clarity helps business teams commit to dates. The landing zone acts as an operating agreement between teams, with practical tests preventing it from becoming only an architecture document.
Sources and method
Both NIST publications predate 2018 and establish cloud-service concepts and risk considerations. The admission checks and case are original operational recommendations independent of a particular provider. Technology evolves: current designs must be checked against provider documentation and client requirements. The economic thresholds are not NIST prescriptions.
- NIST SP 800-145 — The NIST Definition of Cloud Computing, 2011
- NIST SP 800-146 — Cloud Computing Synopsis and Recommendations, 2012
Links checked on 4 October 2026. The scenarios and thresholds in this article are educational; they do not describe a client engagement or an outcome delivered by CYTIZEN.