IT-centryczność TOGAF a architektura biznesowa

Ramy architektoniczne TOGAF wywodzą się z IT (pierwsza wersja TOGAF bazowała na TAFIM – Technology Architecture Framework for Information Management). Od wersji 8 rozwój TOGAFa został ukierunkowany w stronę architektury korporacyjnej (obejmującej oprócz aspektów IT przede wszystkim aspekty biznesowe organizacji – reprezentowane w postaci architektury biznesowej). Był to wyraźny postęp, gdyż wcześniejsze wersje TOGAF opisywały wyłącznie architekturę IT (na poziomie komponentów danych, aplikacji i infrastruktury IT).

Najnowsze wersje TOGAF (tj. wersje 9.0 i 9.1) starają się objąć całość korporacji i zwracają większą uwagę na biznesowe uwarunkowania działania organizacji (wprowadzając np. elementy planowania bazujące na potencjale – capability base planning). Jednak da się zauważyć, że niektóre aspekty modelowania biznesu wymagają ciągle dalszego rozszerzenia.

Dla osób pracujących w IT podejście proponowane w TOGAF jest naturalne. Kładzie ono bowiem bardzo istotny nacisk na IT (określane jest to mianem IT-centryczności TOGAF). Istnieje jednak wiele branż, w których IT nie jest głównym komponentem działania organizacji (np. przemysł, logistyka). Widoczne jest, że TOGAF nie kładzie nacisku na tego typu przypadki. Chyba najlepszym przykładem takiej sytuacji jest faza B cyklu ADM (Architecture Development Method)– tj. cyklu budowy i używania architektury korporacyjnej w organizacji (por rysunek 1). Według TOGAFa w fazie B należy przygotować architekturę biznesową (Business Architecture). Wydaje się jednak, że tak duży i rozległy temat został jednak potraktowany stosunkowo pobieżnie przez twórców ADM, podczas gdy architektura IT została rozpisana aż na dwie fazy cyklu ADM (C oraz D), wskazujące precyzyjnie jakie kroki i w jakiej kolejności należy wykonać aby uzyskać architektury danych, aplikacji oraz techniczną.

Rysunek 1. Cykl ADM (Architecture Development Method)
Źródło: The Open Group

Powoduje to, iż wbrew pozorom może okazać się, że opracowanie architektury biznesowej nie będzie łatwym wyzwaniem. W ramach jednej firmy znajduje się przecież wiele linii produktowych (ze swoimi wizjami, strategiami, itp.) które można uznać za podział wertykalny. Do tego dochodzą jeszcze podziały funkcyjne organizacji: sprzedaż, marketing, obsługa klienta (podział horyzontalny). Istnieją też funkcje wspierające: księgowość, finanse, kadry, administracja, raportowanie korporacyjne, itp. Bardzo trudno jest ująć te wszystkie aspekty w jednej spójnej architekturze. Wizja jednego działu wpływa przecież na wizje i sposób pracy innych działów.

Odrębnym zagadnieniem jest zaangażowanie ludzi z IT w tworzenie architektury biznesowej. Czy mają być oni tylko biernymi realizatorami pomysłów biznesu? A może wręcz przeciwnie powinni oni pokazywać, jakie nowe możliwości dostarcza współczesna informatyka w kontekście wprowadzania nowych produktów i usług biznesowych? Najgorszym wariantem byłoby chyba, gdyby swoje działania ograniczyli oni w fazie B jedynie do przedstawiania ograniczeń technicznych związanych z rozwiązaniami informatycznymi (na zasadzie: „tego nie da się, i tego też nie można…”).

Często wreszcie w ramach pracy nad architekturą zwrotnie można dowiedzieć się o uwarunkowaniach, które powodują, że dane rozwiązanie/aspekt architektury nie jest możliwy do zaimplementowania. Do tego należy jeszcze uwzględnić fakt ograniczeń wynikających z planowanej do zastosowania technologii. Aby zapewnić spójność całej architektury (począwszy od jej aspektów biznesowych po informatyczne) funkcja IT w organizacji w fazie B cyklu ADM mogłaby być traktowana jako kolejna jednostka biznesowa, która realizuje przypisane jej zadania poprzez zastosowanie podejścia usługowego. Wskazane powyżej elementy pokazują, że faza B może trwać długo i może okazać się być bardzo trudnym opracowanie efektywnej architektury biznesowej.

Aby ograniczyć te ryzyka TOGAF sugeruje podejście związane ze zmniejszeniem zakresu cyklu ADM albo poprzez przyjęcie wysokiego poziomu ogólności (tzw. architektury strategiczne/architektury segmentów), albo poprzez ograniczenie się do wybranego zakresu organizacji (nazywanego korporacją). W jednym i drugim przypadku nie da się jednak uniknąć konsultacji z pozostałymi jednostkami organizacyjnymi.

Po opracowaniu architektury biznesowej może zaistnieć sytuacja gdy w ramach prac nad dalszymi domenami architektonicznymi będzie potrzeba powrotu do fazy B (co może wynikać np. ze zmiany wymagań). Sam TOGAF nie zakłada możliwości powrotu jedynie do fazy B z pominięciem kolejnych faz (por. rysunek 2 przedstawiający iteracje ADM). Należy jednocześnie zauważyć, że sposób realizacji powrotu do wcześniejszych faz nie jest jawnie wskazany w TOGAF i pozostaje w gestii architekta.

Rysunek 2. Iteracje w ramach cyklu ADM (Architecture Development Method)
Źródło: The Open Group

Podsumowując jeśli w ramach prac nad wyborem ram architektonicznych zostanie wybrany ostatecznie TOGAF to należy pamiętać o tym że jest on ciągle IT centryczny i niektóre z jego elementów należy rozbudować o dodatkowe aspekty odnoszące się do specyfiki biznesowej organizacji.