Trzeba robić inną architekturę

Data: 2021-10-06
Autor: Sebastian Konkol
Trzeba robić inną architekturę

Biorąc pod uwagę prosty fakt, że współczesny świat technologią IT stoi, co do zasady umiemy (jako ludzkość, nie koniecznie każda organizacja) robić zwinnie całkiem spore „systemy informatyczne”. Ciągle jednak jest długo (i coraz dłużej) i drogo (i coraz drożej), a do tego z czasem (coraz krótszym) każdy, nawet najlepiej zrobiony system staje się ciężarem. Nie wszystko można zrzucić na marketing dostawców technologii IT i wciskanie kolejnej „wielkiej technologii rozwiązującej wszystkie problemy (znane i nieznane)”. Podstawowy problem musi więc polegać na czymś innym.

Prosty przegląd wskazuje, że najpierw kwantem działania (w ramach pierwotnego wdrożenia), a później ziarnem krystalizacji dalszych prac (w ramach rozwoju) jest twór nazywany „systemem informatycznym”. To wokół niego toczone są dyskusje, tworzone są plany i identyfikowane problemy. Skąd się jednak te systemy biorą?

Otóż, jeśli przyjrzeć się dokładnie, systemy biorą się najczęściej z arbitralnych podziałów uruchamianych inicjatyw, projektów, przedsięwzięć, czy jak są zwane te twory w różnych firmach. Każde z nich buduje „swój system”, z definicji będący silosem w konsekwencji budowania wagi systemu przez przedsięwzięcie. Później trzeba go „jedynie” zintegrować… i zaczynają się najdroższe schody w praktycznej informatyce – nieuzgodnione modele danych, duplikacja danych, niezależne i niepowiązane identyfikacje tych samych obiektów biznesowych, arbitralnie pocięte procesy biznesowe, sztuczna złożoność interakcji, to zaledwie początek listy kosztownych konsekwencji wynikających z arbitralnych podziałów granic między systemami i potrzeby budowania wagi w organizacji przez przedsięwzięcia powołujące te systemy do życia. Co gorsze, z racji arbitralnych podziałów przedsięwzięć „informatycznych”, te problemy ulokowane są w przypadkowych miejscach i wcale nie tam, gdzie najsprawniej byłoby je rozwiązać, gdyby sensowniej postawić granicę między systemami lub rozłożyć proces biznesowy – najpierw, niestety, jest granica systemu, a później problem integracji. Sprawy „ewoluujących” zakresów projektów wraz z upływem czasu i wypalaniem budżetu projektu dodają kolejnych „warstw trudności” – kierownicy projektów podejmują różne decyzje okrawania zakresu i (tu zaskoczenie) niemal zawsze skutkujące zwiększeniem trudności „późniejszej integracji”. Panujące powszechnie podejście „odnarzędziowe” (zróbmy system) promuje nie tylko silosowość, ale i lokalne rozwiązywanie problemów, nawet jeśli mają one zasięg szerszy niż tylko lokalny. Organizacja staje się w zawrotnym tempie zakładnikiem uwarunkowań i ograniczeń narzędzi, czyli sposobu myślenia jego twórcy / twórców, z całym bagażem zamkniętości na zmiany i rozwój.

Dlaczego jest to dla mnie tak oczywiste? Bo sieciowość jest najbardziej podstawową cechą świata, a arbitralne dzielenie go powoduje brak możliwości poskładania później do tzw. kupy. Napisał o tym już dosyć dawno temu Albert-László Barabási, w swojej książce “Linked: How Everything Is Connected to Everything Else ad What It Means for Business, Science, and Everyday Life”. Jeden cytat, odnoszący się do sposobu działania współczesnej nauki, warto przytoczyć:

“Have you ever seen a child take apart a favourite toy? Did you then see the little one cry after realizing he could not pull all the pieces back together again? Well, here is a secret that never makes the headlines: We have taken apart the universe and have no idea how to put it back together. After spending trillions of research dollars to disassemble nature in the last century, we are just now acknowledging that we have no clue how to continue – except to take it apart further.”

Taka jest jednak charakterystyka w zasadzie każdego systemu złożonego – o tym właśnie jest ta książka. Polecam gorąco, otwiera oczy na wiele bezsensowności, nadal traktowanych jako standard operating procedure. Jak podzielimy arbitralnie świat na systemy, to nawet nie będziemy wiedzieli, jakie powiązania pocięliśmy. Wiara w to, że uzyskamy w ten sposób jakąś kontrolę jest wiarą opartą na ogromnych rachunkach za informatykę.

