Przewiduję powolne odchodzenie od idei systemów zintegrowanych na jednym modelu danych. Dotychczasowa ich zaleta czyli pełna (i zarazem trwała) integracja przestaje być zaletą a staje się garbem. System zintegrowany można już “skleić” ze specjalizowanych aplikacji, komponentów. Technologia komponentowa bardzo ten proces ułatwiła. Drugim powodem przewidywanego odejścia od tej idei są ogromne kłopoty z oceną rentowności wdrożenia systemu ERP. Nie raz jest to po prostu wręcz niemożliwe z powodu braku możliwości oceny jakim kosztem wspieramy pojedynczy proces biznesowy bo trudno z jednego ogromnego systemu wykroić koszt wsparcia pojedynczego procesu. Z tego też powodu rośnie zainteresowanie systemami typu middleware (szyny ESB). Do tej pory były wykorzystywane rzadko i dużych firmach, głównie w sektorze finansowym i głownie z uwagi na ich koszt. Obecnie rozwiązanie to staje się coraz popularniejsze. Dlatego?
Pojawienie się standardów w modelowaniu, ustanowienie modelowania pełnowartościowym etapem projektu (a nie ekstrawagancją), otwieranie się technologii, pojawianie się standardów wymiany metadanych i modeli, torują drogę do znacznego obniżenia kosztów i usprawnienia tworzenia systemów opartych o komponenty. To wszystko powoduje, że nie trzeba jednego wielkiego systemu zintegrowanego. Wystarczy tak zwany motor procesów biznesowych i specjalizowane systemy, mogą one pochodzić od różnych producentów i pracować na różnych platformach.
Jedyne czego trzeba przestrzegać to praca od samej góry: model biznesowy organizacji, model procesów biznesowych, struktura workflow (scenariusze działań czyli wewnętrzny opis procesów), lista oczekiwanych usług systemu IT i sam system składany z komponentów. Te trzy elementy: model biznesowy, model procesów, usługi IT stanowią pewną całość. Ubranie opisu usług w ciało to właśnie obiektowe/komponentowe technologie w IT, architektura SOA i MDA, języki i notacje BPMN, UML oraz format danych XML, obiektowe języki programowania.
Koniec quasimonopolu dostawców systemów
No i okazało sie, że standardy sprawdzone same się bronią. Microsoft w BizTalk Server będzie wspierał BPEL (Business Proces Execution Language, oparty na XML język skryptowy opisu procesów między innymi w systemach BPM i workflow management używany już między innymi w niektórych systemach CASE). Oracle także “rozumie” BPEL. Modelowanie staje się normą a otwartość standardem. Notacje UML i BPMN stają się standardem modelowania.
Co to znaczy? Moim zdaniem to, że powoli staje się coś o czym pisałem swego czasu na stronach IT-Consulting. Monopolistę zaczęli doganiać konkurenci. Monopolista zaczyna czuć pokorę: już nie wyznacza sam standardów de’facto (np. formaty plików dokumentów, narzędzia programistyczne, interfejsy komunikacyjne). Tracąc powoli rynek na rzecz rozwiązań konkurencji dostrzegł, że to co było przewagą rynkową (zamknięte rozwiązania) stało się w dalszej perspektywie hamulcem. Przyszła pora na otwartość i konkurowanie jakością a nie szantaż ponad 80% udziałem w rynku (vide współpraca Microsoft i Novell).
Kierunki rozwoju systemów IT
Albo analiza procesowa i obiektowa albo na margines życia. Coraz powszechniejsze zrozumienie idei zorientowania na procesy, interoperacyjności (w tym zarządzanie łańcuchami dostaw), architektury SOA (która moim zdaniem doskonale się wpasowuje w metody zarządzania zorientowanego na procesy i reorganizację w firmach) powoduje stawianie takich wymagań także dostawcom rozwiązań IT. Te które się do tego nie dostosują, moim zdaniem odejdą z rynku.
Model biznesowy firmy, informacje i dane jakich firma wymaga do sprawnego funkcjonowania to już jeden organizm. Stało się faktem, że żadna firma na rynku już nie będzie w stanie konkurować bez sprawnego zarządzania informacją. Do zarządzania informacją i przetwarzania danych zaś potrzebne są sprawnie działające i przede wszystkim łatwe w ich rozwijaniu systemy. Warunek taki spełniają obecnie zorientowane na procesy systemy tworzone w technologiach obiektowych.
Drugi warunek sprawności organizacji to optymalizacja jej wewnętrznej wydajności. Tu wkraczamy dla odmiany w zarządzanie i jego procesową naturę. Jak to pogodzić? Postrzegam tu właśnie miejsce dla architektury SOA. Firmę i jej miejsce w rynkowym łańcuchu wartości można, moim zdaniem, jednoznacznie opisać tylko za pomocą modelu procesowego zorientowanego na produkty. Zasoby (tu system IT) potrzebne do realizacji tej strategii analizujemy już obiektowo.
Namiastką takich opisów i analiz były procedury w księgach jakości ISO. Do pełnej analizy wymagany jest jednak opis (mapa procesów) uwzględniający cały obraz firmy. SOA to architektura wskazująca naturalny proces projektowania systemów IT: model procesowy firmy (organizacji), analiza procesów z perspektywy zasobów IT jakimi mogą być wspierane, na bazie tej analizy powstaje lista usług na rzecz procesów biznesowych jakich oczekujemy od nowego systemu.
Następnie w procesie analizy obiektowej usługi te transponowane są na model obiektowy przyszłego systemu IT. Analiza obiektowa powinna dać jako produkt także opis dziedziny systemu czyli reprezentację rzeczywistych obiektów w systemie. Jest to podstawa modelu danych dla powstającego systemu. Kolejne etapy to już projekt obiektowego programu (aplikacji) i jego implementacja.
