Przyszłość integracji aplikacji leży w doborze specjalizowanych narzędzi, a nie uniwersalnych platform integracyjnych.

Być może za wcześnie o tym mówić. Większość firm w Polsce stoi przecież dopiero u progu poważniejszych projektów integracyjnych. Z drugiej strony, doświadczenia większych przedsiębiorstw - banków i firm telekomunikacyjnych - wskazują, że sam fakt ustanowienia interfejsów pomiędzy systemami nie wprowadza jako taki zasadniczej zmiany jakościowej w obsłudze funkcji biznesowych.

Tym, którzy jeszcze nie dotarli do tego etapu i nadal tkwią w galimatiasie interfejsów, sprzęgów, plików o karkołomnej strukturze, może się wydawać, że żądanie czegokolwiek więcej niż możliwość łatwej wymiany danych między aplikacjami to nadmiar luksusu. W końcu, gdy istnieje dobra podstawa, np. w postaci systemu kolejkowania i transformacji komunikatów, można na niej budować dowolne rozwiązania biznesowe. Problem tak naprawdę leży zupełnie gdzie indziej.

Gdzie ta uniwersalność

Firmy wykorzystujące dziesiątki aplikacji, takie jak banki czy operatorzy telekomunikacyjni, rzeczywiście potrzebują rozwiązania bardzo uniwersalnego. Budują infrastrukturę z myślą o wykorzystaniu jej do celów, których w chwili wdrożenia nie sposób przewidzieć. Gdy jednak, jak ma to miejsce w firmie handlowej czy usługowej, gdzie aplikacji jest raptem kilka lub kilkanaście i z dużym prawdopodobieństwem można zakładać, że nie będzie ich wiele więcej, należy się zastanawiać, czy warto wydawać niemałe pieniądze tylko po to, by zbudować wielki fundament pod mały domek.

Druga, nie mniej ważna sprawa to cel wymiany danych między systemami. Nawet najbardziej uniwersalna platforma kolejkowania komunikatów - uważana za sprawdzoną podwalinę wszelkich przedsięwzięć integracyjnych - nie będzie prawidłowo spełniać swoich funkcji stosowana do celów, do których nie została stworzona. Przykładowo, do replikacji dużych ilości danych między ośrodkami przetwarzania: podstawowym a zapasowym nadają się inne technologie, działające na innym poziomie architektury - zwykle na poziomie bazy danych, systemu plików lub jeszcze "niżej" - na poziomie systemów pamięci masowych. System kolejkowania komunikatów zazwyczaj nie nadaje się także do transportu danych z systemów transakcyjnych do systemów analitycznych. Jakkolwiek jest to możliwe co do zasady, wydajność - zwłaszcza w porównaniu z dedykowanymi rozwiązaniami ETL - nie będzie raczej zadowalająca.

Czy uniwersalna platforma integracyjna sprawdzi się jako rozwiązanie do połączenia systemu transakcyjnego z Internetem? Tak, ale głównie z systemami wewnętrznymi. Bezpieczna integracja z systemami partnerów handlowych czy klientów będzie wymagać znacznie więcej nakładów, a najlepiej dedykowanego środowiska portalowego. Podobnie będzie w przypadku systemów do synchronizacji informacji pomiędzy wieloma niezależnymi systemami źródłowymi, do przetwarzania potokowego (Straight Through Processing), obiegu dokumentów. Takie przykłady można by mnożyć.

Integracja po kawałku

Wszystkie te systemy można wykonać samodzielnie, budując kolejne warstwy wokół centralnego środowiska komunikacyjnego. Z biegiem czasu zbudowanym środowiskiem trzeba będzie w miarę efektywnie zarządzać - do tego trzeba stworzyć kolejne narzędzia. A skoro tak, to może by pójść krok dalej i wdrożyć platformę do zarządzania procesami biznesowymi? Gdy raz podejmie się decyzję, dywagacjom tego rodzaju nie ma końca. W konsekwencji, zamiast eliminować konkretne problemy, firma podchodząca do integracji purystycznie "od podszewki" brnie coraz dalej - ku mirażom.

A gdyby tak zapomnieć o wielkiej integracji i zamiast wielkich planów za wielkie pieniądze rozwiązywać konkretne problemy metodą małych kroków? Puryści będą oburzeni. Z reguły jednak to nie z ich kieszeni są finansowane niemające końca ani wyraźnie sprecyzowanego celu projekty integracyjne.

To nie oni ponoszą odpowiedzialność za ich fiasko.

Zamiast słuchać integracyjnych purystów, rozwiązujmy konkretne problemy, wykorzystując do tego celu dedykowane narzędzia. A jeżeli z biegiem czasu pojawi się inny problem, niech obsłuży go inne dedykowane narzędzie. Bo z rozwiązywania problemów - a nie z pogoni za niedoścignioną wizją uniwersalności integracji - dział IT rozliczą zarówno udziałowcy, jak i użytkownicy.

Owszem, w porównaniu z rozwiązaniem uniwersalnym koszty wdrażania systemów dedykowanych do obsługi określonych funkcji mogą być wyższe. Więcej wdrożonych produktów to m.in. więcej szkoleń dla pracowników i więcej oddzielnych umów serwisowych. Różnica polega jednak na tym, że wydatki poniesione na konkretne rozwiązania dają konkretne efekty, gdy tymczasem inwestycja w platformę jest jedynie obietnicą ich osiągnięcia.

Sprawy po imieniu

Warto zacząć myśleć o integracji w kategoriach korzyści osiąganych tu i teraz. Może nawet nie o integracji. Współczesne systemy informatyczne łączy się na różne sposoby, na różnym poziomie abstrakcji, z różną częstotliwością, słowo integracja stało się więc pojemne i wieloznaczne, a przez to różnie interpretowane. Sprawy trzeba wreszcie nazywać po imieniu: replikacja to replikacja, synchronizacja to synchronizacja, kopiowanie to kopiowanie itp. Precyzja pozwala unikać niedomówień. I nie pozostawia złudzeń.

<hr size=1 noshade>Z biznesowym zacięciem

Sybase od wielu lat działa na rynku integracji systemów informatycznych. Od dłuższego czasu klienci - a są nimi globalne firmy z branży finansowej, rynków kapitałowych, telekomunikacji i dystrybucji - dają nam do zrozumienia, że wdrażanie platform integracyjnych w ogóle ich nie interesuje. One chcą, żeby dostawca rozumiał i rozwiązywał ich problemy biznesowe.

Posłużę się przykładem naszego produktu replikacyjnego. Dopóki staraliśmy się sprzedawać go jako technologię, dopóty nie miał wielkiego wzięcia. Dopiero gdy udowodniliśmy klientom, że jego wdrożenie pozwala wykorzystywać na bieżąco aktualizowane kopie systemów głównych działające w zapasowym centrum danych do uruchamiania raportów i analiz OLAP, zrozumieli, że mogą sporo oszczędzić.