Fikcyjny scenariusz edukacyjny. Nie opisuje konkretnej organizacji ani dostawcy.
Sytuacja
Organizacja kupuje usługę SaaS. Własny zespół ma zbudować kanał użytkownika i integrację, ale dokumentacja architektoniczna zostaje sprowadzona do diagramu „nasz system → API SaaS”. W przeglądzie pada argument: „Nie utrzymujemy ich serwerów, więc ich architektura nas nie interesuje”.
Gdzie powstaje antywzorzec
Prawdziwe stwierdzenie — klient nie zarządza wewnętrzną technologią dostawcy — zostaje rozszerzone na fałszywy wniosek, że nie trzeba rozumieć zachowania usługi ani granicy odpowiedzialności. W rezultacie elementy, których klient nie kontroluje, stają się jednocześnie zależnościami, których nikt nie opisał.
Objawy
- API i SLA są traktowane jako kompletny opis rozwiązania;
- brak właściciela dla błędów występujących pomiędzy kanałem klienta a SaaS;
- nikt nie potrafi powiedzieć, gdzie przetwarzane i retencjonowane są dane;
- IAM opisuje tylko logowanie, bez ról, dostępu supportu i odebrania uprawnień;
- RTO/RPO dotyczą „platformy”, ale nie pełnej ścieżki biznesowej;
- monitoring klienta kończy się na kodzie HTTP;
- zmiana lub zakończenie dostawcy nie ma procedury eksportu i odłączenia.
Konsekwencje
Podczas incydentu obie strony mogą widzieć zielone własne komponenty, a użytkownik nadal nie wykonuje procesu. Niejasne odpowiedzialności wydłużają eskalację. Ograniczenia danych albo wersjonowania wychodzą dopiero przy wdrożeniu. Exit strategy powstaje w chwili, gdy organizacja już chce wyjść.
Lepsza decyzja
- Zdefiniuj granicę usługi i odpowiedzialność obu stron.
- Opisz przepływ danych, IAM i kontrakty integracyjne.
- Ustal NFR oraz sposób ich pomiaru i dowodzenia.
- Zaprojektuj model operacyjny: monitoring, korelację, incydenty, maintenance i recovery.
- Ustal lifecycle oraz exit przed uzależnieniem procesu od usługi.
- Żądaj szczegółów implementacyjnych tylko wtedy, gdy konkretne wymaganie albo ryzyko ich potrzebuje.
Granica
Przeciwieństwem tego antywzorca nie jest mikrozarządzanie dostawcą. W SaaS celowo deleguje się znaczną część implementacji i operacji. Dojrzałość polega na tym, aby delegować świadomie, z jawnym kontraktem odpowiedzialności i dowodami dla zachowania, od którego zależy organizacja.
„Nie operujemy ich infrastruktury” nie oznacza „nie musimy rozumieć usługi”.