La crescita del cloud richiede confini chiari.

Account, ambienti e diritti amministrativi devono corrispondere all'organizzazione reale. Una separazione per aree di business non coincide sempre con una separazione per applicazioni o per responsabilità operativa. Verifichiamo quindi insieme chi richiede le risorse, chi le gestisce e a chi devono essere attribuite le spese. Vengono considerati anche gli ambienti esistenti. Lo scenario target descrive poi i confini previsti e le loro motivazioni, in modo che le modifiche successive non vengano decise soltanto sulla base di nomi nati per caso o di responsabilità storiche.

Sviluppo, test e produzione ricevono ciascuno la separazione necessaria. Viene inoltre stabilito come utilizzare i servizi condivisi e quali eccezioni possano essere ammesse. L'attuazione non deve impedire ogni particolarità, ma consentirne una gestione tracciabile. Una procedura regolamentata per le eccezioni stabilisce chi decide e chi ne è responsabile. Così l'architettura resta spiegabile anche quando singole applicazioni hanno requisiti particolari o un workload esistente può essere integrato nella struttura comune solo gradualmente.

Una policy documentata non modifica ancora alcuna risorsa. Per i requisiti concordati si verifica quindi quali possano essere implementati tecnicamente e quali richiedano ancora una decisione organizzativa. Ne fanno parte ruoli, accessi di rete, logging e tag di costo. La configurazione deve rendere riconoscibile quali regole siano vincolanti e dove siano necessarie approvazioni. Allo stesso tempo viene descritto il percorso per le modifiche, in modo che un adattamento successivo non debba avvenire al di fuori della base comune.

Una configurazione versionata consente di verificare le modifiche e di documentare in modo tracciabile lo stato previsto. Nell'ambito concordato viene così costruito un percorso di provisioning ripetibile. Questo viene testato con un ambiente concreto, comprese le verifiche e gli accessi necessari. Il vostro team riceve la configurazione insieme alle procedure per il suo utilizzo. Così, da una piattaforma allestita una sola volta, nasce una base a cui altri progetti possono fare riferimento e la cui manutenzione non resta solo a carico dei partecipanti originari del progetto.

La praticabilità della landing zone si verifica con un'applicazione reale. Il vostro team deve ricevere le risorse previste, raggiungere i sistemi necessari e poter svolgere il proprio lavoro con i diritti assegnati. Questa prima prova rende visibili le informazioni mancanti e gli ostacoli superflui. Distinguiamo quindi insieme tra un requisito necessario e una procedura che andrebbe semplificata. Le osservazioni confluiscono nella configurazione e nella documentazione prima di accogliere altri team.

Il passaggio di consegne comprende la responsabilità per la manutenzione della piattaforma, l'inserimento di nuovi progetti e l'approvazione delle modifiche. Anche i punti aperti vengono documentati con le loro conseguenze. Una landing zone non costituisce una conferma definitiva di sicurezza o conformità per ogni applicazione che vi verrà gestita in seguito. La configurazione e l'utilizzo di queste applicazioni vanno valutati separatamente. La base creata supporta questi compiti fornendo procedure comuni e rendendo visibile la responsabilità per le estensioni e le deviazioni.