Warsztat decyzji · ArchitectMentor Weekly · 5–11.10.2026

Dostawca daje SaaS. Czy musisz znać jego architekturę?

Rozpoznaj ryzyko, podejmij decyzję i porównaj swój tok myślenia z analizą seniora. W wybranych ćwiczeniach zadasz też pytanie mentorowi AI.

CEL ĆWICZENIAOdróżnić szczegóły implementacyjne dostawcy od informacji potrzebnych do oceny odpowiedzialności, ryzyka i integracji SaaS.2 minuty lub warsztat z mentorem

01SCENARIUSZŚredni

Co wiemy?

Fikcyjny scenariusz edukacyjny

Organizacja rozważa zewnętrzną usługę SaaS do obsługi ważnego procesu transakcyjnego. Dostawca utrzymuje aplikację, bazę danych i infrastrukturę we własnym środowisku. Klient ma jednak zbudować własny kanał użytkownika, połączyć usługę z tożsamością organizacji, przekazywać część danych biznesowych i obsługiwać incydenty pierwszej linii.

Dostawca przekazał opis API, SLA oraz ogólną informację o bezpieczeństwie. Na pytanie o architekturę odpowiada: „To SaaS — szczegóły wewnętrznej implementacji są po naszej stronie”. Nie ma jeszcze jasnej informacji o granicach odpowiedzialności, lokalizacji i retencji danych, sposobie izolacji klientów, zależnościach krytycznych, procedurze awarii, RTO/RPO, telemetryce dostępnej klientowi ani mechanizmie zakończenia usługi i eksportu danych.

Biznes chce szybko zatwierdzić kierunek. Zespół techniczny dzieli się na dwa obozy: „bez pełnego diagramu dostawcy niczego nie zatwierdzamy” oraz „to SaaS, więc architektura dostawcy nas nie interesuje”.

Pytanie do Ciebie

Jaką decyzję podejmiesz na tym etapie? W 2–3 zdaniach wskaż potrzebne informacje, szczegóły pozostające po stronie dostawcy i dowód przed akceptacją.

Za co mentor ocenia odpowiedź?

Wynik jest wskazówką do nauki, nie oceną zawodowych kompetencji.

Granica odpowiedzialności
Informacje istotne dla decyzji
Dowód przed akceptacją

Zobacz pytania naprowadzające

Co kontroluje klient: kanał użytkownika, tożsamość, dane czy infrastrukturę dostawcy?
Jak sprawdzisz cały proces, gdy API odpowiada, lecz usługa biznesowa nie działa?
Które niewiadome można zamknąć kontraktem, testem odtwarzania lub eksportu?

Zacznij od wyboru albo od razu uzasadnij decyzję mentorowi. Wariant możesz zmienić w każdej chwili.

Nie wiem — pokaż wskazówkę

Połącz zakres odpowiedzialności z wymaganiem i dowodem.

03ANALIZA SENIORA

Porównaj tok rozumowania

Pełna analiza jest dostępna również bez oceny AI.

SaaS nie usuwa architektury — przesuwa granicę

Najważniejsza decyzja nie dotyczy tego, czy dostawca używa kontenerów, maszyn wirtualnych czy konkretnej bazy danych. Jeżeli klient nie zarządza tymi elementami i ich zmiana nie narusza uzgodnionego kontraktu, szczegóły mogą pozostać wewnętrzne.

Architekt klienta musi jednak rozumieć system, który powstaje na styku organizacji. Granica rozwiązania obejmuje nie tylko API, lecz także przepływ tożsamości, dane, konfigurację, kanały użytkownika, zależności, procedurę awarii, telemetrykę i operacje day-2.

Minimalny zestaw informacji przed decyzją

Service boundary i odpowiedzialność. Co dokładnie jest usługą? Kto odpowiada za endpoint klienta, IAM, konfigurację, dane, certyfikaty, integrację i pierwszą reakcję na incydent?
Dane. Gdzie są przetwarzane i przechowywane, jak długo, jak są separowane pomiędzy klientami, jak wygląda backup, eksport i usunięcie?
Tożsamość i dostęp. Jak działa federacja, role, uprzywilejowany dostęp dostawcy, audyt i odebranie dostępu?
NFR. Dostępność, wydajność, limity, RTO, RPO, maintenance windows, skalowanie oraz sposób mierzenia zobowiązań.
Failure model. Co obserwuje klient, kiedy usługa lub jej zależność zawodzi? Jakie są timeouty, retry, degradacja, komunikacja incydentowa i eskalacja?
Observability. Jakie metryki, logi, identyfikatory korelacyjne i statusy dostaje klient? Co pozwala odróżnić błąd po swojej stronie od awarii SaaS?
Lifecycle i exit. Jak zmieniają się API, jak wygląda wersjonowanie, eksport danych, okres przejściowy i zakończenie usługi?

Czego zwykle nie trzeba znać

Nie trzeba wymagać nazw każdego mikroserwisu, szczegółowej topologii klastra, konfiguracji każdego load balancera czy języka implementacji, jeśli nie wpływają na wymaganie, ryzyko, zgodność, kontrakt lub obowiązek klienta. Wyjątki powstają wtedy, gdy regulacja, bezpieczeństwo, customer-hosted data plane, dedykowany komponent w środowisku klienta albo wymaganie audytowe wprowadza dodatkową odpowiedzialność.

Jak zamknąć decyzję dowodami

Zamiast prosić tylko o „więcej dokumentacji”, zbuduj macierz odpowiedzialność → wymaganie → dowód. Przykładowo (wartość fikcyjna, wymagająca uzgodnienia): RTO 4 h → procedura odtworzenia + wynik regularnego testu; SSO → kontrakt federacji + test logowania/odebrania roli; izolacja danych → opis modelu izolacji + odpowiedni dowód bezpieczeństwa; exit → format eksportu + test próbnego eksportu.

Nie potrzebujesz pełnej mapy kuchni dostawcy. Musisz wiedzieć, co zamawiasz, gdzie kończy się jego odpowiedzialność, gdzie zaczyna Twoja i jak sprawdzisz, że granica działa.

Całe wydanie Weekly · Antywzorzec

POWIĄZANA WIEDZA