Wiele chmur. Jeden jasny plan.

Systemu nie można sensownie umieścić bez znajomości ścieżek przepływu jego danych. Aplikacja eksploatowana lokalnie może być ściśle powiązana z bazą danych, podłączeniem maszyn lub zarządzaniem użytkownikami. Jeśli poszczególne części zostaną przeniesione, czas odpowiedzi i zależność od połączeń mogą zyskać na znaczeniu. Dlatego wspólnie rozważamy, które komponenty powinny pozostać razem, a które można rzeczywiście eksploatować rozdzielnie. Pożądane wykorzystanie wielu dostawców jest oceniane w odniesieniu do tych wymagań, a nie przyjmowane jako cel sam w sobie.

Model docelowy uwzględnia korzyść biznesową w takim samym stopniu jak dodatkowy nakład pracy. Różne środowiska mogą wymagać własnych procedur dostępu, narzędzi i kompetencji. Do analizy należą również bieżący ruch danych i obsługa wspólnych interfejsów. Decyzja dokumentuje, dlaczego aplikacja pozostaje w określonym miejscu albo ma zostać do niego przeniesiona. Powstaje w ten sposób architektura, którą można sprawdzić przy późniejszych zmianach i której rozproszenie wynika z wymagań Państwa aplikacji.

Nawiązanie połączenia sieciowego nie dowodzi jeszcze, że aplikacja działa przez nie w pełni prawidłowo. Rozwiązywanie nazw, uprawnienia użytkowników, dostępy do danych i zewnętrzne interfejsy mogą mieć dodatkowe wymagania. Dlatego przy wdrożeniu potrzebne ścieżki komunikacji są wspólnie identyfikowane i konfigurowane. Następnie uczestnicy po stronie technicznej i biznesowej sprawdzają istotne procesy. Dzięki temu można stwierdzić, czy środowisko jest nie tylko dostępne, lecz także rzeczywiście realizuje przewidziane zadania w nowych warunkach.

Ponadto ocenia się, co dzieje się w razie przerwania połączenia. Które komponenty pozostają użyteczne, które procesy czekają i jakie dane trzeba potem zsynchronizować? Odpowiedzi określają, jakie procedury są potrzebne w eksploatacji. Testy i dokumentacja ujawniają granice wybranej architektury. Jeśli oczekiwane zachowanie nie zostaje osiągnięte, trzeba podjąć świadomą decyzję o dostosowaniu, dodatkowych działaniach albo pozostającym ograniczeniu. Ta decyzja stanowi część odbioru integracji.

W przypadku awarii obejmującej kilka środowisk często na początku nie jest jasne, która część jest przyczyną problemu. Bez uzgodnionych ścieżek zgłaszania poszczególne strony mogą wtedy odsyłać się nawzajem do cudzego zakresu odpowiedzialności. Dlatego wspólnie ustalamy, kto przyjmuje zgłoszenie incydentu, jakie informacje są potrzebne i jak włączane są kolejne osoby. Opisuje się również uzgadnianie zmian, aby interwencja w jednym środowisku nie miała niezauważonego wpływu na inne aplikacje lub lokalizacje.

Możliwa późniejsza zmiana dostawcy jest rozpatrywana na podstawie konkretnych zależności: eksportu danych, wykorzystywanych usług, konfiguracji i niezbędnych dostosowań aplikacji. Korzystanie z wielu dostawców nie oznacza automatycznie, że aplikację można bez trudu przenosić między nimi. Te ograniczenia są dokumentowane, a możliwy nakład pracy jest oceniany. Państwa zespół otrzymuje dzięki temu przejrzystą podstawę do przyszłych decyzji i może ocenić, jakie przygotowania byłyby potrzebne do przeniesienia lub konsolidacji środowiska systemowego.