Rozwój chmury wymaga jasnych granic.

Konta, środowiska i uprawnienia administracyjne muszą odpowiadać rzeczywistej organizacji. Podział według działów biznesowych nie zawsze jest taki sam jak podział według aplikacji lub odpowiedzialności za eksploatację. Dlatego wspólnie sprawdzamy, kto zamawia zasoby, kto je obsługuje i komu mają być przypisane wydatki. Uwzględnia się przy tym istniejące środowiska. Model docelowy opisuje następnie zamierzone granice i ich przyczyny, aby późniejszych decyzji o zmianach nie podejmowano wyłącznie na podstawie przypadkowo powstałych nazw lub historycznych zakresów odpowiedzialności.

Środowiska rozwojowe, testowe i produkcyjne są od siebie oddzielone w wymaganym stopniu. Ponadto określa się, jak wykorzystywane są usługi wspólne i jakie wyjątki mogą być dopuszczone. Wdrożenie nie ma blokować każdego nietypowego przypadku, lecz zapewniać przejrzysty sposób postępowania z nim. Uregulowana ścieżka wyjątków wskazuje, kto decyduje i kto ponosi odpowiedzialność. Dzięki temu architekturę da się wyjaśnić także wtedy, gdy poszczególne aplikacje mają szczególne wymagania albo istniejące obciążenie robocze (workload) można na początku włączać do wspólnej struktury tylko stopniowo.

Udokumentowana polityka sama jeszcze nie zmienia żadnego zasobu. Dla uzgodnionych wytycznych sprawdza się więc, które z nich można odwzorować technicznie, a które wciąż wymagają decyzji organizacyjnej. Należą do nich role, dostępy sieciowe, rejestrowanie zdarzeń i oznaczenia kosztowe. Konfiguracja ma pokazywać, które reguły obowiązują wiążąco i gdzie wymagane są zatwierdzenia. Jednocześnie opisuje się sposób wprowadzania zmian, aby późniejsze dostosowanie nie odbywało się poza wspólną podstawą.

Wersjonowana konfiguracja pozwala sprawdzać zmiany i przejrzyście dokumentować zamierzony stan. W uzgodnionym zakresie buduje się na tej podstawie powtarzalną ścieżkę wdrażania. Jest ona testowana w konkretnym środowisku, wraz z niezbędnymi kontrolami i dostępami. Państwa zespół otrzymuje konfigurację razem z procedurami jej stosowania. Dzięki temu z jednorazowo skonfigurowanej platformy powstaje podstawa, którą mogą się kierować kolejne projekty i za której utrzymanie nie odpowiadają wyłącznie pierwotni uczestnicy projektu.

To, czy Landing Zone sprawdza się w praktyce, widać dopiero na rzeczywistej aplikacji. Państwa zespół musi otrzymać przewidziane zasoby, mieć dostęp do potrzebnych systemów i móc wykonywać swoją pracę z przypisanymi uprawnieniami. Ten pierwszy przebieg ujawnia brakujące informacje i niepotrzebne przeszkody. Wspólnie odróżniamy przy tym niezbędny wymóg od procesu, który należałoby uprościć. Obserwacje trafiają do konfiguracji i dokumentacji, zanim zostaną włączone kolejne zespoły.

Do przekazania należą odpowiedzialność za utrzymanie platformy, przyjmowanie nowych projektów i zatwierdzanie zmian. Dokumentowane są również otwarte kwestie wraz z ich konsekwencjami. Landing Zone nie jest ostatecznym potwierdzeniem bezpieczeństwa lub zgodności dla każdej aplikacji, która będzie w niej później eksploatowana. Konfigurację i sposób wykorzystania takich aplikacji trzeba rozpatrywać odrębnie. Utworzona podstawa wspiera te zadania, udostępniając wspólne procedury i czyniąc widoczną odpowiedzialność za rozszerzenia oraz odstępstwa.