Przegląd architektury oprogramowania: architektura nie ma jakości bez listy zmian

Potrzebujesz niezależnego architekta do przeglądu systemu? Poznaj nasze usługi Staff Augmentation.

Zobacz też: Architektura monolityczna vs mikroserwisy: przewodnik oraz Modernizacja architektury IT: staff augmentation vs outsourcing

Przegląd architektury w typowej polskiej organizacji wygląda tak: zespół zewnętrzny dostaje dostęp do repozytorium, spędza trzy dni na rozmowach, po dwóch tygodniach przysyła czterdziestostronicowy raport, w którym skalowalność dostaje trzy na pięć, bezpieczeństwo cztery, a utrzymywalność dwa i pół. Raport trafia do dyrektora technicznego. Dyrektor techniczny czyta streszczenie zarządcze, kiwa głową, zapisuje w planie „poprawa utrzymywalności” i nic się nie dzieje.

Nie dzieje się nic nie dlatego, że raport był zły. Nie dzieje się nic dlatego, że „utrzymywalność dwa i pół” nie jest informacją, na podstawie której da się cokolwiek zdecydować. Nie mówi, ile kosztuje, czego dotyczy ani co się stanie, jeśli tego nie ruszycie. Jest oceną szkolną wystawioną systemowi, który nie zdaje egzaminu, tylko ma wykonać konkretną pracę.

Teza tego przewodnika brzmi i można się z nią spierać: architektura nie ma jakości w oderwaniu od listy zmian, których się od niej oczekuje, więc jedyny przegląd zmieniający decyzje wycenia koszt konkretnych, nazwanych zmian z najbliższych osiemnastu miesięcy — a nie ocenia właściwości w skali od jednego do pięciu. Ta sama architektura, która jest znakomita dla zespołu planującego utrzymanie funkcjonalności i optymalizację kosztów, może być fatalna dla zespołu, który za osiem miesięcy ma wpiąć system do nowego kanału sprzedaży. Ocena bez listy zmian jest oceną bez pytania.

Kontrargument jest mocny i trzeba go postawić uczciwie: istnieją właściwości, które są dobre lub złe niezależnie od planów — system podatny na wyciek danych jest podatny bez względu na to, co macie w planie na przyszły rok, a rozwiązanie, które przewraca się przy podwojeniu ruchu, jest kruche niezależnie od tego, czy podwojenie nastąpi. Odpowiedź: to prawda, ale te właściwości też są mierzalne wyłącznie wobec konkretnych scenariuszy. „Bezpieczny” nie znaczy nic, dopóki nie powiecie, przed kim i przed czym; „skalowalny” nie znaczy nic bez liczby. Scenariusz zagrożenia i scenariusz obciążenia to również pozycje na liście zmian — po prostu takie, których nie planujecie, a przed którymi się zabezpieczacie. Metoda się nie zmienia, zmienia się źródło pozycji na liście.

Dlaczego przeglądy architektury kończą się raportem, którego nikt nie czyta?

Bezpośrednia przyczyna jest prosta: raport nie zawiera liczby, którą dałoby się wstawić do budżetu. Zawiera oceny, rekomendacje i priorytety, ale nie zawiera odpowiedzi na jedyne pytanie, jakie zada osoba decydująca o pieniądzach — ile to kosztuje i co się stanie, jeśli tego nie zrobimy.

Głębsza przyczyna leży w formacie. Checklista jest wygodna dla wykonawcy przeglądu, bo daje powtarzalny produkt i pozwala pracować bez głębokiego wejścia w kontekst biznesowy. Sześć wymiarów, po kilkanaście pytań w każdym, punktacja, wykres radarowy. Taki przegląd da się sprzedać, wykonać i rozliczyć niezależnie od tego, czy ktokolwiek z biznesu poświęcił mu godzinę. To jest właśnie źródło problemu, a nie jego objaw: format, który nie wymaga obecności biznesu, nie może wyprodukować wyceny biznesowej.

Warto przy tym zauważyć, że branża wiedziała to wcześniej i cofnęła się z lepszej pozycji. Metody oceny architektury oparte na scenariuszach — czyli takie, w których uczestnicy najpierw formułują konkretne przyszłe zdarzenia, a potem sprawdzają, jak architektura na nie odpowiada — są opisane i stosowane od przełomu wieków, z metodą ATAM z Software Engineering Institute jako najbardziej znanym przykładem. Nie wyparły checklisty dlatego, że wymagają czegoś kosztownego: obecności ludzi z biznesu przez dwa dni i gotowości do powiedzenia na głos, czego naprawdę oczekuje się od systemu. Checklista tego nie wymaga i dlatego wygrała.

