System wielokrotnie zintegrowany

Systemy CRM/ERP z reguły są systemami złożonymi, o podstawowej gradacji tej złożoności opartej o moduły funkcjonalne. Budowa taka jest naturalną konsekwencją konieczności opanowania znacznej komplikacji i ogromnej skali systemów tej klasy. Sama idea podziału, choć niewątpliwie słuszna, implikuje separację i w konsekwencji konieczność przeciwdziałania negatywnym skutkom tejże np. poprzez integrację.

Podstawowym i powszechnym wyznacznikiem integracji systemów jest proste i oczywiste założenie, że wszystkie moduły współpracują ze sobą w dostarczaniu złożonych funkcjonalności oraz partycypują w dostępie do współdzielonych zasobów. W konsekwencji tej współpracy mamy np. jeden zbiór danych kontrahentów, a jak wystawimy dokument w module sprzedaży, to w module księgowym pojawia się on automatycznie i ma już dekrety zgodne z definicją wzorca dekretacji. Takie podejście w dzisiejszych czasach można uznać wyłącznie za punkt wyjścia do dalszych rozważań o skali i zakresie integracji w złożonych systemach informatycznych. Rozważając kolejne możliwe płaszczyzny integracji, proponuję przyjrzeć się z pewnego dystansu kilku rozwiązaniom z zakresu systemu VERTO i platformy NEXT:

• Podsystemy funkcjonalne — Twórcy systemu VERTO mają do dyspozycji gotowe do działania i przygotowane do uniwersalnego użycia podsystemy (building blocks). Podsystemy te zapewniają dostarczanie pewnych powtarzalnych funkcjonalności jak np. posiadanie numeru, posiadanie załączników, posiadanie dodatkowych cech, czy możliwość wyszukiwania pełnotekstowego. Komponenty te są przetestowane i gotowe do użycia, mogą zostać dołączone (mixin) na zasadzie kompozycji do wszystkich elementów systemu, także tych, które dostarczają twórcy spoza głównego zespołu deweloperskiego VERTO.
• Moduły uniwersalne – To moduły, które posiadają przekrojowe funkcjonalności w zakresie całego systemu. Najlepszym przykładem jest moduł Workflow, który pozwala na etapie tworzenia procesów używać jako budulca wszystkich elementów systemu z dowolnego modułu, a na etapie realizacji procesów wywoływania funkcjonalności tych elementów w tożsamy z obsługą systemu sposób. Pozwala to na pytania w rodzaju „ …napisałem swój plugin czy widoki i akcje mojego plugin’u mogą brać udział w procesach workflow? ” odpowiadać zawsze „tak”.
• API oparte o model – API imperatywne stanowi oczywiście bardzo popularny i podstawowy budulec mechanizmów rozbudowy systemu, jednak podejście MDA (Model Driven Architecture) pozwala podważyć tę dominację. Rozbudowa systemu o nowe funkcjonalności poprzez deklaracje, a nie poprzez imperatywy, wprowadza całkiem inną jakość w całym procesie rozbudowy, obniża koszty, skraca czas dostarczenia (Time To Market), zwiększa jakość rozwiązań oraz co ważne powoduje zauważalnie większy poziom integracji.
• Architektura oparta o komponenty – W tym przypadku można mówić wręcz o paradoksie architektury. Skoro dzielimy system na odrębne komponenty (components) z ustaleniem ich kanałów komunikacji (sockets), to powodujemy jakby zmniejszenie integracji z punktu widzenia całości. Jest to prawdą tylko do chwili kiedy zaczynamy te komponenty łączyć (links), ogromna moc tkwiąca w dobrze połączonych odseparowanych komponentach ujawnia się wielopłaszczyznowo. Od razu można zauważyć pozytywne zmiany dwóch podstawowych metryk: wzrost spójności (cohesion), przy jednoczesnym spadku zależności (coupling). Konkludując, paradoksalnie architektura taka pozwala osiągnąć zdecydowanie lepiej zintegrowany system, złożony z dobrze zdefiniowanych i skomunikowanych ze sobą komponentów.

Na koniec można zadać pytanie, czy powyższe mechanizmy aplikują się zawsze, czy zawsze warto stosować tego rodzaju rozwiązania. Odpowiedź nie może być twierdząca. Jako regułę bezwzględnie obowiązkową dla architekta systemów informatycznych i każdego innego architekta należy uznać konieczność uwzględniania kontekstu. Naszym kontekstem jest system klasy CRM/ERP, w tym kontekście zasada „dziel i zwyciężaj” stosowana w skali opisanej powyżej będzie dobrym rozwiązaniem, pozwalającym wciąż pozostawać w bezpiecznym zakresie złożoności esencjonalnej. Miejmy jednak świadomość, że dla innych kontekstów, małych aplikacji czy nieskomplikowanych systemów należy dostosować architekturę tak, aby unikać rozrostu nieuzasadnionej złożoności.