Integracja: reaktywacja

Trudno oprzeć się wrażeniu, że integracja aplikacji jest niechcianym dzieckiem informatyki. Wydatki na integrację można postrzegać jako koszty naprawiania wcześniej popełnionych błędów. Gdyby jednak zapytać decydentów, czy są skłonni potroić koszty systemu, by w przyszłości mógł szybciej i prościej połączyć się z innymi systemami w przedsiębiorstwie, odpowiedź brzmiałaby - nie! Lepiej przyjąć, że integracja jest naturalną konsekwencją ewolucyjnego rozwoju informatyki w przedsiębiorstwie, które wzrasta organicznie. Jednak ostatnie osiągnięcia w tej dziedzinie każą jeszcze raz zapytać: czy na pewno ewolucyjne podejście jest właściwe? A może rewolucja, określana dziś hasłem Web 2.0, byłaby szybsza, tańsza i skuteczniejsza?

Trudno oprzeć się wrażeniu, że integracja aplikacji jest niechcianym dzieckiem informatyki. Wydatki na integrację można postrzegać jako koszty naprawiania wcześniej popełnionych błędów. Gdyby jednak zapytać decydentów, czy są skłonni potroić koszty systemu, by w przyszłości mógł szybciej i prościej połączyć się z innymi systemami w przedsiębiorstwie, odpowiedź brzmiałaby - nie! Lepiej przyjąć, że integracja jest naturalną konsekwencją ewolucyjnego rozwoju informatyki w przedsiębiorstwie, które wzrasta organicznie. Jednak ostatnie osiągnięcia w tej dziedzinie każą jeszcze raz zapytać: czy na pewno ewolucyjne podejście jest właściwe? A może rewolucja, określana dziś hasłem Web 2.0, byłaby szybsza, tańsza i skuteczniejsza?

Przez wiele lat terminem "przetwarzanie rozproszone" określano taką konfigurację, w której różne elementy tego samego procesu obsługiwane są przez różne systemy, potencjalnie - w różnych lokalizacjach geograficznych. Warto przypomnieć, że podstawy takiego przetwarzania oferował już w latach 90. standard CORBA. Jednak dojrzałość infrastruktury była długo niedostateczna, a ponadto brakowało komercyjnych zastosowań, standardów, a - nade wszystko - udokumentowanych korzyści dla przedsiębiorstw. Wśród dostawców zaś dominowało myślenie zawarte w słowie proprietary, czyli taka konstrukcja aplikacji, by dobrze i sprawnie współdziałały jedynie z aplikacjami tego samego dostawcy, a integrowanie ich z systemami pochodzącymi od innych dostawców było kosztowne i długotrwałe.

W ostatnich pięciu latach diametralnie się to zmieniło. Kluczowi gracze rynku informatycznego - począwszy od producentów ERP, poprzez dostawców baz danych, jak Oracle czy Sybase, aż po Microsoft - odpowiedzieli na potrzebę integracji systemów informatycznych w przedsiębiorstwach nie tylko pakietami aplikacji, ale i otwartą konstrukcją własnych produktów oraz wsparciem dla standardów. Jednocześnie rozwój technologii internetowych i ścisłe wprzęgnięcie Internetu jako narzędzia dla biznesu stworzyło masę krytyczną dla integracji.

Integracja: ściślej

A więc główny kierunek integracji AD 2006 to przede wszystkim ściślej. Wynika on z rosnącej skłonności przedsiębiorstw do przebudowy swoich procesów biznesowych i automatyzacji czynności z nimi związanych. Dziesięć lat temu, gdy w przedsiębiorstwach zaczęto stosować pierwsze systemy informatyczne, budowane były "pionowo" - dla komórek przedsiębiorstwa (sprzedaż hurtowa, mobilna czy internetowa; księgowość, zamówienia, produkcja). Dziś potrzebujemy systemów zbudowanych poziomo, wzdłuż ścieżek, jakimi przebiegają procesy biznesowe.

Charakterystyczna jest ewolucja komponentu finansowo-księgowego. W wielu przedsiębiorstwach (może nawet w większości) był pierwszym systemem informatycznym powszechnego użycia, niejako "jaskółką informatyzacji". Dziś przesunął się na drugi plan działań - duża część (często nawet zdecydowana większość) wpisów w księgach nie odbywa się ręcznie, a w wyniku eksportów offline i online z innych modułów. W dojrzałych systemach ERP popularna "efka" działa praktycznie całkowicie w tle.

Jednak firmy, które posiadają bagaż w postaci systemów informatycznych z tego czasu, muszą wykonać wysiłek, by je zintegrować.

Częściowo już to zrobiły - jedne systemy zasilane są przez inne danymi za pośrednictwem interfejsów, plików, procedur sięgających do baz... Do pewnego momentu taka układanka działa dobrze, potem zaczynają się problemy - systemy zaczynają bardzo mocno zależeć od siebie, stają się awaryjne i przez to droższe w utrzymaniu. Stopień komplikacji najlepiej oddaje potoczne określenie "architektura spaghetti". Splątany makaron jest co prawda smaczny, gdy zamawiamy go w restauracji, ale jako model architektury aplikacji w przedsiębiorstwach wywołuje zawsze ten sam skutek: jest niestrawny.

Integracja: taniej

