Zadecyduje architektura

Zadecyduje architektura

W pierwszej z nich modelujemy procesy biznesowe generując diagramy z wykorzystaniem modułu graficznej wizualizacji BPM (Business Process Management). Gdy z kolei tworzymy zintegrowany system usług webowych na poziomie bazodanowym, NXJ generuje usługi (Web Service) odpowiedzialne za operacje SQL-owe dla wyspecyfikowanych tabel. Również i tu nie ma potrzeby klasycznego programowania "liniowego"; aplikacja jest generowana graficznie, podobnie jak w szeroko znanych pakietach 4GL. W fazie implementacji, także przy użyciu NXJ, generujemy maski dla użytkowników.

Nowy rynek dla architektury korporacyjnej

Zadecyduje architektura

Siatka Zachmana. Holistyczny model przedsiębiorstwa uzyskany na podstawie sześciu podstawowych pytań zadanych pięciu grupom użytkowników.

Tyle przykładów "z placu budowy". W ten sposób można informatyzować nawet spore firmy, ale EAM idzie krok dalej, proponując właśnie podejście "urbanistyczne", czyli wyjście poza wspomaganie poszczególnych aplikacji, a nawet procesów, w kierunku zintegrowanej syntezy całego krajobrazu IT przedsiębiorstwa w ramach zarządzania jego architekturą korporacyjną. Mamy tu do czynienia ze znanym postulatem: ze strategii przedsiębiorstwa (misja) wyprowadzić jego architekturę biznesową, na tej podstawie informacyjną i wreszcie przejść do technologicznej architektury IT i jej kolejnych poziomów - od warstwy aplikacyjnej do fizycznej (sprzęt, narzędzia software’owe). Metamodel EAM ma więc w sferze zarządzania podobne znaczenie jak model OSI (Open Systems Interconnection Reference Model) dla sieci.

Aktualnie na dynamicznym rynku EAM można znaleźć szereg narzędzi wspomagających tę metastrategię modelowania. Wymieńmy tu, przykładowo, takie rozwiązania jak: System Architect (Telelogic), Aris IT Architect (IDS Scheer), Troux (Troux Technologies) czy Planning IT (Alfabet AG). Już tylko analiza nazw pakietów i ich producentów rzuca światło na ich genezę. Telelogic jest powiązany z IBM, Aris od kilkunastu lat należy do standardów modelowania korporacyjnych systemów przetwarzania informacji (Architecture of Integrated Information Systems), z kolei Alfabet ma w zakresie BPM doświadczenia z międzynarodowymi koncernami jak np. Credit Suisse czy BMW. Podobne referencje (w zakresie SOA) posiada Troux (Austin, Texas, USA).

Geneza narzędzi EAM jest więc trojakiego rodzaju. Wywodzą się z modelerów dla architektów IT lub bazują na pakietach BPM, stąd naturalna możliwość rozszerzania ich funkcjonalności o reguły EAM. Trzecią możliwością jest zestaw o charakterze metamodelera, umożliwiający integrację innych narzędzi (edytory graficzne). Mówimy tu wszakże o nowym rynku, który trudno jest kategoryzować. Przykładowo, w sferze ERP mamy wysoko zintegrowane pakiety software’owe. W obszarze EAM ten stopień integracji jest z naturalnych powodów mniejszy. Nawet tak złożone aplikacje jak ERP są bowiem tylko częścią krajobrazu EAM.

EAM w praktyce

Jak zatem implementować EAM w praktyce? Przede wszystkim należy pamiętać, że kluczowym elementem tej metodyki jest prawidłowe modelowanie środowiska biznesowego, a więc semantyczna integracja sfery technicznej i użytkowej. Przedsiębiorstwo, które systematycznie stosuje dobre praktyki zarządzania w odniesieniu do swoich procesów, może łatwiej przejść do EAM - o ile posiada aktualizowaną dokumentację procesów. I nie chodzi tu tylko o techniczne komentarze umieszczane w kodzie źródłowym oprogramowania, ale o modele przepływu danych, struktogramy czy choćby sensowne schematy blokowe. Ważna jest bowiem spójność zawartej w nich wiedzy - tę da się transformować do form przewidzianych przez współczesne standardy modelowania - np. UML (Unified Modelling Language) - i dalej, do obszaru modeli referencyjnych ładu korporacyjnego.

A tych ostatnich jest wiele. Wymieńmy tu takie jak: COBIT (Control Objectives for Information and Related Technology), PRINCE czy ITIL (IT Infrastructure Library). Formalnie, na podstawie siatki Zachmanna skonstruowano TAFIM (Technical Architecture Framework for Information Management), który z kolei stał się podstawą dla TOGAF-u (The Open Group Architecture Framework) charakteryzującego się typowymi elementami EAM:

  • podejście holistyczne, dokumentujące struktury organizacyjne;
  • orientacja celowa (goal orientation) integrująca procesy gospodarcze oraz IT;
  • referencyjna formalizacja (obiekty i relacje).

    W tym ostatnim przypadku można korzystać z katalogów problemowych (pattern) dla tworzenia kart software’owych (viewpoint) i klastrowych (cluster).


TOP 200