Architekt-metodolog: TOGAF i Change Management

Architekt-metodolog: jak zlikwidować rozdźwięk między strategią a kodem za pomocą TOGAF, zarządzania zmianami i automatyzacji procesów

Wielokrotnie korporacyjna architektura pozostaje tylko zestawem slajdów w PowerPointzie — nie dlatego, że jest niedoskonała, ale ponieważ pomiędzy jej projektowaniem a realizacją brakuje sterowanego, mierzalnego, opartego na rolach i zautomatyzowanego mostu. Ten rozdźwięk prowadzi do sytuacji, w której celowe schematy ArchiMate nie wpływają na decyzje zespołów developerskich, zasady są łamane „z ustawienia”, a dług techniczny rośnie liniowo z każdym wydaniem. Rozwiązanie nie leży w nowej metodologii, lecz w syntezie trzech komponentów: inżynierskiego zarządzania obiektami (TOGAF ADM Phase H), behawioralnego dopasowywania znaczeń (Organizational Change Management) oraz ich operacyjnej fiksacji poprzez automatyzację w CI/CD, Jira i repozytoriach. Architekt-metodolog to nie role w strukturze organizacyjnej, lecz funkcja integrująca te warstwy.

Dlaczego architektura „pływa”: diagnostyka rozdźwięku między Discovery i Delivery

W typowym procesie IT architekt korporacyjny (EA) tworzy architekturę docelową, zasady i mapę drogową — jednak nie bierze udziału w podejmowaniu decyzji na poziomie zadania. Solution-architekt (SolA) projektuje rozwiązanie pod konkretny problem, kierując się terminami i aktualnymi kompetencjami zespołu, ale bez bezpośredniej informacji zwrotnej od strategicznych artefaktów. W rezultacie zrealizowany system nie odpowiada żadnej z dwóch modeli: ani strategicznej, ani taktycznej.

To nie problem ludzi — to systemowy defekt zarządzania. Objawia się on brakiem jasnych odpowiedzi na kluczowe pytania:

• Jak backlog architektoniczny przekłada się na zadania w Jira i sprawdzany jest w pipeline’u?
• Kto i według jakiego kryterium podejmuje decyzję o odchyleniu od zasad architektonicznych?
• Jak mierzyć stopień zgodności rzeczywistej architektury z docelową — nie raz w roku, ale w każdym PR?
• Gdzie są zdefiniowane strefy odpowiedzialności za każdy artefakt architektoniczny (np. za ADR, za opis integracji, za wybór szyfrowania)?
• Jak zapewnić, aby zmiana w jednym serwisie nie naruszała zasad bezpieczeństwa czy danych w innym?

Bez formalizowanych procesów współpracy między EA, SolA i zespołami DevOps architektura staje się metaforą, a nie narzędziem.

TOGAF Phase H jako podstawa zarządzania obiektami architektonicznymi

Ostatnia faza TOGAF ADM — Phase H (Architecture Change Management) — to nie „utrzymanie dokumentacji”, lecz pełnoprawny cykl inżynierski zarządzania obiektami architektonicznymi. Określa, w jaki sposób dokładnie zmieniają się artefakty, kto w tym uczestniczy, które zmiany wymagają uzgodnień, a które — automatycznego odzwierciedlenia w repozytorium.

Kluczowe elementy Phase H w kontekście praktycznego zastosowania:

• Obiekty zarządzania: zasady architektoniczne, standardy wyboru technologii (np. „PostgreSQL 15+ wyłącznie dla OLTP”), schematy integracji (OpenAPI, AsyncAPI), dokumenty ADR, opisy domen danych (w terminach DAMA-DMBOK).
• Procesy klasyfikacji: rozróżnienie zmian na simplification (uproszczenie istniejącej architektury), incremental (stopniowe wdrażanie nowego komponentu) i re-architecting (całkowita wymiana warstwy). Każdy typ ma swój własny ścieżkę uzgodnień: od automatycznego sprawdzania w CI po posiedzenie Architecture Board.
• Metryki pomiaru: procent zadań z wypełnionym ADR, udział PR z automatyczną weryfikacją zgodności ze specyfikacją OpenAPI, liczba odrzuconych requestów dotyczących używania nieautoryzowanych technologii, poziom długów architektonicznych według SonarQube + niestandardowych reguł.

Phase H dostarcza języka, struktury i współrzędnych. Ale nie rozwiązuje pytania: dlaczego developer będzie wypełniał ADR, skoro nie jest to wbudowane w jego workflow?

Change Management jako praca z czynnikiem ludzkim