Trzecia przyczyna jest organizacyjna. Raport oceniający właściwości nie ma adresata. „Utrzymywalność dwa i pół” nie jest niczyim zadaniem. Wycena „wpięcie nowego kanału sprzedaży kosztuje na obecnej architekturze czternaście tygodni, z czego dziewięć to przebudowa warstwy integracyjnej” ma adresata natychmiast, bo ktoś odpowiada za ten kanał i ma na niego termin.

Co konkretnie znaczy, że architektura nie ma jakości bez listy zmian?

Weźmy dwa systemy o identycznej strukturze: monolit z jedną bazą danych, obsługujący sprzedaż i rozliczenia, z warstwą integracyjną zbudowaną punkt do punktu.

Dla organizacji A plan na osiemnaście miesięcy brzmi: utrzymać funkcjonalność, obniżyć koszt infrastruktury o piętnaście procent, zamknąć zaległości w bezpieczeństwie. Dla tej organizacji opisana architektura jest bardzo dobra. Jest tania w utrzymaniu, ma jedno miejsce wdrożenia, jeden model danych i zespół, który zna ją na wylot. Podział na usługi kosztowałby rok pracy i pogorszyłby wszystkie trzy cele.

Dla organizacji B plan brzmi: wpiąć trzy nowe kanały sprzedaży, otworzyć dane rozliczeniowe dla partnerów przez interfejs programistyczny i wydzielić spółkę zależną, która ma korzystać z części systemu. Dla tej organizacji ta sama architektura jest kosztowna, bo każdy z tych trzech celów wymaga rozcięcia współdzielonego modelu danych, a integracje punkt do punktu trzeba by mnożyć.

Ta sama struktura, dwie przeciwne oceny. Nie dlatego, że oceniający się pomylił, tylko dlatego, że „jakość architektury” bez podanego zastosowania nie jest wielkością, która istnieje. To jest dokładnie ta sama pomyłka kategorialna, co pytanie, czy narzędzie jest dobre, bez powiedzenia, do czego.

Praktyczna konsekwencja jest dwojaka. Po pierwsze, przegląd trzeba zaczynać od listy zmian, a nie od diagramu. Po drugie, dwa przeglądy tego samego systemu wykonane dla różnych planów mogą dać przeciwne rekomendacje i to nie jest sprzeczność, tylko poprawny wynik.

Skąd wziąć listę zmian, jeśli firma nie ma planu na osiemnaście miesięcy?

Zarzut brzmi rozsądnie i pada na każdym warsztacie: większość organizacji nie ma spisanego planu na tak długi okres, a to, co jest spisane, dezaktualizuje się w kwartał. Odpowiedź jest praktyczna: nie potrzebujecie planu, potrzebujecie listy kandydatów na zmiany, a ona istnieje zawsze, tylko rozproszona po czterech miejscach.

Zobowiązania z datą. Zmiany regulacyjne, wygasające umowy licencyjne, kończące się wsparcie producenta, terminy kontraktowe wobec klientów. To jest najpewniejsza część listy, bo daty są narzucone z zewnątrz i nie podlegają negocjacji wewnętrznej.

Rejestr niezrealizowanych żądań biznesu. Rzeczy, o które biznes prosił i usłyszał „to za drogie” albo „to nie jest teraz priorytet”. Ta lista jest złotem, bo zawiera dokładnie te zmiany, których koszt architektura już raz podniosła do poziomu odmowy. Warto wyciągnąć ostatnie dwa lata takich odmów.

Trendy w danych operacyjnych. Wolumen transakcji, liczba użytkowników, rozmiar bazy, czas wykonania najdłuższych operacji. Ekstrapolacja na osiemnaście miesięcy daje scenariusze obciążenia, które nie wymagają niczyjej deklaracji.

Scenariusze zagrożeń i awarii. To są zmiany, których nie planujecie, ale na które architektura musi odpowiadać: utrata jednego z komponentów, kompromitacja poświadczeń, niedostępność zewnętrznego dostawcy, konieczność odtworzenia danych z określonego momentu.

Jak prowadzić warsztat, żeby biznes mówił o zmianach, a nie o życzeniach

