W poszukiwaniu Wzorca Architektury

Data: 2019-01-07
Autor: Sebastian Konkol
W poszukiwaniu Wzorca Architektury

Od ponad dwóch dekad rozwiązuję zagadki ze świata informatyki praktycznej, sfery nazywanej w literaturze “Enterprise Information Systems”, posługując się warsztatem i narzędziami architekta. Wraz ze wzrostem doświadczenia rośnie we mnie przekonanie, że najważniejszą klasą narzędzi architekta są wzorce architektury, wszak po co za każdym razem na nowo wymyślać koło, skoro już wiemy, jak ma wyglądać? Z drugiej strony jednak stosowanie wzorców staje się coraz trudniejsze, wymaga coraz większego wysiłku, napotyka na coraz więcej przeszkód. Coś jest nie tak ze wzorcami? Problemy są tak specyficzne dla każdego przypadku? Myślę, że nie, a prawdziwa zagadka jest w nieco innym miejscu.

W wersji streszczenia dla kierownictwa problem przedstawia się następująco. Pomimo deklaracji o integrowalności, otwartości, API, współdzieleniu i całej tej reszcie, systemy informatyczne budowane są jak rozwiązania zamknięte, silosowe, jakby każdy system był „pępkiem świata” i narzucał reszcie swój punkt widzenia na świat (model danych, sposób działania, GUI). Każdy system odwzorowuje jednak pewien model świata, a – jak dobrze wiemy – “All models are wrong, but some are useful”. Wkładamy więc coraz więcej wysiłku w działania integracji rozwiązań, które powstają jako silosowe, z egoistyczną myślą przewodnią bycia pępkiem świata. Integracja takich rozwiązań wygląda coraz bardziej jak mediacja w sytuacji „Ślubów Panieńskich”, ale prowadzona przez Pacyfik pomiędzy Inkami i Hindusami, włączając w te mediacje różnice kulturowe i stref czasowych, pamiętając, że tylko mediatorowi zależy na dojściu do porozumienia. Próbujemy posklejać działający biznes z elementów nie mających ze sobą nic wspólnego – nawet nie projektowanych z myślą o tym, że poza dowolnym z nich istnieje cokolwiek.

Ostatnia dekada obfituje w poważne i doniosłe prace nad wzorcami integracji systemów klasy Enterprise. W tej sferze wyczerpaliśmy już możliwości, które niosłyby jakieś sensowne ekonomiczne uzasadnienie. Jeśli ma być skuteczniej i efektywniej, wysiłek trzeba włożyć w inną sferę działania – wzorce tworzenia systemów klasy Enterprise, które zapewnią rzeczywistą możliwość integrowania ich. Takich wzorców poszukuję od kilku lat, a ponieważ ich nie znajduję, wypełniam tę przestrzeń własnymi pomysłami.

