Kontekst a architektoniczna ślepota
Ostatnio spotkałem się na LinkedIn z dyskusjami na temat tego, czy architekt z branży bankowej lub FinTech dobrze zaprojektuje systemy dla innych branż. Główny zarzut dotyczył tego, że praca z centralnymi systemami bankowymi (Core Banking) wygląda zupełnie inaczej niż z systemami klasy ERP czy CRM. Jest w niej więcej restrykcji, często trzeba stosować starszy stos technologiczny oraz skupiać się na natychmiastowej aktualizacji i spójności danych. Do tego dochodzi optymalizacja pod kątem gigantycznej liczby użytkowników i transakcji. Takie systemy nierzadko zawierają dług technologiczny zbierany przez dekady – ponieważ są to rozwiązania wysokiego ryzyka, wspomniany dług bywa nienaruszalny. Skoro kod działa, lepiej go nie ruszać, by nie generować dodatkowego zagrożenia.
W przypadku systemów ERP, CRM czy E-commerce sytuacja wygląda inaczej. Częściej można tam eksperymentować i wdrażać najnowsze standardy oraz technologie, a codzienna walka z mikrosekundową optymalizacją i restrykcyjną transakcyjnością schodzi na dalszy plan.
Pytanie o to, czy architekt systemów bankowych będzie dobrym architektem systemów ERP, przypomina mi pytanie, czy maszynista pociągu będzie dobrym kierowcą samochodu. Odpowiedź brzmi: tak, ale nie może stosować tych samych zasad, odruchów i nawyków w obu różnych pojazdach.
Kluczowy problem pojawia się wtedy, gdy architekt próbuje bezmyślnie aplikować sprawdzone w jednym środowisku praktyki i wzorce bezpośrednio do zupełnie innej domeny, nie weryfikując odmienności uwarunkowań biznesowych i technicznych. Efektem są zazwyczaj rozwiązania przekombinowane (over-engineered), zbyt sztywne i niedopasowane do realnych potrzeb organizacji.
W tym miejscu przypomina mi się biblijna metafora:
„Nie wlewa się nowego wina do starych buklaków, ani starego wina do nowych”.
Podobnie jest z modelami myślenia (mental models) w architekturze. Próba wtłoczenia paradygmatów z jednej specyficznej domeny w realia zupełnie innego systemu, bez zrozumienia jego specyfiki, kończy się niedopasowaniem strukturalnym. Problem nie leży jednak w samych narzędziach, lecz w braku świadomości kontekstu.
Jeżeli jednak architekt jest w pełni świadomy różnic kontekstowych i potrafi aktywnie przełączać swoje modele myślenia w zależności od środowiska, w którym przychodzi mu projektować, może być wysoce skuteczny w różnych domenach.
Stwierdzenie, że specjalista od systemów transakcyjnych musi być z definicji kiepskim architektem w świecie CRM/ERP, to klasyczny błąd kategoryzacji.
Główny wniosek: Problem rzadko tkwi w samych kompetencjach danej osoby. Leży on w bezrefleksyjnym przenoszeniu nawyków, mechanizmów i wzorców zachowań z kontekstu, w którym zadziałały idealnie, do zupełnie nowego środowiska – bez weryfikacji, czy zmiana warunków brzegowych nie sprawiła, że przestały one przynosić wartość.
Refleksja końcowa
Kluczem do dojrzałej architektury korporacyjnej nie jest kurczowe trzymanie się jednego, uniwersalnego wzorca, do którego wszystko wydaje się pasować. Jest nią elastyczność, ciągła refleksja nad kontekstem biznesowym oraz gotowość do kwestionowania własnych przyzwyczajeń inżynieryjnych i stosowania zasad myślenia systemowego (Systems Thinking).
Notatka jest częścią cyfrowego ogrodu. Będzie ewoluować wraz z kolejnymi przemyśleniami na temat Systems Thinking i praktyki architektonicznej.