Warsztat pierwszego dnia psuje się zwykle w jeden z dwóch sposobów. Albo biznes wymienia życzenia bez horyzontu i bez skali („chcielibyśmy mieć lepszą analitykę”), albo milknie i pozwala mówić zespołowi technicznemu. Trzy zabiegi proceduralne wystarczają, żeby tego uniknąć.

Pierwszy: zacznijcie od zobowiązań z datą, nie od pomysłów. Kiedy na tablicy stoi już sześć pozycji z terminami narzuconymi z zewnątrz, rozmowa ma ustalony format i kolejne propozycje same przybierają tę samą postać.

Drugi: wymuszajcie liczbę i termin przy każdej pozycji, natychmiast, na głos. Pozycja bez liczby wraca do zgłaszającego z jednym pytaniem — „ilu, do kiedy”. Zwykle po dwóch, trzech takich zwrotach reszta sali sama zaczyna podawać liczby. Pozycje, dla których nikt nie potrafi podać skali nawet z grubsza, nie są planem, tylko nastrojem, i nie wchodzą na listę.

Trzeci: poproście o pozycje, których nie chcecie. Pytanie „czego ten system na pewno nie będzie robił w ciągu osiemnastu miesięcy” jest niewygodne i dlatego wartościowe — odpowiedzi pozwalają wykluczyć całe klasy modyfikacji, które zespół techniczny nosi w głowie jako oczywiste. Wykluczenie kosztownej przebudowy, której nikt nie potrzebuje, jest tak samo dobrym wynikiem przeglądu jak wskazanie tej, która się zwraca.

Zebranie tych czterech źródeł zajmuje jeden dzień pracy analityka i daje zwykle od dwudziestu do czterdziestu kandydatów. Do przeglądu wybiera się z nich od ośmiu do dwunastu — te o najwyższym iloczynie prawdopodobieństwa i wpływu. Dwanaście dobrze opisanych scenariuszy to więcej, niż zdąży się rzetelnie wycenić w pięciodniowym przeglądzie.

Jak wycenić koszt zmiany zamiast oceniać właściwość?

Metoda ma cztery kroki i jest na tyle prosta, że po jednym przeglądzie zespół potrafi ją powtórzyć samodzielnie. Na tym polega jej wartość: przegląd, którego nie da się powtórzyć bez wynajmowania tych samych ludzi, jest usługą, a nie zdolnością organizacji.

Krok 1 — opis scenariusza w kategoriach obserwowalnych. Nie „lepsza integracja”, tylko „nowy partner przesyła zamówienia własnym formatem, wolumen do pięciu tysięcy dziennie, wymagane potwierdzenie w czasie poniżej dwóch sekund”. Scenariusz, którego nie da się jednoznacznie ocenić jako zrealizowany albo nie, nie nadaje się do wyceny.

Krok 2 — wyznaczenie punktów dotknięcia. Które moduły, tabele, kontrakty interfejsów i procesy wdrożeniowe trzeba zmienić, żeby scenariusz się zrealizował. To jest właściwa praca architekta i tutaj przegląd wygrywa albo przegrywa. Wynik zapisuje się jako listę, nie jako opis.

Krok 3 — wycena w tygodniach zespołu, z rozbiciem. Ile z tego to praca nowa, ile to przebudowa istniejącego kodu, ile to migracja danych, ile to testy regresji. Rozbicie ma znaczenie, bo pozycja „przebudowa istniejącego kodu” jest tą, którą realnie obniża się przez zmiany architektoniczne — pozostałe trzy są w dużej mierze nieredukowalne.

Krok 4 — wycena wariantu z modyfikacją architektury. Ile kosztowałaby zmiana strukturalna, która obniża koszt tego i sąsiednich scenariuszy, i przy ilu scenariuszach z listy ta zmiana się zwraca. To jest jedyne miejsce, w którym rekomendacja architektoniczna zyskuje uzasadnienie liczbowe: nie „warto wydzielić warstwę integracyjną”, tylko „wydzielenie warstwy integracyjnej kosztuje siedem tygodni i obniża koszt czterech z dwunastu scenariuszy łącznie o dziewiętnaście tygodni”.

Przykład wyceny jednego scenariusza

Scenariusz: „nowy partner przesyła zamówienia w swoim formacie, do pięciu tysięcy dziennie, potwierdzenie poniżej dwóch sekund”.