Wracając jednak do naszych systemów i problemów generowanych przez to, jak je tworzymy, Niestety podstawowym jest właśnie prosty fakt, że choć chcemy korzystać z otwartości wszystkich systemów w otoczeniu, te „nasze” systemy tworzymy jako zamknięte, silosowe. Próbowaliśmy „przerzucić wszystkie piłeczki” do dostawców, wierząc w magię systemów zintegrowanych, ale nie bardzo się to udało. Tak samo zresztą wierzyliśmy, że chmura, jeszcze zwinniejsze metody i narzędzia, czy sztuczna inteligencja rozwiążą te problemy – nie rozwiązują, co najwyżej wytwarzają kolejną warstwę „zakryć” tuszujących problem na jakiś czas. Wiemy, więc, że nie tędy droga. Którędy więc? Jak powinniśmy kształtować architekturę, aby przystawać do współczesnych potrzeb i dynamiki otoczenia?

Po pierwsze, technologia IT dojrzała na tyle, że zdecydowanie lepiej (pod każdym względem) jest kodować, niż dopasowywać. Taniej jest też budować, niż kupować tzw. gotowe, a kto nie wierzy, niech policzy koszty jednego postępowania przetargowego – ekwiwalent półrocznej pracy zgranego i produktywnego zespołu scrumowego, 10 sporych sprintów (sic!), a jak do tego dodać dostępne możliwości PaaS w każdej z chmur, to aż szkoda czasu na zastanawianie się nad tym.

Po drugie, mamy rozpoznanie – zarówno plusów jak i minusów – podejścia mikrousługowego. To jest dobry wzorzec, choć wymagający także czujności w innych obszarach. Wzorzec ten pozwala osiągnąć adaptowalność w rozwoju systemów informatycznych, jednak odnosi się wyłącznie do sfery funkcjonalnej. Możnaby powiedzieć, że mikroserwisy to sposób na skuteczne tworzenie narzędzi do przetwarzania informacji – do sfery materiału podlegającego obróbce (informacji, danych) potrzebujemy analogicznego wzorca, nadrzędnego w stosunku do mikroserwisów.

Brakujący element tej układanki to odpowiedni sposób radzenia sobie z danymi – ich semantyka, spójność, poprawność identyfikacji itd. Dane powinny być centralnym tematem myślenia architekta, bo wszystkie narzędzia (systemy) powinny operować na tym samych materiale (nie takich samych, a nawet nie skopiowanych danych). Systemy przemijają, a dane pozostają – dane to pamięć i wspomnienia organizacji, a przede wszystkim podstawa zrozumienia i doskonalenia. Aplikacje to „zaledwie” narzędzie doskonalenia i powinniśmy móc je zmieniać szybko i często (Agility). Kiedyś wydawało mi się, że dane także mają być zwinne, ale jest inaczej – spojrzenie na dane powinno zapewniać ciągłość wiedzy i działania firmy, a skuteczność zabezpieczania danych stanowi o odporności organizacji (Resilience).

Po co ta wiedza architektowi? Po to, aby zapewnił gotowość do wielokrotnego wykorzystania posiadanych zasobów – danych i systemów – bez konieczności ich każdorazowego dopasowywania. Brzmi abstrakcyjnie, ale wcale takim nie jest – na tym właśnie polega zwinność w architekturze.

Nie mam na dziś pewności, w jaki sposób powinniśmy zapanować nad architekturą biznesową. Mam jednak taki swój typ, przeświadczenie, że właściwą drogą jest myślenie w kategoriach DDD (Domain-Driven Design). Tak, czy inaczej – wracając do początku – pracując „po nowemu” na danych i aplikacjach dajemy możliwości niepopełniania grzechu arbitralnych podziałów, ale wyeliminować te działania trzeba w oparciu o jakiś dobry pomysł. W najbliższym możliwym projekcie planuję podążać tą właśnie ścieżką.

Musimy zmienić percepcję z „najpierw narzędzia” (architektura aplikacji) na „najpierw materiał” (architektura danych) – budować i egzekwować wspólne modele danych (aby dane uczynić uniwersalnym dobrem, bez względu na to, którym narzędziem je obrabiamy), identyfikować obiekty biznesowe i powiązania między nimi w sposób niezależny od systemu (aby móc opierać się na danych, a nie na procesach ich uzgadniania wymagających angażowania narzędzi sztucznej inteligencji). Musimy rutynowo włączać data governance w prace architektoniczne (aby ponownie przyzwyczaić organizację dbałość o utrzymanie jakości danych), wymuszać tworzenie współużytkowanych źródeł współdzielonych danych (aby wyeliminować nie tylko konieczność „synchronizacji” danych, ale usunąć patologiczne konsekwencje istnienia takich procesów). Musimy promować mechanizmy aplikacyjne umożliwiające rutynowe oparcie o dane zewnętrzne (aby narzędzia zaczęły wreszcie być pomocą w pracy na materiale, nie zaś były źródłem wypaczenia). Potrzebujemy robić inną architekturę – wcale nie tę obecną, skupioną na funkcjonalności (architektura aplikacji), ale co najmniej równorzędnie traktującą informacje (architektura danych) – musimy budować architekturę systemów informacyjnych, dekomponowaną świadomie tam, gdzie podpowiada nam architektura biznesowa, a nie chwilowe zaangażowanie organizacji w takie czy inne przedsięwzięcie.

Pozostaw komentarz