Jak rozmawiać z biznesem nt. TOGAF'a?

Truizmem jest stwierdzenie, że sztuką jest przekonanie organizacji do wdrożenia koncepcji architektury korporacyjnej. Ale dla mnie prawdziwym mistrzostwem jest wyjaśnienie biznesowi czym jest TOGAF i jak go stosować. Wpływa na to kilka czynników.  Po pierwsze TOGAF jest napisany w bardzo nieprzystępny sposób – nawet dla osób dobrze znających angielski (występuje bardzo dużo pojęć, które nie są intuicyjne). Co więcej “czuć”, że TOGAF został napisany przez informatyków dla informatyków (należy pamiętać, że TOGAF wywodzi się z TAFIM – tj. Technical Architecture Framework for Information Management, a do wersji 7.0 włącznie w TOGAF”ie mówiono wyłącznie o architekturze IT, dopiero od wersji 8.0 wprowadzono koncepcję architektury korporacyjnej).

Po drugie jest niezwykle obszerny (specyfikacja standardu liczy około 700 stron) i nie zawsze jest podzielona w logiczny sposób. Po trzecie wreszcie specyfikacja TOGAF jest miejscami niespójna (co do koncepcji i terminologii) i w niektórych obszarach mocno przestarzała (wynika to z historii rozwoju TOGAF’a jako standardu – pierwsza jego wersja pojawiła się już w 1996 roku – bez mała 20 lat temu).

To są minusy tego standardu. Jednak z roku na rok zyskuje on coraz większą popularność. Jeszcze 10 lat temu miał on 7% “rynku ram archtektonicznych” na świecie”, obecnie jego udział zwiększył się do blisko 60%. Nie można go więc ignorować. Niezbędne jest odpowiednie “sprzedanie” tego podejścia biznesowej części organizacji.

Oczywiście można stwierdzić, że bezzasadne jest wyjaśnianie koncepcji TOGAF’a departamentom biznesowym, bo one mają korzystać z architektury korporacyjnej (rozumianej najczęściej jako zbiór modeli), a nie są kompletnie zainteresowane narzędziem, które służy do stworzenia tejże architektury – czyli TOGAFa (na zasadzie: korzystam z samochodu bo chcę dojechać z punktu “A” do punktu “B”, ale nie muszę kompletnie rozumieć jak on działa). Ale często jest tak, że musimy przekonać przyszłych interesariuszy architektury korporacyjnej (np. na posiedzeniu jakiegoś komitetu sterującego) do wyłożenia pewnej sumy pieniędzy na kastomizację tegoż TOGAF’a. Po drugie biznes często chce wiedzieć, czy promowane przez architektów podejście (czyli TOGAF) jest sprawdzone “gdzie indziej” i że “u nas” – tj. w naszej organizacji ono też zadziała. Wreszcie, jeżeli chociaż częściowo uświadomimy biznes na jakiej zasadzie działa TOGAF (czym on jest, a czym nie jest – np. że nie istnieje coś takiego jak “architektura korporacyjna TOGAF”, albo że nie ma sensu kupować drukarek i wdrażać przy tym TOGAF’a) zdecydowanie łatwej będzie można prowadzić prace nad stworzeniem architektury.

Jak więc prowadzić z “biznesem” rozmowy nt. TOGAF’a. Ja najczęściej wykorzystuję do tego analogię. Miałem to szczęście, że moi rozmówcy wiedzą czym są modele referencyjne procesów biznesowych. Wówczas TOGAF’a porównuję do takiego bardzo ogólnego modelu referencyjnego – jak wdrożyć architekturę korporacyjną. Skoro jest to podejście referencyjne – to wówczas nie ma problemów z przekonaniem biznesu, że należy je zaadoptować do specyfiki konkretnej organizacji – bo przecież “każda organizacja jest inna, wyjątkowa”. Po drugie, stwierdzam, że TOGAF to taki “worek z prezentami od świętego mikołaja” dla architektów korporacyjnych i nie wszystkie prezenty są w danym momencie potrzebne. Za każdym razem staram się wybrać niezbędne minimum podejść zawartych w TOGAFie. Najczęściej są to role i odpowiedzialności związane z zarządzaniem architekturą korporacyjną (to biznes rozumie), następnie mówię, że potrzebne jest narzędzie informatyczne, w którym będą przechowywane informacje o architekturze (czyli repozytorium architektoniczne), wreszcie przedstawiam jakie dokumenty (produkty architektoniczne) powstaną i jaka jest ich rola. Najtrudniejsze do przekazania są procesy ładu architektonicznego – bo “biznes” intuicyjnie czuje, że jest to rodzaj kagańca dla jego działań.

W żądnym wypadku przy rozmowach nt. wdrożenia TOGAF’a nie używam takich pojęć jak: kontinuum architektoniczne, potencjał architektoniczny, metamodel zawartości (mimo, że są to fundamentalne koncepcje TOGAF’a). Kiedy nie przestrzegałem tej zasady – widziałem jak szybko tracę kontakt z rozmówcami i wówczas w organizacji “szła fama”, że pojawił się kolejny “konsultant-kosmita”.

Istotnie pomocne jest, jeżeli organizacja miała już wcześniej wdrożoną metodykę zarządzania portfelem projektów i programów lub metodykę zarządzania programami  (uważam, że niewystarczające jest, kiedy organizacja ma tylko zarządzanie  projektami). Wówczas część biznesowa organizacji rozumie korzyści płynące z działania bazującego na sprawdzonych standardach.

Bardzo dobrze w rozmowach z biznesem działają także przykłady organizacji, z Polski i ze świata, które oparły swoją praktykę architektoniczną o TOGAF’a. Bazuję tutaj zwłaszcza na wynikach badań, które przeprowadziłem w 2010 i 2012 roku w Polsce.

Oczywiście są tacy rozmówcy, którzy z góry twierdzą że “TO” nie ma sensu. Nauczyłem się, że wówczas należy podjąć próbę wyjaśnienia – co się rozumie przez “TO”. Najczęściej nie chodzi o TOGAF’a ale o samą koncepcję architektury korporacyjnej. I w drugiej kolejności okazuje się, że tak naprawdę zrządzanie architekturą korporacyjną ma sens, tylko że organizacja nie jest gotowa na takie podejście (chociaż bardzo by się ono jej przydało).