Dokumentacja architektury korporacyjnej jest nieaktualna w dniu publikacji, ponieważ jest kopią stanu, a nie jego źródłem. Governance, który nie ma mechanizmu potrafiącego odmówić, sprowadza się do spotkań i dobrej woli. Jedyne znane nam wyjście z obu tych problemów naraz jest nudne: model architektury żyje w repozytorium git, a jego reguły są wykonywalne i uruchamiane w CI.
Dlaczego dokumentacja rozjeżdża się z rzeczywistością
Powód nie jest kwestią dyscypliny zespołu. Dokument opisujący architekturę powstaje przez odczytanie stanu systemów i zapisanie go w innym formacie, a od momentu zapisu dwie kopie prawdy zmieniają się niezależnie. Diagram nie ma sposobu, by dowiedzieć się, że wczoraj wycofano usługę. Slajd nie potrafi zaprotestować, gdy nowy komponent podłączy się do bazy, do której nie powinien mieć dostępu. Rozjazd jest w tej konstrukcji wbudowany i żadna procedura aktualizacji go nie usunie, bo procedura konkuruje z terminami projektowymi i zawsze przegrywa.
Podobnie z governance. Architecture Review Board bez artefaktu, który da się sprawdzić maszynowo, rozstrzyga na podstawie tego, co przedstawiono na spotkaniu. Ustalenia lądują w notatce. Notatka nie ma żadnego kontaktu z pipeline'em, w którym powstaje system. Po roku organizacja ma zbiór trafnych decyzji, o których nikt nie wie, czy zostały wykonane, i to nie z powodu złej woli, lecz z braku miejsca, w którym niewykonanie byłoby widoczne.
Model w repozytorium zamiast dokumentu
Otwarty toolchain, który zbudowaliśmy, opiera się na jednym założeniu: model jest kodem, więc podlega tym samym rygorom co kod. Trzymamy go w git, w tekstowym DSL-u, który ma pull requesty, historię, blame i review. Rdzeń jest w całości deterministyczny, trójwarstwowy walidator, kompilator do formatu ArchiMate 3.2 Open Exchange XML walidowanego wobec XSD Open Group oraz generator widoków SVG. Całość obejmuje 19 „skills" pokrywających cykl define → document → govern → maintain, czyli także tę część, o której narzędzia do rysowania milczą: co się dzieje z modelem po tym, jak przestaje być nowy.
Wybór ArchiMate 3.2 i walidacji wobec oficjalnej schemy nie jest deklaracją przywiązania do standardu. Ma konkretny skutek: model daje się wyeksportować do innego narzędzia i daje się sprawdzić bez naszego narzędzia. Format, którego poprawność potwierdza tylko edytor, w którym powstał, jest formatem, z którego nie ma wyjścia, a architektura korporacyjna przetrwa kilka generacji narzędzi.
Dokumentację generujemy z modelu w kształcie klauzuli 6 normy ISO/IEC/IEEE 42010: rejestr interesariuszy wraz z ich troskami, portfel aplikacyjny z kwadrantami TIME, mapa zdolności, triage zmian. Kolejność jest tu istotna. Dokument nie jest artefaktem, który się utrzymuje, lecz wydrukiem stanu modelu na dany commit. Nieaktualna dokumentacja przestaje być możliwa, bo nie ma czego dezaktualizować, jest tylko model, który albo przechodzi walidację, albo nie.
Governance, który zwraca kod wyjścia
Najważniejsza właściwość tego narzędzia jest banalna: validate kończy się kodem wyjścia 1, kiedy model
narusza reguły. To wystarcza, żeby uruchomić je jako krok w CI, a to z kolei zmienia charakter zasady
architektonicznej. Zasada, która żywi się przypomnieniami, jest preferencją. Zasada, która potrafi
zatrzymać merge, jest bramką.
Na tym samym mechanizmie oparliśmy rejestr decyzji i rekordy zgodności. ADR-y leżą w repozytorium obok modelu, więc decyzja i jej skutek są w jednym miejscu i w jednej historii. Rekord zgodności nie jest polem tak/nie, ale werdyktem w sześciostopniowej skali, bo w praktyce architektonicznej „zgodne" i „niezgodne" nie wystarczają: bywa zgodne w części, zgodne z odstępstwem, nieocenione, nieaktualne. Skala, która to rozróżnia, jest jedyną, na której raport zdrowia mówi coś użytecznego.
Model utrzymujemy w dwóch strefach: staging i approved, z bramkowaną promocją między nimi. Powód jest
praktyczny. Bez tego rozdzielenia każda propozycja zmiany musi udawać, że jest już zatwierdzona, więc albo
governance blokuje eksplorację, albo eksploracja rozmywa governance. Dwie strefy pozwalają modelować
warianty swobodnie i wciąż mieć jeden stan, na który wolno się powoływać w decyzjach.
Standardy z cyklem życia, odstępstwa z datą wygaśnięcia
Baza standardów z wymuszanym cyklem życia rozwiązuje problem, który w większości organizacji jest nierozpoznany: standardy się nie kończą. Zapis powstaje, obowiązuje, przestaje mieć sens, ale formalnie nadal obowiązuje, więc zespoły uczą się go obchodzić, a przy okazji tracą szacunek do tych zapisów, które sens mają. Standard bez statusu i daty przeglądu z czasem szkodzi bardziej niż jego brak.
Odstępstwa traktujemy jeszcze ostrożniej: każde ma datę wygaśnięcia i nie da się go zapisać bez niej. To jedna linijka w schemacie danych i jedna z najbardziej brzemiennych decyzji w całym narzędziu. Odstępstwo bezterminowe nie jest odstępstwem, jest cichą zmianą standardu, dokonaną bez rozmowy o jej kosztach. Data wygaśnięcia wymusza tę rozmowę w momencie, w którym jest jeszcze tania, i sprawia, że dług architektoniczny ma termin, a nie tylko właściciela.
Architekt, który pracuje z agentami
Do tej pory wszystko powyżej dawało się uzasadnić higieną. Współpraca z agentami AI zmienia to w konieczność, i to z powodu, który nie jest oczywisty.
Model językowy jest bardzo dobry w formułowaniu sądu o architekturze: nazwie ryzyko, zaproponuje dekompozycję, wskaże relację, której brakuje. Jest natomiast zawodny w twierdzeniach weryfikowalnych, poda relację ArchiMate, która nie istnieje w metamodelu, albo przypisze źródłu zdanie, którego w nim nie ma. Ten drugi błąd jest groźniejszy, bo brzmi wiarygodnie i bywa cytowany dalej. Dlatego w tym narzędziu obowiązuje zasada: model dostarcza sądu, narzędzie dostarcza dowodu. Każde twierdzenie o semantyce ArchiMate lub o treści źródła przechodzi przez oracle, który sprawdza je kodem wobec zawendorowanych źródeł pierwotnych, z cytatem zlokalizowanym w dokumencie. Prowadzimy rejestr faktów i mierzymy jego pokrycie, więc widać nie tylko to, co potwierdzono, ale i to, czego nikt nie potwierdził.
Zmienia się też ekonomia przeglądu. Agent potrafi wyprodukować spójny, dobrze sformatowany model większy niż ten, który architekt zdąży przeczytać w tym samym czasie. Przy pracy ręcznej wolne tempo tworzenia było ukrytym mechanizmem kontroli jakości; teraz tego mechanizmu nie ma. Deterministyczna walidacja przestaje więc być wygodą i staje się jedynym miejscem, w którym uwaga człowieka skaluje się razem z wolumenem, nie przez czytanie wszystkiego, lecz przez czytanie tego, co bramka odrzuciła.
Koszty tego podejścia są realne i warto je nazwać. Model w DSL-u wymaga od architekta pracy w narzędziach inżynierskich, co w części organizacji przesuwa granicę kompetencji. Reguły zapisane jako kod trzeba utrzymywać, a reguła zbyt sztywna generuje odstępstwa szybciej, niż ktokolwiek je zamyka. Startowy nakład jest wyższy niż przy warsztacie z diagramami i pierwszy widoczny efekt przychodzi później. To podejście opłaca się tam, gdzie decyzje architektoniczne mają konsekwencje audytowe albo gdzie równolegle pracuje wiele zespołów, nie wszędzie.
Test jest jednak prosty i niezależny od narzędzia: sprawdźcie, co w waszej organizacji stanie się z merge'em, który łamie zasadę architektoniczną. Jeśli odpowiedź brzmi „ktoś to wychwyci na przeglądzie", to zasady nie ma. Jest opinia z dobrą frekwencją na spotkaniach.