Samo "ściślej" więc nie wystarczy. Trzeba jeszcze integrować, tak by korzyści z samej integracji nie zostały "zjedzone" przez koszty utrzymania interfejsów. Rozwiązania tego problemu trzeba szukać w koncepcji magistrali serwisów przedsiębiorstwa, czyli Enterprise Service Bus (ESB). Oznacza ona uwspólnienie wszystkich usług oferowanych przez systemy przedsiębiorstwa, skatalogowanie ich za pomocą standardów z rodziny web services (w szczególności chodzi o standard UDDI) i udostępnienie w wirtualnej przestrzeni dla użytkowników oraz wszystkich innych systemów. W ESB nie ma znaczenia, gdzie fizycznie znajduje się system i dane do niego oraz jaką technologią jest wykonany. Jeśli ktoś (człowiek, system) potrafi przesłać mu polecenie wykonania serwisu, który widnieje w katalogu, system go wykona.

Drugie zagadnienie z dziedziny kosztów integracji to refactoring. Najlepiej pokazać to na przykładzie: załóżmy, że dysponujemy środowiskiem mainframe, które w sposób absolutnie pewny, skalowalny i dojrzały - jak to tylko mainframe potrafi - obsługuje jakiś fragment procesów przedsiębiorstwa. System ma tylko dwie wady: jest bardzo drogi w eksploatacji ze względu na koszty infrastruktury oraz jest mało elastyczny. Ponieważ od niedawna dostępne są środowiska o podobnej dostępności i skalowalności jak mainframe, firma "przykrywa" istniejące środowisko za pomocą usług internetowych (web services), a następnie wymienia to co pod spodem - osiągając w ten sposób efekt zmniejszenia kosztów. Refactoring można porównać do remontu zabytkowej kamienicy: zostawia się fasadę i ściany, ale wszystkie układy, np. grzewcze, kanalizacyjne, elektryczne - wymienia się na nowe - sprawniejsze i tańsze.

Warto w tym momencie polecić wszystkim, którzy rozpoczynają projekt związany z integracją aplikacji, zapoznanie się z tematem wzorców integracji systemów (enterprise integration patterns). Będą nieocenioną pomocą podczas jej planowania i w konsekwencji pozwolą osiągnąć to, o czym marzy każdy CIO - dojrzałą, spójną, elastyczną i skalowalną architekturę systemów.

Integracja: szybciej, elastyczniej

Model TCO mówi, że jedynie około połowy rzeczywistych kosztów przedsiębiorstwa to koszty bezpośrednie. Druga połowa to koszty pośrednie, a wśród nich koszty utraconych korzyści. Ważną przyczyną, dla której przedsiębiorstwa nie są w stanie odpowiedzieć na sygnały płynące z rynku, jest brak elastyczności ich systemów. Głębokie oparcie procesów biznesowych na systemach uprościło funkcjonowanie organizacji, automatyzując pewne czynności, eliminując papier, zapewniając sprawniejszy obieg informacji, ale jednocześnie sprawiło, że wiele zmian w procesach, które wcześniej wymagały jedynie okólnika i szkolenia, dziś wymaga zmiany kodu źródłowego aplikacji lub interfejsów.

Integracja staje dziś przed nowym wyzwaniem: jak sprawić, że aplikacje będą jednocześnie bardziej powiązane, a z drugiej strony - paradoksalnie! - mniej od siebie zależne. Przez zmianę architektury chcą skrócić drogę "od pomysłu do przemysłu". I rzeczywiście, w tradycyjnej aplikacji klient-serwer, podlegającej tradycyjnemu cyklowi życia oprogramowania, droga ta jest długa. Od momentu stwierdzenia potrzeby, poprzez opisanie jej przez analityka i zaprojektowanie oraz zakodowanie go, aż po testy i ostateczne dostarczenie aplikacji użytkownikowi może minąć wiele miesięcy. Architektura ukierunkowana na usługi (SOA) połączona z lekkimi (agile) metodykami inżynierii oprogramowania zmienia ten cykl. Usługę modyfikujemy i walidujemy jej działanie nieomal jednocześnie i natychmiast, nie ma fazy dostarczenia oraz długiego i kosztownego cyklu wdrożeń (releases).

Porównajmy cykl rozwojowy oprogramowania dwóch gigantów: Microsoftu i Google. Microsoft raz na kilka lat wypuszcza następną wersję danego systemu lub grupy systemów; między tymi cyklami oferuje jedynie poprawki (service packs) lub dodatki (add-ons). Google działa zupełnie inaczej: nowe wersje oprogramowania oferowane są nawet kilka razy dziennie. Ponieważ ukryte są pod interfejsem internetowym, ich cykl życia i zmian nie jest nawet znany klientowi końcowemu. Ten ostatni po prostu obserwuje stałe, organiczne podnoszenie jakości i poszerzanie gamy usług. Każdy z nas musi odpowiedzieć sobie sam, który model biznesowy chce powielić.

Skrócenie cyklu rozwojowego oprogramowania i uelastycznienie go pozwoli przedsiębiorstwom na znaczne oszczędności, ale stale musimy pamiętać o kluczowym pytaniu w integracji aplikacji: jak wiele serwisów jest dzielonych pomiędzy aplikacjami i czy jest ich wystarczająco dużo, by nakład inwestycyjny na ich przykrycie interfejsem (np. SOAP) oraz opublikowanie na ESB zwrócił się przedsiębiorstwu z nawiązką? Na to pytanie nie ma odpowiedzi w ogólności - oto kolejne pytanie, na które każda firma musi odpowiedzieć sobie sama. Dla wielu SOA okaże się strategicznym kierunkiem rozwoju, dla niektórych odpowiedź będzie negatywna.

Web 2.0: czy to już czas na rewolucję?

I tak dochodzimy do koncepcji Web 2.0, której adwokatem jest m.in. Tim O'Reilly, znany publicysta i wydawca, którego wydawnictwo znane jest z serii książek informatycznych ze zwierzętami na okładkach.


TOP 200