Punkty dotknięcia ustalone trzeciego dnia przeglądu: moduł przyjmowania zamówień, walidacja, mapowanie na wewnętrzny model zamówienia, tabela zamówień ze współdzielonym kluczem naturalnym, proces asynchronicznej rezerwacji stanów, komponent powiadamiania oraz konfiguracja wdrożeniowa. Siedem miejsc.

Wycena w wariancie „na obecnej architekturze”: praca nowa — trzy tygodnie na adapter formatu i walidację; przebudowa istniejącego kodu — sześć tygodni, w całości na rozplątanie mapowania na wewnętrzny model, bo obecny model zakłada jeden kanał i jedną numerację; migracja danych — tydzień; testy regresji — cztery tygodnie, bo dotknięta tabela jest czytana przez rozliczenia i przez raportowanie. Razem czternaście tygodni, z czego dziesięć to koszt wynikający ze struktury, a nie z samego wymagania.

Wariant z modyfikacją: rozcięcie współdzielonego modelu zamówień, wycenione na siedem tygodni. Po nim ten sam scenariusz kosztuje sześć tygodni, ponieważ przebudowa mapowania znika, a testy regresji spadają z czterech tygodni do półtora, bo zmiana przestaje dotykać rozliczeń.

Rachunek dla jednego scenariusza wychodzi na remis: czternaście tygodni wobec siedmiu plus sześciu, czyli trzynastu. Sens pojawia się dopiero na całej liście — ta sama modyfikacja obniża koszt trzech innych scenariuszy o łącznie osiemnaście tygodni. I to jest właśnie informacja, której nie da się wyprodukować, oceniając „utrzymywalność” w skali od jednego do pięciu: modyfikacja architektoniczna prawie nigdy nie zwraca się na pierwszej zmianie i prawie zawsze zwraca się na czwartej.

Kluczowa uwaga metodyczna: wyceny są zgrubne i mają być zgrubne. Dokładność rzędu ±40% w tygodniach wystarcza do podjęcia decyzji o kolejności, a pogoń za dokładnością ±10% zamienia przegląd w projekt analityczny na kwartał. Jeśli decyzja zmienia się przy błędzie wyceny czterdziestoprocentowym, to znaczy, że dwa warianty są równoważne i wybór należy oprzeć na innym kryterium, na przykład na dostępności kompetencji.

Co z bezpieczeństwem i dostępnością — czy tu też potrzebna jest lista?

Tak, i ta sekcja jest odpowiedzią na najpoważniejszy zarzut wobec tezy tego przewodnika.

Właściwości takie jak bezpieczeństwo, dostępność czy odporność na awarie rzeczywiście nie zależą od waszej mapy produktu. Zależą jednak od scenariuszy, i to bardziej niż cokolwiek innego w architekturze. Zdanie „system jest bezpieczny” nie ma wartości informacyjnej, dopóki nie powie się, przed jakim przeciwnikiem, o jakich możliwościach i przy jakim modelu zaufania. Zdanie „system jest wysoko dostępny” nie ma wartości, dopóki nie powie się, ile minut niedostępności rocznie jest akceptowalne i dla którego procesu.

Praktyczny wniosek jest taki, że scenariusze zagrożeń wchodzą na tę samą listę i przechodzą przez tę samą czterokrokową wycenę, tylko z inną jednostką wyniku. Zamiast „ile tygodni kosztuje ta zmiana” pytacie „ile tygodni kosztuje doprowadzenie systemu do stanu, w którym ten scenariusz nie kończy się szkodą” — i ta liczba jest tak samo budżetowalna.

Przykłady scenariuszy, które w polskich systemach warto mieć na liście niezależnie od branży: kompromitacja poświadczeń jednego z integratorów zewnętrznych; konieczność odtworzenia stanu bazy sprzed dwunastu godzin bez utraty transakcji przyjętych w międzyczasie; niedostępność dostawcy usługi płatniczej przez cztery godziny w szczycie; wyciek pliku eksportowego zawierającego dane osobowe; oraz odejście jedynej osoby, która potrafi wykonać wdrożenie produkcyjne. Ostatni scenariusz bywa wyśmiewany jako niearchitektoniczny, a jest jednym z najczęściej realizujących się i najkosztowniejszych.

Które zmiany regulacyjne trzeba w Polsce wpisać na listę z datą?

