Architektura korporacyjna a ryzyko

Jedną z podstawowych korzyści związanych z wdrożeniem koncepcji  architektury korporacyjnej w organizacji jest dostarczenie mechanizmów wspomagających  zarządzanie ryzykiem korporacyjnym (Enterprise Risk Management).

To dzięki architekturze korporacyjnej można np. przygotowywać analizy wpływu (określane popularnie nazwą analizy what-if)  i oceniać, jakie skutki na organizację może mieć zmiana poszczególnych procesów biznesowych (tj. na jakie zasoby informacyjne, dane, aplikacje oraz elementy infrastruktury będzie oddziaływać planowana modyfikacja danego procesu biznesowego) lub wręcz w drugą stronę – jak  potencjalna awaria elementu na poziomie infrastruktury technicznej (np. serwera) wpłynie na  funkcjonowanie aplikacji wykorzystywanych przy realizacji konkretnego procesu biznesowego. Oczywiście jest to tylko najprostszy przykład wykorzystania elementów architektury korporacyjnej w procesie zarządzania ryzykiem. Innym przykładem może być przygotowanie dedykowanych punktów widzenia (viewpoints) dla menadżerów ryzyka.

Z drugiej strony samo przedsięwzięcie budowy architektury korporacyjnej i wdrożenie tej koncepcji w organizacji wiąże się z pojawieniem nowych czynników ryzyka. Bardzo wyraźnie wskazuje na to TOGAF, który zaleca wręcz na samym początku każdego cyklu ADM (tj. cyklu tworzenia architektury korporacyjnej), w ramach fazy A (tj. tworzenia wizji architektury) oszacowanie czynników ryzyka – na dwóch poziomach. Pierwszy z poziomów nazywany jest początkowym  (bazowym) poziomem ryzyka, drugi zaś poziom określony jest poziomem rezydualnym (jest to poziom ryzyka po podjęciu działań mitygujących – tj. obniżających początkowy poziom ryzyka). Do decyzji Głównego Architekta należy określenie czy poziom ryzyka rezydualnego jest wystarczający, cz też niezbędne są dodatkowe działania, obniżające jego poziom.

Otwartym zagadnieniem pozostaje, jaka może być lista czynników ryzyka związanego z wdrażaniem koncepcji architektury korporacyjnej. Na podstawie doświadczeń własnych oraz analizy literatury można wskazać, że do ryzyk, które najczęściej się materializują zaliczyć można:

• odrzucenie przez organizację formalizmów, które związane są z wprowadzeniem ładu architektonicznego (architecture governance) – bardzo często tworzenie części rozwiązań IT schodzi “do podziemia”, byle nie trzeba było przechodzić “architektonicznej ścieżki zdrowia” – czyli departamenty biznesowe generują u siebie “shadow IT”, które tworzy im lokalne rozwiązania;  nie trzeba komentować jaki wpływ może to mieć na ciągłość działania biznesu, w momencie kiedy takie “shadow IT” odejdzie z organizacji i zostawi system bez kodów źródłowych i/lub dokumentacji;
• ignorowanie rekomendacji płynących z architektury korporacyjnej przez kluczowych interesariuszy – i to po obydwu stronach – tj. zarówno biznesowej jak i IT; jest to często dramatycznie widoczne w organizacjach, które NIE WIERZĄ w sensowność systemowego podejścia do zarządzania, a architektura korporacyjna jest dla nich jedynie modą;
• brak właściwego uwzględnienia kwestii związanych z bezpieczeństwem w planowanej architekturze korporacyjnej (dopiero na końcu prac bardzo często organizacja przypomina sobie o tej trosce); nie zawsze ludzie “od biznesu” są włączani na odpowiednio wczesnym etapie w działania architektoniczne – niestety, im później się to zrobi tym później jest uwzględnić ich wytyczne i/lub znaleźć jakieś rozwiązania kompromisowe;
• wzrost kosztów rozwiązań IT po wprowadzeniu architektury korporacyjnej (widać to zwłaszcza w pierwszym okresie wdrażania podejścia architektonicznego, gdzie następuje standaryzacja rozwiązań IT) – niestety porządek kosztuje od razu, za bałagan płaci się za jakiś czas; dodatkowo budowanie rozwiązań potencjalnie reużywalnych (zgodnych z podejściem architektonicznym) też jest droższe niż budowa rozwiązań nie uwzględniających tego paradygmatu;
• odrzucenie przez część interesariuszy rozwiązań wynikających z architektury – interesariusze ci wolą własne rozwiązania (często bardziej dostosowane do ich lokalnych potrzeb), niż rozwiązania “korporacyjne” – wystandaryzowane i tańsze w obsłudze, ale często pomijające specyficzne uwarunkowania danej jednostki;
•  opóźnienia w realizacji projektów poprzez tzw. paraliż analityczny – czyli czekanie aż powstaną wszystkie modele, zostaną one zatwierdzone i przekazane do realizacji; bez tego część jednostek nie chce rozpoczynać żadnych (nawet tych najbardziej pilnych) prac; opóźnienie prac w projektach może wyniknąć także z niedoszacowania potrzebnego zespołu architektonicznego na etapie uruchomienia procesów związanych z ładem architektonicznym (wówczas na tym etapie powstaje “wąskie gardło” w organizacji) – to nie jest problem, kiedy w organizacji jest realizowanych 10 równoległych projektów, ale przy 50-ciu robi się duży problem;
•  wprowadzenie dodatkowych zależności pomiędzy systemami używanymi przez różne departamenty – następuje to w imię likwidacji silosowości, ale kosztem zwiększenia stopnia powiązań pomiędzy systemami informatycznymi (przecież te systemy powinny być  re-używane) – czyli likwidując silosowość wprowadzamy większą złożoność;
• postawienie weto przez dostawców rozwiązań – do tej pory całą (lub zdecydowaną) wiedzę o dostarczanych rozwiązaniach mieli po swojej stronie – nagle zamawiający zaczyna chcieć ją przejąć – bardzo często reakcją obronną tych dostawców jest poniesienie opłat za dany produkt (na zasadzie: to wliczmy sobie koszty ryzyka, że nie my tylko firma trzecia będzie go rozwijać).

Na pewno lista ta nie jest pełna. Zapraszam do zgłaszania nowych pomysłów – na ich bazie będę starał się uzupełniać ten materiał.

Z drugiej strony przynajmniej część z tych czynników ryzyka świadczyć może o złym podejściu do wdrożenia architektury korporacyjnej w organizacji. Wówczas trzeba zastanowić się jakie, i w jaki sposób uruchomić działania naprawcze / wzmacniające potencjał architektoniczny organizacji.