Kupno SaaS ogranicza zakres technologii, którą klient projektuje i utrzymuje. Nadal trzeba opisać system powstający na styku organizacji: kanał użytkownika, tożsamość, dane, integrację i ciągłość procesu.

1. Zacznij od modelu odpowiedzialności

Podział obowiązków nie wynika automatycznie z etykiety SaaS. Zależy od modelu wdrożenia i integracji. Czysty provider-hosted SaaS daje inną granicę niż rozwiązanie z agentem, terminalem, komponentem lub data plane działającym w środowisku klienta.

Pierwszym artefaktem powinien być nie diagram technologii, lecz macierz odpowiedzialności obejmująca co najmniej: usługę SaaS, kanał klienta, IAM, dane, integracje, sieć, konfigurację, certyfikaty/sekrety, monitoring, incident management, continuity i exit.

2. Rozdziel „jak dostawca to zbudował” od „jak usługa zachowuje się na granicy”

Pytania o język, framework czy liczbę mikroserwisów są przydatne tylko wtedy, gdy prowadzą do ryzyka, które klient musi ocenić. Znacznie ważniejsze są: kontrakt API, ograniczenia, semantyka błędów, lifecycle, izolacja, sposób pracy administratorów dostawcy oraz zachowanie podczas awarii.

3. Siedem obszarów due diligence

Obszar Co trzeba ustalić Przykład dowodu
Odpowiedzialność kto operuje czym i kto reaguje RACI / responsibility matrix
Dane lokalizacja, retencja, izolacja, backup, eksport data flow + polityka + test eksportu
IAM federacja, role, PIM/PAM, dostęp supportu test SSO i odebrania uprawnień
Integracja API, wersjonowanie, limity, błędy kontrakt + test negatywny/failure test
NFR dostępność, latency, capacity, RTO/RPO SLO/SLA + sposób pomiaru + drill
Operacje monitoring, status, incydent, zmiana runbook + telemetry + escalation path
Exit przenośność danych i zakończenie usługi format eksportu + exit rehearsal

4. RTO/RPO i SLA nie mogą być dekoracją

SLA mówi niewiele, jeśli nie wiadomo, co dokładnie jest mierzone i z której perspektywy. RTO/RPO wymagają zdefiniowania granicy danych i funkcji. Jeżeli klient utrzymuje własny kanał, pełny user journey może mieć inne RTO niż sama usługa dostawcy.

5. Observability jest częścią kontraktu operacyjnego

Klient nie potrzebuje dostępu do każdego wewnętrznego logu dostawcy. Potrzebuje wystarczającej informacji, aby rozpoznać stan usługi i własnych integracji: health/status, korelacja, podstawowe metryki, kody błędów, incident communication i ścieżka eskalacji.

6. Im więcej elementów działa po stronie klienta, tym mniej „czysty” jest SaaS

Agent, terminal, konektor, gateway lub data plane po stronie klienta zwiększa customer-owned architecture. Wtedy potrzebna jest zgodność wersji, model upgrade’u, wsparcie OS/runtime, wymagania sieciowe, telemetria i rollback. Nie wolno nadal oceniać rozwiązania tak, jakby było wyłącznie zdalną stroną WWW.

7. Exit strategy jest wymaganiem architektonicznym

Vendor lock-in nie oznacza, że należy unikać usług zarządzanych. Oznacza, że trzeba wiedzieć, które elementy są trudno przenośne i co stanie się przy wyjściu. Dla krytycznej usługi potrzebne są format danych, kompletność eksportu, czas udostępnienia, sposób usunięcia kopii oraz wygaszenie integracji i tożsamości.

Decision rule

Nie pytaj: „czy znamy architekturę dostawcy?”. Pytaj: „czy znamy wszystkie granice, ryzyka i zachowania, za które odpowiadamy albo od których zależymy — i czy mamy dla nich dowód?”.

Od pytania do dowodu

Fikcyjny przykład: wymagany przez biznes RTO cztery godziny obejmuje kanał klienta, IAM, SaaS i integrację. Sama deklaracja odtworzenia bazy dostawcy nie potwierdza tego celu. Uzgodnij zakres, właścicieli, scenariusz próby, punkt rozpoczęcia pomiaru i warunek końca. Cztery godziny nie są uniwersalnym wymaganiem.

Dla danych przetestuj eksport i możliwość odczytania go poza usługą. Dla dostępu sprawdź odebranie roli, aktywną sesję i uprzywilejowany dostęp wsparcia. Dla integracji przeanalizuj brak odpowiedzi, limity i wersję kontraktu. Zapisz wynik, wersję usługi oraz niewiadome. Dobierz zakres sprawdzenia do krytyczności procesu; lista dokumentów nie zastępuje decyzji właściciela ryzyka.

Źródła i metoda

Źródła pierwotne sprawdzone 11.10.2026: Azure: zasady projektowania SaaS oraz metodyka projektowania. Wyjaśniają zasady odpowiedzialności i projektowania usługi; nie potwierdzają właściwości konkretnego dostawcy. Lista siedmiu obszarów i macierz odpowiedzialność → wymaganie → dowód są autorską syntezą ArchitectMentor. Materiał przygotowany z pomocą AI.

Przećwicz decyzję · Antywzorzec · Całe wydanie