To jest część listy, której nie trzeba negocjować z biznesem, bo daty są narzucone. Dla polskiej organizacji w 2026 roku warto sprawdzić co najmniej cztery obszary — każdy z nich generuje konkretne, wyceniane zmiany w architekturze integracyjnej, w logowaniu i w obsłudze danych.

Krajowy System e-Faktur. Obowiązek wystawiania faktur ustrukturyzowanych wchodzi etapami w 2026 roku, z wcześniejszym terminem dla największych podmiotów. Dla architektury oznacza to nie tylko integrację z zewnętrznym systemem, ale też zmianę modelu danych faktury, obsługę identyfikatorów nadawanych przez system, tryb awaryjny na wypadek niedostępności i archiwizację. Przegląd architektury przeprowadzony w 2026 roku bez wyceny tego scenariusza pomija największą wymuszoną zmianę integracyjną tego roku.

Rozporządzenie DORA. Dla podmiotów sektora finansowego i ich dostawców przepisy o operacyjnej odporności cyfrowej stosuje się od 17 stycznia 2025 roku. Konsekwencje architektoniczne są konkretne: rejestr umów z zewnętrznymi dostawcami usług teleinformatycznych, wymogi dotyczące testowania odporności, obowiązki zgłoszeniowe przy poważnych incydentach oraz warunki wyjścia od dostawcy. Każdy z tych elementów przekłada się na wymagania wobec logowania, separacji komponentów i możliwości odtworzenia.

Dyrektywa NIS2 i jej krajowa transpozycja. Rozszerza katalog podmiotów objętych obowiązkami cyberbezpieczeństwa daleko poza sektor finansowy — obejmuje między innymi produkcję, gospodarkę odpadami, usługi pocztowe i część sektora cyfrowego. Skutki architektoniczne dotyczą przede wszystkim zarządzania ryzykiem łańcucha dostaw, obsługi incydentów i uwierzytelniania.

Akt o sztucznej inteligencji. Jeżeli w systemie działa jakikolwiek komponent oparty na modelach, harmonogram stosowania rozporządzenia 2024/1689 generuje wymagania dotyczące logowania, nadzoru człowieka i dokumentacji, które są wymaganiami architektonicznymi, a nie tylko formalnymi.

Wspólna cecha tych czterech pozycji: mają daty, mają adresata i nie da się ich odłożyć decyzją wewnętrzną. Dlatego stanowią najlepszy punkt startowy dla organizacji, która twierdzi, że nie ma planu na osiemnaście miesięcy.

Jak przygotować materiał, żeby przegląd nie zamienił się w archeologię?

Największym pojedynczym pożeraczem czasu w przeglądzie jest ustalanie stanu faktycznego. Cztery rzeczy przygotowane przed startem oszczędzają zwykle półtora dnia z pięciu.

Wykaz repozytoriów i właścicieli. Z zaznaczeniem, które są aktywne, a które tylko żyją. W średniej wielkości organizacji różnica między listą deklarowaną a rzeczywistą bywa dwukrotna.

Konfiguracja wdrożeniowa i topologia środowisk. To jest źródło prawdy o tym, co gdzie działa. Diagram z prezentacji jest źródłem prawdy o tym, co miało działać.

Statystyka zmian z repozytorium za ostatnie dwanaście miesięcy. Liczba zmian na moduł i liczba różnych autorów na moduł. Moduły o wysokiej częstotliwości zmian i wielu autorach są dokładnie tymi, w których koszt zmiany architektonicznej się zwraca — a moduł, którego nikt nie dotykał od dwóch lat, jest złym miejscem na inwestycję niezależnie od tego, jak brzydki jest jego kod.

Lista integracji zewnętrznych z właścicielem kontraktu. Zwykle najkrótszy dokument i zwykle ten, którego brakuje. Integracje są miejscem, w którym materializuje się większość kosztu zmiany.

Czego nie warto przygotowywać: aktualizacji dokumentacji architektury. Aktualizowanie dokumentu przed przeglądem to praca wykonana dwa razy, bo diagram powstający w trakcie przeglądu i tak będzie dokładniejszy. Lepiej wejść w przegląd z nieaktualnym dokumentem i uczciwie to powiedzieć.

Jak wygląda pięciodniowy przegląd dzień po dniu?

Poniższy rozkład sprawdza się dla systemu średniej wielkości — od kilkuset tysięcy do około dwóch milionów linii kodu, od trzech do dziesięciu integracji zewnętrznych.

