Zaginione elementy specyfikacji TOGAF

Nawiązując do znanego powiedzenie można stwierdzić, że “TOGAF jaki jest każdy widzi” (w szczególności, kiedy patrzy się na podręcznik liczący blisko 700 stron). Oznacza to, że ma on zarówno lepsze jaki i słabsze części. Wynika to z kilku czynników. Po pierwsze – zgodnie z założeniami twórcy TOGAF’a, czyli  The Open Group ma być on aplikowalny w dowolnej wielkości organizacji, dowolnej branży. Oznacza to, że musi być on na dosyć ogólnym poziomie szczegółowości. Jak pisałem w jednym z wcześniejszych wpisów na tym serwisie – TOGAF bardzie mówi co ma być zrobione, a nie jak. Dla części osób jest to poważna wada, bo spodziewają się “książki kucharskiej” – jak przygotować i wdrożyć podejście architektoniczne… Niestety nie ma tak prosto – sporo elementów w praktyce architektonicznej ma mocno kontekstowy charakter.

Po drugie TOGAF jest rozwijany przez Forum Architektoniczne (będące częścią The Open Group). W chwili obecnej skupia ono ponad 200 firm z całego świata. I jeżeli tylko nawet 20% z tych dwustu firm aktywnie bierze udział w tworzeniu TOGAF’a – to i tak jest to ponad 40 interesariuszy – mających bardzo różne doświadczenia z wdrażaniem podejścia architektonicznego. Przekłada się to niestety na niespójności w specyfikacji TOGAFa. Ale można na to spojrzeć również od drugiej strony – czyli te 40 firm dzieli się swoimi doświadczeniami – co działa, a co nie działa w budowie architektury korporacyjnej.

Trzecim czynnikiem jest długa historia TOGAF’a. Jego początki sięgają roku 1994, kiedy to członkowie The Open Group decydują, że to TAFIM (Technical Architecture Framework for Informationa Management), rozwijany przez Information Systems Agency Departamentu Obrony USA, będzie punktem startowym prac nad TOGAFem. W 1996 roku opublikowano pierwszą wersję TOGAFa (czyli bez mała to podejście architektoniczne ma 20 lat). Od tego czasu pojawiło się kilka istotnych wydań tego standardu –  w szczególności:

• 2002 – TOGAF 7 (wprowadzał on koncepcję architektury IT),
• 2003 – TOGAF 8  (wprowadzał on koncepcję architektury korporacyjnej),
• 2009 – TOGAF 9 (ostatnia duża edycja TOGAF’a).

W chwili obecnej obowiązuje TOGAF 9.1, który został opublikowany w 2011 r. Od dłuższego czasu przyjęto strategię ewolucyjnych zmian w specyfikacji. W praktyce oznacza to, że tylko nieduża część materiału jest wycofywana (aby zachować kompatybilność wsteczną), a dokładane raczej są wciąż nowe zagadnienia (widać to bardzo patrząc na specyfikację TOGAF 8 vs. specyfikację TOGAF 9 – wzrost objętości był dwukrotny). Niestety przy takim modelu prac nad TOGAF’em pojawiają się niespójności pomiędzy poszczególnymi  fragmentami (bardzo obszernej) specyfikacji.

Wreszcie ostatnim elementem mającym wpływ na kształt specyfikacji TOGAF”a jest bardzo partycypacyjny, bazujący na wolontariacie sposób prac nad jej rozwojem. Oznacza on, że poszczególne części TOGAF’a są aktualizowane/zmieniane, jeżeli zostanie to uznane przez członków Forum Architektonicznego za istotne/konieczne. Co więcej zostanie to zrealizowane – jeżeli będą dostępne zasoby członków Forum, które można delegować do tych prac.

Parę dni temu na LinkedIn (na grupie poświęconej TOGAF’owi) pojawiło się pytanie – jakie elementy TOGAF’a należy uznać za najsłabsze/brakujące/do poprawki/do dodania. Na bazie przeprowadzonej tam dyskusji sformułowano takie zestawienie. Poniżej przytaczam je (w trochę zmodyfikowanej przeze mnie postaci):

• Konieczność uspójnienia terminologii w ramach całej specyfikacji.
• Konieczność napisania TOGAF’a językiem zrozumiałym dla biznesu.
• Konieczność aktualizacji lub wycofania modelu referencyjnego III-RM.
• Konieczność aktualizacji modelu referencyjnego TRM.
• Konieczność przemyślenia podejścia do kwestii bezpieczeństwa.
• Konieczność przemyślenia podejścia do kwestii związanych z ładem architektonicznym (zwłaszcza w kontekście faz G i H cyklu ADM).
• Konieczność rozszerzenia materiału poświęconego wzorcom architektonicznym.
• Konieczność przemyślenia i aktualizacji metamodelu zawartości.
• Konieczność uporządkowania ról i ich odpowiedzialności w ramach ładu architektonicznego.
• Konieczność przemyślenia i przebudowania podejścia do kontinuum korporacyjnego.
• Konieczność zastanowienia się nad obszarem zarządzania danymi informacją w przedsiębiorstwie.
• Konieczność przemyślenia artefaktów (zwłaszcza diagramów) i sposobów ich modelowania.

Patrząc na tą listę można zadać sobie pytanie – czy w takim razie warto poświęcić czas i zasoby, aby oprzeć praktykę architektoniczną w organizacji na TOGAFie. Odpowiem tak – obecnie nie ma dobrej alternatywy dla TOGAF’a. Poza tym warto pomyśleć o ramach hybrydowych, łączących dobre pomysły z różnych podejść :).