Na czym miałby się opierać Wzorzec Architektury systemów klasy Enterprise? Na prawdziwym otwarciu, akceptacji istnienia innych rozwiązań, specjalizacji w określonych sferach. Główne założenia dla Wzorca mogłyby wyglądać następując:

  • Oddzielenie danych od funkcji aplikacji. Dzisiaj dane są traktowane jako produkt uboczny działania aplikacji. Każda z nich tworzy dane tak, aby aplikacji było wygodnie. W konsekwencji te same obiekty mamy w wielu systemach, tylko opisane w sposób niepowiązany. Systemy powinny być więc projektowane i tworzone w sposób explicite rozdzielający warstwę danych od warstwy logiki biznesowej. Część danych aplikacji to jej dane „prywatne”, ale jedynie część – druga część to dane o charakterze współdzielonym (np. dane klientów, katalog produktów, księga główna). Aplikacje powinny umieć działać na danych współdzielonych bez konieczności „kopiowania” ich do przestrzeni swoich danych prywatnych.
  • Dane współdzielone. W konsekwencji powstawałyby repozytoria danych o specjalnym charakterze. Takie współdzielone dane powinny stanowić pojedyncze źródło prawdy i gwarantować synchronizację procesów realizowanych w aplikacjach. Powinny one stanowić niezależne byty w środowisku informatycznym firmy.
  • Specjalizacja funkcji komponentów. Dobrym przykładem funkcji sprawiającej wiele problemów jest workflow. Każdy większy system implementuje jakąś formę konfigurowalnych procesów. Mamy więc wiele środowisk prowadzenia procesów, a te prawdzie (end-to-end) musimy realizować i tak „poza” wszystkim systemami. Każdy system otwarty powinien zapewniać możliwość poddawania swoich obiektów zewnętrznym procesom, zgodnie z logiką biznesową dopuszczalnych operacji na tych obiektach. Czym staje się system finansowo-księgowy? Księgą ze zbiorem procesów księgowych. Oczywiście, prowadzi to do konstatacji, że model systemu zintegrowanego (np. ERP, CRM) jest ślepą uliczką.
  • Funkcje wspólne. Każda aplikacja wprowadza wiele tych samych funkcji. Od tak fundamentalnych jak zarządzanie użytkownikami i uprawnieniami, czy uwierzytelnienie, aż po złożone jak generowanie zdarzeń, obsługa procesu, czy zarządzanie dokumentami elektronicznymi. Z jakiegoś powodu akceptujemy systemy, z których każdy implementuje niezależnie te funkcje. Po co? Środowisko informatyczne powinno być zbiorem komponentów realizujących dobrze określone funkcje – najlepiej, jak to możliwe. Potrzebujemy systemowo jednego uwierzytelnienia (zamiast integracji systemów do „jednego SSO”), potrzebujemy jednego repozytorium dokumentów, jednego sterowania procesami biznesowymi. Orkiestracja, SLA i współpraca z systemami spoza jurysdykcji (chmura?) to także dobrzy kandydaci na funkcje wspólne, podobnie jak monitorowanie działania, wykrywanie problemów i nadużyć.
  • Środowisko działania. W myśl Wzorca, każdy system klasy Enterprise zamiast dostarczać niezależne środowisko pracy użytkowników (GUI), powinien udostępniać komponent osadzany w środowisku GUI. Takie środowisko powinno zapewniać realizację funkcji wspólnych. Specjalizowane funkcje administracyjne powinny być dostępne jak kontrolki w panelu sterowania. API i integracja powinny być fundamentem działania zarówno GUI jak i systemów współpracujących („integracja” to bardzo złe słowo). Dane współdzielone i operacje na nich powinny być elementem opisywanym standardami, jak w przypadku Semantic Web.

Według takiej wizji budowanie wsparcia informatycznego oznaczałoby dokonywanie przemyślanych decyzji o zakupie lub wytworzeniu specyficznych komponentów logiki biznesowej, jakie byłyby potrzebne dla sprostania wymaganiom. Wdrożenie wymagałoby osadzenia danych w środowisku danych współdzielonych (wszak i tak wymaga), osadzenia GUI w środowisku działania użytkowników, włączenia funkcji administracyjnych do „panelu sterowania”. Oczywiście upraszczam, ale takie podejście – o ile oparte na konstrukcji systemów w myśl Wzorca – byłoby znacznie lepszą alokacją wysiłku organizacji. To systemowe podejście do implementacji rozwiązań Best of Breed.

Co to oznacza? Bez wątpienia, poważną rewolucję. Model budowy wsparcia informatycznego to jednak co najmniej tyle samo ważąca zdolność co zarządzanie finansowe w firmie. Każda firma, przechodząc od fazy startup’u do normalnego wzrostu, ma możliwość ukształtowania tego modelu zgodnie ze Wzorcem, o ile tylko będzie tego chciała. Firmy dojrzałe co jakiś czas przechodzą także poważne zmiany w tej sferze – zmiany, które mogą opierać się na takich wzorcach. Cyfrowe transformacje to tylko modna etykieta dla takich zmian. Bez wątpienia, nie jest to prosta i łatwa ścieżka, jednak droga obecna prowadzi do wykładniczo rosnących kosztów integracji przy ginących korzyściach osiąganych tymi kosztami.

 

Dlaczego jesteśmy w takiej sytuacji? Z jednej strony to modus operandi branży ICT – dostarczają zamknięte rozwiązania dla konkretnych problemów, przerzucając problemy integracji na kupującego. Znacznie łatwiej sprzedać zamknięty system, niż rozwiązanie naprawdę otwarte. Z drugiej strony jednak kupujemy takie rozwiązania, przyjmując te problemy na siebie. Kupujemy rozwiązania IT formułując wymagania na systemy zamknięte. Może (już / jeszcze / najwyższy, właściwe podkreślić) czas zmienić ten paradygmat?

Pozostaw komentarz