Dzień 1 — lista zmian. Warsztat z udziałem biznesu, cztery godziny. Produktem jest od ośmiu do dwunastu scenariuszy opisanych w kategoriach obserwowalnych, uszeregowanych. Po południu: przegląd materiału przygotowawczego i rekonstrukcja topologii.

Dzień 2 — mapa systemu. Sesje z inżynierami, rysowanie rzeczywistej struktury i przepływów danych. Produktem jest jeden diagram, który wszyscy uczestnicy uznają za prawdziwy. Zaskakująco często ten diagram jest już wartością samą w sobie, bo okazuje się, że dwie części zespołu miały różny obraz tego samego systemu.

Dzień 3 — punkty dotknięcia. Dla każdego scenariusza: które elementy trzeba ruszyć. Praca w parach, architekt zewnętrzny z inżynierem znającym obszar. To najbardziej pracochłonny dzień i ten, którego nie da się skrócić.

Dzień 4 — wycena i warianty. Tygodnie zespołu dla każdego scenariusza w wariancie „na obecnej architekturze” oraz dla dwóch, trzech modyfikacji strukturalnych, które obniżają koszt wielu scenariuszy naraz.

Dzień 5 — decyzje. Przekazanie wyniku osobom decydującym, w formacie macierzy kosztu zmiany, i podjęcie trzech, czterech decyzji na miejscu. Jeżeli piąty dzień kończy się bez decyzji, przegląd zamienia się w raport i wraca do punktu wyjścia z pierwszego akapitu tego tekstu.

Poniższa tabela jest formatem wyniku, nie modelem dojrzałości. Warto ją wypełnić na żywo, na projektorze, w obecności osób decydujących — to jest jedyny znany mi sposób, żeby decyzja zapadła tego samego dnia.

Scenariusz z listy 18 miesięcy	Koszt na obecnej architekturze	Koszt po modyfikacji strukturalnej	Modyfikacja, która to obniża	Ryzyko przy zaniechaniu	Decyzja
Integracja z KSeF, termin narzucony	9 tygodni	6 tygodni	Wydzielenie warstwy integracyjnej	Brak zgodności w terminie ustawowym	Wykonać, wariant z modyfikacją
Trzeci kanał sprzedaży	14 tygodni	6 tygodni	Rozcięcie współdzielonego modelu zamówień	Utrata okna rynkowego	Wykonać modyfikację najpierw
Otwarcie danych dla partnerów	11 tygodni	5 tygodni	Wydzielenie warstwy integracyjnej	Przychód odroczony o rok	Objęte modyfikacją powyżej
Podwojenie wolumenu transakcji	4 tygodnie	4 tygodnie	Brak — koszt nieredukowalny	Degradacja czasu odpowiedzi	Wykonać bez modyfikacji
Kompromitacja poświadczeń integratora	6 tygodni	3 tygodnie	Centralne zarządzanie sekretami	Incydent z obowiązkiem zgłoszenia	Wykonać, priorytet wysoki
Odejście jedynej osoby od wdrożeń	3 tygodnie	1 tydzień	Automatyzacja i opis procesu wdrożenia	Zatrzymanie wydań na kwartał	Wykonać natychmiast, najtańsza pozycja

Wiersz ostatni ilustruje rzecz, którą macierz pokazuje, a punktacja właściwości ukrywa: najtańsza pozycja o najwyższym ryzyku prawie nigdy nie jest tą, o której mówi się na spotkaniach architektonicznych.

Jak zapisać wynik, żeby dało się nim zarządzać po przeglądzie?

Wynik przeglądu żyje w organizacji trzy tygodnie, jeśli jest raportem, i osiemnaście miesięcy, jeśli jest wpięty w bieżący proces. Trzy nawyki decydują o tym, który wariant się zdarzy.

Rejestr decyzji architektonicznych. Każda decyzja z piątego dnia zapisana jako krótki dokument: kontekst, rozważane opcje, wybór, konsekwencje. Kilkanaście zdań, nie kilkanaście stron. Wartość ujawnia się przy następnym przeglądzie, kiedy zamiast rekonstruować, dlaczego coś zrobiono tak, a nie inaczej, po prostu się to czyta.

Macierz kosztu zmiany jako dokument żywy. Aktualizowana przy każdej zmianie planu, nie raz na rok. Aktualizacja jednego wiersza zajmuje kwadrans, jeśli metoda jest w organizacji znana.

