Temat cloud computing jest coraz gorętszy. Z jednej strony podgrzewają atmosferę firmy oferujące różne formy dzierżawy zasobów a z drugiej technologie i architektury zwane „chmurowymi”, prowadzą do stale malejących kosztów integracji (chmura prywatna).
Tak zwane technologie webowe (np. RESTful/REST API itp.) dotyczące integracji, powstały co prawda już nawet w 2000 roku, jednak dopiero teraz można mówić o dostępnych, przetestowanych bibliotekach, czyniących tego rodzaju projekty tańszymi, np. omawiane w artykule „Wymagania pozafunkcjonalne ? integracja” integracja z pomocą API to dzisiaj już taki sam koszt jak „spawanie” z pomocą SQL, wystarczy, że zatrudnimy kogoś (firmę) kto potrafi, a nie kogoś kto za nasze pieniądze będzie się dopiero zwinnie uczył, składając ofertę mimo braku kompetencji. Opór wielu firm przed przed tymi rozwiązaniami, z mojego doświadczenia, wynika z: braku wiedzy i kompetencji (wiele znanych firm IT nadal operuje metodami i technologiami z przed nawet 30 lat!), kurczowego trzymania się modelu biznesowego „dostarczamy jeden monolityczny system”, który silnie uzależnia klienta od dostawcy.
No i stosowanie metod opartych o tak zwane usługi „webservis”, wymaga całkowitego odejścia od metod strukturalnych projektowania (jednolite bazy danych w modelu relacyjnym i sterta funkcji) na rzecz metod obiektowych i komponentowych (Large system architecture).
Znamienne jest to, że gdy np. przeszukamy Internet pod kątem SOA, zobaczymy, iż w ostatnich kilku latach sporo publikacji poświęcono odejściu od tradycyjnego sposobu rozwoju systemów informatycznych ? od rozbudowanych rozwiązań autonomicznych do struktur złożonych z różnego rodzaju rozproszonych usług, ukierunkowanych na obsługę wybranych procesów biznesowych czy choćby pojedynczych działań. Równolegle, za Oceanem dynamicznie rozwija się Cloud Computing. Czymże innym jest to zjawisko, jak nie możliwością dobierania do organizacji (infrastruktury IT i modelu biznesowego) usług, które są niezbędne do efektywniejszej pracy (?do obsługi wybranych procesów biznesowych czy choćby pojedynczych działań?). I tak jak w ostatnich latach szyny integracyjne służyły integrowaniu wewnętrznej infrastruktury IT, tak w najbliższej przyszłości będą się rozwijać do łączenia również zewnętrznych usług z Chmury. (INTEGRACJA ROZWIĄZAŃ Z CHMURY TO WYZWANIE?).
Ja pisałem o tym już w 2011 roku (Biznes wychodzi ….).
Osobiście nie demonizował bym konieczności posiadania „szyny integracyjnej”, jak autorzy cytowanego powyżej artykułu (firma TIBCO jest dostawcą takiego produktu), jednak trend w kierunku rezygnacji z monolitycznych aplikacji już się zaznacza, a to czy taka „szyna” będzie, raczej jest konsekwencją architektury. Dobrze zaprojektowana architektura całego systemu aplikacji (komponentów) to struktura hierarchiczna: tak zwany „front end” to aplikacje, których odpowiedzialnością jest zarządzanie procesami, przepływem pracy (wprowadzanie danych i korzystanie z nich). Głębiej są dziedzinowe aplikacje stanowiące referencyjne składy i źródła danych. W takiej architekturze komunikacja (wywołania) jest jednostronna (zawsze mamy jasny podział usługobiorca-usługodawca. Szyny integracyjnej, jako dodatkowego komponentu, wymagają skomplikowane systemy i raczej dotyczy to większych korporacji, firmy naszego sektora MSP rzadko kiedy.
Internetowe metody integracji (np. wspomniany REST) to wymiana poleceń i obiektów a nie „funkcja vs. baza danych” (patrz wspomniany artykuł o integracji, dziwią mnie developerzy narzekający np. na „skomplikowane mapowanie obiektowo-relacyjne”, bo ono nie ma prawa być skomplikowane, a jeżeli jest, to jest to pierwszy sygnał, że to zły projekt!).
Tak więc chmury owszem, to chyba przyszłość, bez wnikania w to czy to chmury publiczne czy prywatne. Autonomiczne, duże systemy ERP? Nie wróżę im kariery, w obecnej postaci mega-aplikacje umrą, odwlekanie tej śmierci z pomocą perswazyjnych reklam i kampanii dużych korporacji i ich sprzedawców, to tylko sztuczne przedłużanie życia inwestycji w duże ERP, przez producentów tych rozwiązań, dawanie sobie czasu na (mam nadzieję) ich refaktoring. Mamy np. takie kolosy jak Google czy Amazon, które pokazują, że chmurowe, wysoce skalowalne architektury zasobowe mają sens. Systemy ERP oparte na relacyjnych bazach danych i ich wewnętrzna integracja poprzez współdzielenie danych, nie mają nawet szansy z tego skorzystać.
