Metoda
Architektura na żądanie.
Metoda tej praktyki jest starsza niż ta strona i prostsza, niż brzmi: nakład architektoniczny jest kosztem, więc ponosimy go tylko tam, gdzie redukuje ryzyko, którego organizacja nie może sobie pozwolić ponieść. Resztę wysiłku oddajemy budowie działającego systemu. Wariant ciągły tej metody, architecture as a service, to nadzór architektoniczny kupowany wtedy, gdy pojawia się decyzja warta nadzoru, zamiast etatu, który musi się czymś wykazać.
Cztery reguły dawkowania
- 01
Proporcjonalnie do ryzyka
Miarą potrzebnej architektury jest koszt odwrócenia decyzji, nie rozmiar projektu. Granice systemów, model danych, tożsamość, integracje, to decyzje drogie w odwróceniu i one dostają analizę, zapis i przegląd. W banku oznaczało to pełny komitet architektury nad wymianą systemu centralnego; w budowie produktu, jeden rejestr decyzji i szkic granic na jednej stronie. Oba nakłady były właściwe, bo oba były proporcjonalne.
- 02
Ostatni odpowiedzialny moment
Decyzję odraczamy dotąd, aż dalsza zwłoka zaczęłaby odbierać opcje, bo najdroższe architektury powstają z odpowiedzi na pytania, których nikt jeszcze nie zadał. W praktyce wygląda to tak: fundamenty, których nie da się tanio dołożyć później, wchodzą od pierwszej migracji; funkcje czekają na dowód potrzeby; a każda odroczona decyzja ma zapisaną ścieżkę odwrotu, łącznie z wersjami zapasowymi zależności.
- 03
Architektura wykonywalna
Standard, którego nie sprawdza maszyna, jest opinią z dobrą frekwencją na spotkaniach. Model architektury trzymamy w repozytorium, walidacja zwraca kod błędu i działa jako bramka w pipeline, a odstępstwa istnieją wyłącznie jako dyspensy z datą wygaśnięcia. To jest to samo, co architektura ewolucyjna nazywa fitness functions, z tą różnicą, że u nas naprawdę zatrzymuje builda.
- 04
Minimalny artefakt: decyzja
Jeśli z całej dokumentacji architektonicznej ma zostać jedno, niech zostanie rejestr decyzji: kontekst, rozważane opcje, powody odrzucenia pozostałych. Prowadzimy też tabele build-vs-buy z werdyktem przy każdej odrzuconej opcji. Diagramy się dezaktualizują; powody decyzji nie.
Rodowód
Nie wymyśliliśmy tych reguł, złożyliśmy je z rzeczy sprawdzonych i nazwanych przez innych. Proporcjonalność do ryzyka to teza książki Just Enough Software Architecture George'a Fairbanksa. Architektura wykonywalna to fitness functions z Building Evolutionary Architectures Neala Forda i Rebekki Parsons. Rejestr decyzji w tej formie opisał Michael Nygard. Ostatni odpowiedzialny moment pochodzi z lean software development Mary i Toma Poppendiecków, a sylwetka architekta, który pisze kod zamiast oceniać go z góry, z eseju Martina Fowlera o architectus oryzus. Nasz wkład jest gdzie indziej: w dyscyplinie stosowania tych reguł w środowiskach, które zwykle uważają je za zbyt lekkie, w banku, w regulowanym fintechu, na hali produkcyjnej.
Przebieg
Nie ma dwóch identycznych zaangażowań, ale kolejność jest zwykle ta sama.
- 01
Rozmowa
Bez prezentacji i bez zobowiązań. Interesuje nas, co konkretnie boli i co się stanie, jeśli nic się nie zmieni. Jeśli po tej rozmowie widać, że nie jesteśmy właściwym adresem, mówimy to od razu.
- 02
Rozpoznanie
Kilka dni na zobaczenie stanu faktycznego: architektury, procesu albo kodu, zależnie od problemu. Rozmawiamy z ludźmi, którzy system utrzymują, nie tylko z tymi, którzy go zamawiali.
- 03
Diagnoza i kierunek
Raport, który da się przeczytać w zarządzie i w zespole technicznym: co jest ryzykiem, co można zostawić, co należy zrobić w jakiej kolejności i ile to mniej więcej kosztuje. Zawsze z opcjami, nie z jedną rekomendacją.
- 04
Wykonanie albo nadzór
Albo budujemy, albo prowadzimy decyzje przy zespole klienta. W obu przypadkach dokumentacja i rejestr decyzji powstają razem z pracą, a nie po niej.
- 05
Przekazanie
Runbooki, środowisko odtwarzalne z repozytorium i przegląd z zespołem, który przejmuje. Uznajemy zaangażowanie za udane wtedy, gdy da się je zakończyć bez szkody dla klienta.
AI w naszej pracy
Używamy agentów AI w codziennym wytwarzaniu oprogramowania, to jeden z powodów, dla których niewielka praktyka jest w stanie prowadzić kilkanaście produkcyjnych repozytoriów naraz. Obowiązuje przy tym dokładnie ta sama zasada, którą stosujemy u klientów: model proponuje, testy i deterministyczna walidacja orzekają, człowiek odpowiada za wynik. Specyfikacja i rejestr decyzji są źródłem prawdy, kod jest ich konsekwencją.