Powiązanie z planowaniem budżetu. Pozycje z macierzy, które zapadły jako decyzje, trafiają do planu z tą samą wyceną, z którą zapadły. Jeżeli wycena z przeglądu i wycena w planie to dwie różne liczby powstałe w dwóch różnych procesach, przegląd nie miał wpływu na nic.

Dodatkowa uwaga o wskaźnikach: kuszące jest wprowadzenie miary „jakości architektury” jako liczby śledzonej w czasie. Nie polecam. Taka miara natychmiast staje się celem i przestaje być miarą, a poza tym mierzy coś, co — jak argumentuje ten przewodnik — nie istnieje w oderwaniu od listy zmian. Śledźcie zamiast tego jedną wielkość: średni koszt scenariusza z listy, w tygodniach. Jeżeli spada, architektura się poprawia w jedynym sensie, który ma znaczenie.

Co zrobić, gdy wynik brzmi „nie ruszać”

Najbardziej niewygodny wynik przeglądu wygląda tak: żadna z rozważanych modyfikacji strukturalnych nie zwraca się na waszej liście scenariuszy, a wszystkie pozycje należy wykonać na obecnej architekturze. Zespół techniczny odbiera to jako porażkę, bo pracował dwa tygodnie i nie dostał zgody na przebudowę, której chciał.

To jest jednak wynik pełnoprawny i zwykle najbardziej wartościowy finansowo. Oznacza, że organizacja właśnie uniknęła wydania kilkuset tysięcy złotych na modyfikację, która nie miała pokrycia w planie. Przebudowa architektury bez pokrycia w liście zmian jest kosztem, który materializuje się natychmiast, i korzyścią, która materializuje się nigdy — bo scenariusze, dla których byłaby korzystna, nie wystąpią.

Warto ten wynik zapisać wprost i z datą, razem z listą, na której zapadł. Przy następnym przeglądzie, za rok, lista będzie inna i ta sama modyfikacja może się zwrócić z nawiązką. Zapis „sprawdzone przy tej liście, nie zwraca się” chroni przed dwiema odwrotnymi patologiami naraz: przed powtarzaniem tej samej analizy co pół roku i przed traktowaniem odmowy sprzed roku jako rozstrzygnięcia obowiązującego wiecznie.

Kiedy przegląd powinien wykonać ktoś z zewnątrz?

Własny zespół zna system nieporównanie lepiej i wykona kroki drugi i trzeci szybciej niż ktokolwiek z zewnątrz. Ma jednak dwie systematyczne wady, których nie da się usunąć dobrą wolą.

Pierwsza to obrona wcześniejszych decyzji. Osoba, która trzy lata temu wybrała rozwiązanie, ma trudność w wycenieniu scenariusza tak, żeby wynik pokazał, że wybór był kosztowny. To nie jest kwestia uczciwości, tylko normalnego mechanizmu poznawczego.

Druga to brak punktu odniesienia. Zespół pracujący od lat na jednym systemie nie wie, czy czternaście tygodni na wpięcie kanału sprzedaży to dużo, czy mało, bo nie widział innych systemów w tej samej klasie.

Rozsądny układ jest mieszany i tańszy, niż się wydaje: architekt z zewnątrz prowadzi metodę i wycenia, inżynierowie z zespołu dostarczają wiedzę o systemie. Zewnętrzna obecność potrzebna jest przez pięć dni przeglądu plus dwa dni na przygotowanie, a nie przez cały kwartał. Przy stawkach obserwowanych na polskim rynku dla doświadczonego architekta w modelu kontraktowym to jest wydatek rzędu kilkunastu tysięcy złotych — wobec wycenianych w tygodniach decyzji o wartości setek tysięcy jest to koszt marginalny, i to jest zwykle najmocniejszy argument w rozmowie o budżecie przeglądu.

Jakie anty-wzorce widać najczęściej w polskich systemach?

Cztery poniższe pojawiają się w naszej praktyce częściej niż pozostałe i wszystkie mają wspólną cechę: są tanie w powstawaniu i drogie w usuwaniu.

Współdzielona baza jako interfejs integracyjny. Dwa systemy czytają z tych samych tabel, bo tak było najszybciej. Skutek: każda zmiana schematu jest zmianą w dwóch systemach naraz, a granica odpowiedzialności nie istnieje. To jest najczęstszy powód, dla którego wycena „prostej” zmiany wychodzi trzykrotnie wyżej niż intuicja.