Organizational Change Management (OCM) to tutaj nie szkolenie HR, lecz techniczna dyscypllina zarządzania percepcją, motywacją i zachowaniem uczestników procesu. Jego celem jest sprawienie, by przestrzeganie zasad architektonicznych stało się naturalnym konsekwencją pracy, a nie dodatkowym obciążeniem.

Dzieje się to na trzech poziomach:

• Komunikacja w języku wartości: zamiast „trzeba wypełnić ADR” — „ADR pozwala Ci wcześniej zobaczyć konflikty integracji i uniknąć 3 dni debugowania w produkcji”.
• Nauka w kontekście zadania: wbudowane checklisty w szablonach Jira, interaktywne tutoriale w GitLab Wiki przy tworzeniu nowego serwisu, przykłady ADR w repozytorium z komentarzami „dlaczego dokonano tego wyboru”.
• Zaangażowanie przez odpowiedzialność: jasne przypisanie roli „Architekt” w review-workflow, automatyczne dodanie jej do assignee przy przejściu zadania do statusu „Design Review”, generowanie raportów o aktywności każdej roli w rozwiązaniach architektonicznych.

OCM nie zastępuje TOGAF — czyni go stosownym. Bez niego zasady architektoniczne pozostają rekomendacjami. Z nim — stają się częścią codziennej rzeczywistości.

Automatyzacja jako punkt łączący obiekty i znaczenia

Automatyzacja to nie tylko wygoda. To jedyny sposób, by ograniczenia architektoniczne stały się nieodwracalne i mierzalne. Kluczowa zasada: jeśli zasada nie może być automatycznie sprawdzana w CI/CD lub Jira — nie działa.

Przykłady wdrożenia:

# Sprawdzanie obecności ADR przed uruchomieniem pipeline’a
if [ ! -f "docs/architecture/adr-$(echo $CI_COMMIT_TAG | cut -d'-' -f2).md" ]; then
  echo "ERROR: Brak ADR dla tagu $CI_COMMIT_TAG"
  exit 1
fi

# Workflow Jira: zadanie nie przechodzi do ‘Ready for Dev’, dopóki nie zostaną wypełnione pola:
# - ‘Architecture Decision Record ID’
# - ‘Data Domain Owner’
# - ‘Security Review Status’ = ‘Approved’

# Automatyczna weryfikacja OpenAPI v3.1: zgodność z wewnętrznym standardem wersjonowania
# oraz obowiązkowymi securitySchemes
import openapi_spec_validator
from openapi_spec_validator import validate_spec
spec = load_spec('openapi.yaml')
assert spec['info']['version'].startswith('v2.'), "Version API musi być v2.x"
assert 'securitySchemes' in spec.get('components', {}), "Brak securitySchemes"

Taka automatyzacja usuwa obciążenie kognitywne, tworzy jedną prawdę i buduje kulturę odpowiedzialności. Developer nie „łamać zasady” — po prostu nie może ich złamać bez wyraźnego wyłączenia sprawdzania i wyjaśnienia powodu.

Co jest ważne

• Rozdźwięk między Discovery i Delivery to problem systemowy, a nie brak kompetencji: powstaje z powodu braku formalizowanych procesów współpracy między EA, SolA i DevOps.
• TOGAF Phase H zapewnia inżynierski framework do zarządzania obiektami architektonicznymi: zasadami, standardami, artefaktami i metrykami.
• Organizational Change Management gwarantuje akceptację tych obiektów przez ludzi poprzez komunikację wartości, naukę w kontekście i zaangażowanie przez role.
• Automatyzacja w CI/CD, Jira i repozytoriach to nie opcja, lecz obowiązkowy element IT-Governance: tylko w ten sposób można zagwarantować przestrzeganie zasad w codziennej pracy.
• Architekt-metodolog to funkcja, a nie stanowisko: posiada zarówno model obiektowy (TOGAF, ArchiMate), jak i praktyki behawioralne (OCM), oraz potrafi je łączyć poprzez techniczną implementację.

IT-Governance nie zaczyna się od utworzenia komitetu, lecz od wprowadzenia jednej zautomatyzowanej zasady — np. sprawdzania ADR w CI. Reszta to skalowanie tej praktyki: dodawanie nowych sprawdzianów, rozszerzanie ról, integracja z metrykami jakości i bezpieczeństwa. Najważniejsze — nie pozostawiać architektury w prezentacji. Trzeba ją wbudować w kod, w pipeline, w workflow. Tylko wtedy przestaje być slajdami i zaczyna rządzić.

— Editorial Team