Pułapka systemów zintegrowanych

Data: 2021-06-16
Autor: Sebastian Konkol
Pułapka systemów zintegrowanych

W każdej firmie, w której informatyka ma jakieś znaczenie, znajdzie się jakiś CRM, ERP czy BI. Są to systemy o wieloletniej historii, wdrażane według stabilnych i dobrze udokumentowanych metod, obrośnięte zasadami governance. Ich niewątpliwymi zaletami są zdolność do zapewnienia kompleksowego rozwiązania dla znaczącej – w wielkości i istotności – części działań biznesowych oraz gotowość do działania „od dnia zero”. Po kilku latach okazuje się jednak, że coraz częściej stają się przeszkodą.

Jest wiele powodów, dla których tak się dzieje. Najbardziej podstawowe ograniczenie ewoluuje z czasem z największej zalety – zdolność do szybkiego wdrożenia opiera się na tym, że system zintegrowany realizuje spójny (i zwykle mocno ustalony) model działania, procesy biznesowe, sposób współpracy z otoczeniem biznesowym. Z czasem okazuje się, że ta „gotowość” staje się przesztywnieniem konstrukcji, ograniczającym możliwość rozwoju biznesu.

Są jednak także inne powody, a takim z którym ostatnio przyszło mi się zmagać w kilku firmach to ustanowienie systemu zintegrowanego samodzielnym „ekosystemem” do rozwoju oprogramowania. Każdy szanujący się system zintegrowany jest oczywiście wyposażony w wiele możliwości konfiguracji oraz głębszego dopasowania, które lokowane jest już w sferze „rozwoju oprogramowania”. Naturalnie, zdolność taka jest dobra, ale w takim systemie technicznie mogą być realizowane funkcje, które nie powinny być tam nigdy implementowane. Oczywiście, nie dzieje się to jednorazowo, lecz stopniowo, odrobinkę przy każdej zmianie, w ramach której „nie opłaca się” powoływać oddzielnego środowiska do zrealizowania jakiejś funkcji na zewnątrz systemu zintegrowanego, za to znajduje się jakiś hak (specjalność specjalizowanych w takim, czy innym systemie zintegrowanym), dzięki któremu da się to upchnąć w tymże systemie zintegrowanym. Przy kolejnej okazji granica tego, co można sobie wyobrazić w systemie zintegrowanym przenoszona jest odrobinę dalej. Rzecz jasna, gdyby takie granice pokazać w czasie wdrażania systemu zintegrowanego, to absolutnie wszyscy popukaliby się w głowy, a jednak z czasem do tego dochodzi. Zachodzenie takiego procesu świadczy o słabości stanowienia architektury w takiej firmie, ale to temat do poruszenia już innym razem.

Pisałem wcześniej, że architektura zwinna eliminuje systemy zintegrowane gdyż są one esencją antyzwinności – przesztywniona konstrukcja, narzucone sposoby przetwarzania danych i realizacji procesów, zamknięty dostęp do baz danych o narzuconej strukturze i logice, zmienność z wersji na wersję, ograniczone możliwości włączania w nowoczesne procesy wytwórcze, to tylko część problemów. Naturalnie, żadna firma nie pozbędzie się z dnia na dzień systemu klasy CRM, a prawdopodobnie nigdy nie pozbędzie się systemu klasy ERP – i dobrze, bo co najmniej część tych klas systemów niesie realną wartość dla organizacji i dobrze wypełnia swoje zadania. Z drugiej strony, jeśli ktokolwiek w ostatnich latach próbował postawić eCommerce we współpracy z systemem klasy ERP (cenniki, stany magazynowe, polityka promocyjna, fakturowanie) spopielił zaklęciami niejedną wykładzinę – wdrożenie eCommerce dla rynku B2B uczy zaklęć spopielających całe fabryki wykładzin. Tak się po prostu nie da – trzeba jakoś inaczej, inteligentnie, sprytnie, adaptacyjnie.

Oczywiście pamiętamy jeszcze (prawda?) Gartnerowskie klasyfikacje elementów portfela aplikacji między systems of records a systems of engagement. Jako model wspomagający decyzje nie przyjął się on jakoś, ale niesie za sobą ważną myśl – rozwiązania informatyczne mają warstwy, a sposób „posiadania” poszczególnych z nich powinien być różnicowany bardzo, bardzo świadomie. Co ciekawe, mimo powszechnej wiedzy o tym, prawie równie powszechne jest raczej „obudzenie się z problemem”, niemalże tym samym problemem – nakładania na systemy określonej „klasyfikacji” procesów rozwojowych z innej „klasyfikacji”, promującej błędny tryb rozwoju rozwiązania sklasyfikowanego jako system of records.

Przede wszystkim jednak należy postawić ostrą granicę między systemem zintegrowanym a otoczeniem i bardzo rygorystycznie jej strzec, na przykład wprowadzając pryncypium korzystania wyłącznie z możliwości konfiguracyjnych systemu zintegrowanego i niedostosowywania systemu zintegrowanego (czyli wymagania bardzo solidnego uzasadnienia dostosowywania takiego systemu). W konsekwencji funkcje nienadające się do implementacji wewnątrz systemu zintegrowanego nie będą tam trafiały, lecz będą realizowane na zewnątrz tej granicy. W taki sposób wokół systemu zintegrowanego powstaje „wianuszek” aplikacji, a jeśli kontrola architektoniczna jest sprawnie prowadzona w firmie, szybko następuje scalenie z architekturą front-endów dla poszczególnych jednostek biznesowych.  W ten sposób wokół każdego systemu zintegrowanego powstaje zbiór rozwiązań o topologii gwiazdy. W centrum jest system zintegrowany, a na zewnątrz są komponenty (nazwałbym je usługami SOA, choć często nazywane są mikroserwisami). Te usługi mają z jednej strony zapewniać środowisko dla skuteczniejszego prowadzenia rozwoju, a z drugiej – amortyzować techniczne słabości systemów zintegrowanych (np. długi czas dostępu do danych w systemach zintegrowanych). Tak, podążając prostym skojarzeniem, SAP rozwiązuje ten drugi problem dostarczając SAP CAR działający w oparciu o SAP HANA (poza tym, że koszty licencji są powalające), SAP CAR realizuje właśnie wzorzec przeniesienia pracy poza system transakcyjny udostępniając topologię gwiazdy. Co ciekawe, choć opowiadam o tym na narzucającym się przykładzie systemu klasy ERP, analogiczne rozwiązania powstają w kontekście innych klas systemów zintegrowanych (Billing / Customer Care, CRM, PIM, ERP, BI).

Trzeba przy tym pamiętać, po co to robimy, gdyż celem jest pokrycie stabilnym rozwiązaniem znanego i stabilnego problemu biznesowego (np. naliczania opłat, rejestracji klientów, księgowości i magazynowania) w tej ich części, która rzeczywiście jest stabilnym problemem biznesowym – oraz natychmiastowe wyjście z tego rozwiązania tam, gdzie istnieje zmienność. W ten sposób da się pogodzić zwinność (Agility) z odpornością (Resilience).

Koncepcja systemu zintegrowanego pochodzi z przełomu lat ’80 i ’90 ubiegłego wieku. Choć wiele się zmieniło od tamtej pory systemy zintegrowane nadal dostarczają wymierną wartość dla przedsiębiorstw. Zmieniło się jednak tak dużo, że konieczne jest dopasowanie sposobu myślenia o posiadaniu i użytkowaniu takich systemów: niech robią to, co robią dobrze – i nie robią tego, co lepiej jest robić poza nimi. Prawda, że proste? 😉

Pozostaw komentarz