Integracje punkt do punktu bez rejestru. Każda z osobna rozsądna, wszystkie razem tworzą sieć, której nikt nie widzi w całości. Pierwszym produktem przeglądu bywa odkrycie integracji, o której nie wiedział nikt z obecnych.

Logika biznesowa w procedurach składowanych i w zadaniach wsadowych. Trudna do testowania, niewidoczna dla narzędzi analizujących kod aplikacji, i zwykle bez właściciela. W wycenie scenariuszy ta warstwa jest źródłem największych niespodzianek.

Środowisko produkcyjne różniące się od testowego w sposób nieudokumentowany. Skutkuje tym, że wycena testów regresji jest zawsze zaniżona, bo część problemów ujawnia się dopiero na produkcji.

Żaden z tych czterech wzorców nie jest sam w sobie powodem do przebudowy. Powodem jest dopiero to, że podnoszą koszt konkretnych scenariuszy z waszej listy — i przegląd ma to pokazać liczbą, a nie nazwać po imieniu.

Jakich błędów unikać przy samym przeglądzie?

Zaczynanie od diagramu. Diagram bez listy zmian prowadzi do dyskusji o elegancji struktury. Lista zmian bez diagramu prowadzi do jego narysowania. Kolejność ma znaczenie.

Przegląd bez udziału biznesu. Wtedy scenariusze wymyśla zespół techniczny, a wymyśla je zwykle jako te, które chciałby zrealizować. To jest przegląd potwierdzający istniejące plany techniczne.

Wycena zbyt dokładna. Pogoń za dokładnością zamienia pięć dni w kwartał i nie zmienia żadnej decyzji.

Rekomendacje bez kosztu zaniechania. Każda rekomendacja musi mieć drugą stronę: co się stanie, jeśli tego nie zrobimy. Bez tego wszystkie rekomendacje wyglądają na jednakowo pilne, czyli na jednakowo odkładalne.

Przegląd kończący się dokumentem zamiast decyzjami. Sprawdzian jest prosty: ile decyzji zapadło w dniu przekazania wyniku. Zero oznacza, że format był zły.

Mylenie przeglądu architektury z audytem bezpieczeństwa. To dwie różne prace o różnych metodach i różnych kompetencjach. Przegląd architektury wycenia scenariusze zagrożeń, ale nie zastępuje testów penetracyjnych ani analizy podatności. Więcej o kosztach tej drugiej pracy piszemy w tekście o cenniku testów bezpieczeństwa.

Jak ARDURA Consulting prowadzi przeglądy architektury?

Pracujemy metodą opisaną powyżej i w układzie mieszanym: nasz architekt prowadzi proces i odpowiada za wycenę, wasi inżynierowie dostarczają wiedzę o systemie. Standardowy zakres to dwa dni przygotowania i pięć dni przeglądu, zakończone macierzą kosztu zmiany i sesją decyzyjną z osobami odpowiadającymi za budżet.

Świadomie nie zostawiamy po sobie czterdziestostronicowego raportu. Zostawiamy jeden diagram, który zespół uznaje za prawdziwy, wypełnioną macierz kosztu zmiany, komplet rejestrów decyzji z sesji piątego dnia i opis metody na tyle prosty, żeby kolejny przegląd zespół przeprowadził bez nas. Przegląd, po którym organizacja nie potrafi powtórzyć wyceny samodzielnie, jest usługą sprzedaną ponownie za rok, a nie zdolnością zbudowaną raz.

Jeżeli po przeglądzie okazuje się, że któraś z modyfikacji strukturalnych ma zostać wykonana, udostępniamy inżynierów w modelu Staff Augmentation lub Time & Materials — zwykle w składzie architekt plus dwóch, trzech programistów na okres wynikający z wyceny, bez konieczności powiększania etatów na stałe.

Najtańszy pierwszy krok, który możecie wykonać sami w tym tygodniu: zbierzcie z ostatnich dwóch lat wszystkie żądania biznesu, na które padła odpowiedź „to zbyt kosztowne”. Ta lista jest gotowym szkieletem scenariuszy i zwykle mówi o architekturze więcej niż jakikolwiek diagram.

Skontaktuj się z nami, jeśli chcesz przeprowadzić przegląd, który kończy się decyzjami, a nie raportem.