„Wirusy” architektoniczne

Data: 2013-11-27
Autor: Sebastian Konkol
„Wirusy” architektoniczne

W kilku projektach, w jakich ostatnio doradzałem, byłem świadkiem wielu dyskusji z architekturą w tle, choć wypowiadane zdania nie świadczyły o takim tle. Odnosiły się do zagadnień o charakterze migracji danych, podatności na dostosowania „w ostatniej chwili”, czy wydajności systemów informatycznych. Wcale nie jest to „głuchy telefon”, więc co?

Dwa przypadki ilustracyjne.

Pierwszy z nich dotyczył ustalania szczegółów dotyczących „wtłoczenia” danych ze starego systemu, który pełnił przez wiele lat określone funkcje biznesowe, do nowego systemu, którego funkcje – przynajmniej w założeniach – miały być wykorzystywane znacznie szerzej. Stary system został skonstruowany na kilka lat przed wdrożeniem go w organizacji, dla której pracowałem, a od czasu wdrożenia minęło już trochę czasu. Przez te lata stary system, jak to zwykle bywa, „obrastał” kolejnymi, małymi rozszerzeniami, zmieniającymi de facto w istotny sposób jego rolę biznesową, jednak w klasyfikacji tego systemu był to nadal system bilingowy. Nowy system także był systemem bilingowym, a – w porównaniu z funkcjami bilingowymi starego systemu – jego możliwości deklasowały stary system o kilka rzędów wielkości. Jeśli więc zamienimy stary na nowy, to uzyskamy ogromne nowe zdolności kreowania biznesu, prawda? Taka myśl była podtrzymywana przez cały, trwający ponad rok projekt przygotowań do „procesu podmiany”. Na zakończenie przygotowań trzeba było jeszcze „tylko” ustalić, jak dane ze starego systemu zasilą nowy system. I zaczęło się. Najpierw okazało się, że – w konsekwencji słabości i ograniczeń starego systemy – dane do przeniesienia są rozproszone, a funkcje na nich operujące rozsiane po „naroślach” (wcale nie bilingowych) i wielu innych systemach (bo gdzieś przecież trzeba było to zrobić). Te „narośla” i  inne systemy pracowały wprost na strukturach danych starego systemu, wiążąc je z innymi funkcjami realizowanymi poza starym systemem – „wirus” ograniczeń starego systemu przez lata rozprzestrzeniał się niezauważalnie. Powstały więc dwie możliwości: albo wszystkie „naroślą” i inne systemy trzeba zmienić, aby współpracowały z nowym systemem (wysiłek co najmniej porównywalny z całym „przepięciem”), albo wymusić na nowym systemie dostosowanie się do struktur danych starego. Nie trudno zgadnąć, który wariant został wybrany – nowy system został „zgwałcony”, aby odwzorować struktury danych starego, dzięki czemu wszystkie „naroślą” i inne systemy mogły nadal współpracować, ale… utracił w konsekwencji wszystkie możliwości kreowania biznesu, a w kilku wypadkach był nawet gorszy, niż stary system. I co? I nic! Wielki wysiłek i poważne wdrożenie, którego efektem było ograniczenie wykorzystywanych już zdolności kreowania biznesu, łatane „naprędce”. A najtragiczniejsze było to, że nowy system został zainfekowany tym samym „wirusem” ograniczeń starego systemu, który kontynuował swoje życie i rozprzestrzenianie się nawet po wyłączeniu starego systemu.

Drugi przykład dotyczył ustalania sposobu integracji nowego, wdrażanego właśnie systemu z systemami istniejącymi już w środowisku informatycznym firmy. Wszystko zostało ustalone, zarówno dla trybu wsadowego jak i komunikacji on-line. Wskazane zostały standardy integracji w obu trybach. Ustalono wymagania wydajnościowe, adekwatne dla każdego z trybów. Zrealizowano integrację kilkunastu przepływów, zgodnie z ustaleniami i standardami. Zmierzono wydajność osiąganą przez poszczególne przepływy… i okazało się. Okazało się, że jeden z systemów, który miał być obsługiwany w trybie on-line, wymaga od wdrażanego systemu „poprawy” parametrów wydajnościowych, a punktem odniesienia dla „poprawy” były parametry obowiązujące w trybie wsadowym. Padło kilka propozycji rozwiązania zagadnienia „poprawy”, pośród których jednym z wariantów był taki, który w najszybszy sposób rozwiązywał problem, ale wymagał „nagięcia” standardów integracji – choć był on najszybszym rozwiązaniem, traktowany był jako zło konieczne.

Oba te przypadki łączy wspólny powód, dla których w ogóle się wydarzyły. W obu tych przypadkach zabrakło myśli architektonicznej przez cały czas trwania tych przedsięwzięć. W pierwszym „przeoczono”, że charakter starego systemu został znacznie zmieniony, a sposób integracji starego systemu z resztą środowiska uzależniał całe środowisko od tego konkretnego systemu. „Wyszło” w najgorszym momencie, kiedy kierownictwo projektu bało się już tak bardzo, że było skłonne pogrążyć biznes w kłopotach, byle nie ogłosić poważnego zagadnienia projektowego. W drugim przypadku „przeoczono”, że nie wszystkie integracje zgadzają się z przyjętymi standardami. „Wyszło”, kiedy w momencie próby odpowiedzialni za integrację, bezpiecznie dla siebie, trzymali się kurczowo standardów i byli gotowi wymusić na projekcie poniesienie znacznie większych kosztów, byle tylko mieć porządek u siebie.

Problemy takie wcale nie są tworzone przez technologię. Coś, co w efekcie określane jest poważnym błędem architektonicznym, mszczącym się przez wiele lat, jest prostą konsekwencją faktu, że ludzie nie chcą ponosić konsekwencji błędnych decyzji, nawet jeśli nie swoich. Coś, co w efekcie powinno być postrzegane jako poważna pomyłka w integracji wcale nie wynika z wyboru technologii, lecz z nastawienie ludzi „od integracji”. Takie wirusy wcale nie rozprzestrzeniają się przez systemy – rozprzestrzeniają się przez ludzi.

Pozostaw komentarz