Jakiś czas temu moim światem zawodowym zawładnął trzyliterowy skrót SOA. Najbliższy czas upłynie mi zdaje się nad zgłębianiem sensu akronimu EA (akr. Enterprise Architecture). Kolejny akronim, o którym zaczyna się robić głośno… a może i było o nim głośno już od dawna, tyle że ja nie słyszałem, jako że stoję teraz nieco z boku, tj. w firmie która wdrożenia nowinek IT raczej kupuje a nie sprzedaje, w związku z czym nowinki te docierają do niej troszkę wolniej. W każdym razie wygląda na to, że potrzebuje rozeznać się nieco lepiej w temacie, co niniejszym wspólnie z wami czynię.
No więc cóż kryje się pod pojęciem Enterprise Architecture? Co to jest architektura IT wszyscy my – a więc profesjonaliści IT – dobrze rozumiemy. Architektura IT to sposób zorganizowania IT, tj.: komponenty IT, relacje między tymi komponentami oraz relacje komponentów z otoczeniem.
Architektura jest to – w ogólności – podział całości na części, ze zrozumieniem funkcji każdej z tych części i wzajemnych relacji poszczególnych części oraz relacji tych części ze światem zewnętrznym, a więc z tym co jest poza naszą całością.
A co to jest Enterprise? Enterprise to jest zbiór jednostek (firm, działów jednej firmy, oddziałów, agencji, itd.) mających wspólne cele i funkcjonujących jako pewnego rodzaju całość.
Enterprise Architecture jest więc podziałem na części korporacji. Próbą zrozumienia jak funkcjonuje korporacja i próbą planowego i celowego zarządzania zmianami w tejże korporacji, włączając w to, ale nie ograniczając się do IT.
Enterprise Architecture jest pomysłem na to, aby zanim przystąpi się do jakichkolwiek działań w obrębie IT, zastanowić się poważnie nad tym, po co te działania w IT miałyby być robione i jak to co ostatecznie będzie zrobione ma wyglądać.
Oczywistym jest, że rolą IT jest wspieranie funkcjonowania firmy w tym sensie, że powinno ono wytwarzać narzędzia ułatwiające to funkcjonowanie. Zanim przystąpimy do zastanawiania się, jak powinno wyglądać nasze IT, a więc zanim przystąpimy do rozważań nad Architekturą IT, powinniśmy zastanowić się, jak chcemy aby wyglądał nasz biznes, tj. nad architekturą biznesu, przedsiębiorstwa jako takiego. To jest właśnie sens EA. W sumie rzecz zdaje się dość oczywista, tyle że jak zwykle diabeł tkwi w szczegółach. Ważne jest, aby robić to w sposób systematyczny i planowy a co za tym idzie rozumny i celowy.
Dobrym zobrazowaniem idei EA jest pobieżne choćby przyjrzenie się metodzie TOGAF (The Open Group Architecture Framework). Po pierwsze, mówi się tam, że Architektura Przedsiębiorstwa to Architektura Biznesowa, Architektura Danych, Architektura Aplikacji i Architektura Infrastruktury IT.
Architektura Biznesowa to sposób funkcjonowania korporacji, a więc struktura organizacyjna, strategia biznesowa i kluczowe procesy biznesowe.
Architektura Danych to typy i źródła oraz cykl życia danych niezbędnych do funkcjonowania korporacji. Zauważmy, że to właśnie dane są najważniejsze. Aplikacje mają za zadanie jedynie wspomagać zbieranie i przetwarzanie oraz przeszukiwanie tych danych. To jakie to są dane i w jaki sposób są przetwarzane w dużym stopniu determinuje sposób konstrukcji oprogramowania, które te dane ma za zadanie przetwarzać. Architektura Danych jest łącznikiem pomiędzy Architekturą Biznesu i Architekturą IT.
Architektura Aplikacji to znaczna część tego co można rozumieć pod pojęciem Architektury IT. Jest to sposób organizacji oprogramowania, tj. podział na poszczególne aplikacje i integracja tych aplikacji tak aby wspólnie zapewniały zaplanowane przetwarzanie danych i wspierały istniejące procesy biznesowe.
Architektura Infrastruktury IT to rozwiązania techniczne zapewniające funkcjonowanie oprogramowania zgodne z przyjętymi założeniami i istniejącymi możliwościami.
TOGAF opisuje także metodę rozwoju architektury, tj. Architecture Development Method (ADM). Metoda ta złożona jest z kilku kroków kojarzących się z cyklem rozwoju oprogramowania, tyle że tylko część etapów związana jest bezpośrednio z oprogramowaniem.
Pierwsza faza metody ADM to w wielkim skrócie ustalenie kontekstu biznesowego i konsolidacja wokół inicjatywy wszystkich kluczowych interesariuszy.
W fazie drugiej tworzona jest wizja korporacji do której dążymy. Jest to kluczowy krok z punktu widzenia celowości pracy. W końcu każda praca rozwojowa powinna być nakierowana na osiągnięcie jakiegoś konkretnego celu mającego znaczenie z perspektywy korporacji jako całości. Jeśli miało by się na tym etapie okazać, że tak naprawdę nikt nie wie do czego omawiana inicjatywa dąży, to jest to bardzo dobra przesłanka, aby tej inicjatywy szybko zaprzestać.
Kolejny etap to opisanie istniejącej Architektury Biznesowej oraz Architektury Biznesowej docelowej, a więc tej do której dążymy. To na tym etapie zaczyna być widoczne, co trzeba będzie zrobić. Są to zmiany na poziomie procesów biznesowych, a więc trzeba to będzie jeszcze przełożyć na zmiany w IT, ale wstępny zakres tych zmian zaczyna być już widoczny. Nie zapominajmy też, że projekt IT to tylko część całego projektu, który może zawierać także takie elementy jak reorganizacja. Po tym etapie ma być wiadomym co trzeba zmienić w firmie, nie tylko w IT.
Dalsze etapy to właśnie rzutowanie zmian w biznesie na zmiany w IT, a więc opracowanie niezbędnego zakresu zmian Architektury Danych, Architektury Aplikacji i Architektury Infrastruktury IT oraz implementacja i wdrożenie tych zmian. Ten fragment pracy związany jest już stricte z rozwojem oprogramowania.
Już dawno zorientowałem się, że użyte technologie mają – paradoksalnie – najmniej decydujący wpływ na ostateczny rezultat projektu IT. Jeśli to nie technologia decyduje o powodzeniu lub porażce projektów technologicznych to w takim razie co? Właśnie sprawność zarządzania architekturą korporacji, bo takie zarządzanie i taka architektura w każdej korporacji istnieje, tyle że nader często jest to architektura niekontrolowana, powstała i zarządzana samorzutnie. Jeśli kogoś interesuje rozwój IT, to w pierwszym rzędzie powinien zająć się rozwojem architektury. Im szerzej pojęta architektura to będzie, tym lepiej.
