lut
13

Architektura korporacyjna a ryzyko

Źródło: Andrzej Sobczak
Print Friendly

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.

Andrzej Sobczak

Profesor, kierownik Zakładu Zarządzania Informatyką w Instytucie Informatyki i Gospodarki Cyfrowej SGH. Ma ponad 8 letnie doświadczenie we wdrażaniu koncepcji architektury IT i architektury korporacyjnej. Posiada certyfikaty TOGAF 8/9, ArchiMate 2.0, ITIL, MSP.

Polecane wpisy

TAGI DLA WPISU

Dyskusja do artykułu “Architektura korporacyjna a ryzyko

  1. Świetna lista. Ze swojej strony mogę dodać z ryzyko zbyt szybkiej dezaktualizacji. Byłem już światkiem jak na omawianiu pierwszych modeli opisujących cześć z nich byłą już nieaktualna gdyż kilka departamentów działało zbyt samodzielnie. Ta samowola wynikała przede wszystkim z braku zrozumienia i odpowiednich decyzji już na poziomie zarządu co przekłada się na działy i departamenty. Drugie ryzyko to postrzeganie architekta korporacyjnego jako nadzorca galerników a w moim odczuciu to raczej sternik w osadzie wioślarskiej. Tu na nie korzyść działa zbyt mała wiedza o architekturze korporacyjnej. I trzecie ryzyko to nadmierne zaufanie ArchiMate i innym notacjom, które po zejściu na zbyt niski poziom abstrakcji są niemalże nie do utrzymania.

    • Witam, w pełni zgadzam się z zasygnalizowanymi przez Pana problemami. Pierwszy z nich można rozwiązać przez odpowiednio ustawione procesy ładu architektonicznego (tj. zmiana w organizacji MUSI przełożyć się na zmianę w modelach; powiadomienie o konieczności takiej zmiany wychodzi wówczas z departamentu inicjującego zmianę) + czuwanie nad całością zmian na poziomie Rady Architektonicznej (lub ciała pełniącego jej rolę). Nadzorca galerników vs. sternik – bardzo ładne określenia :). Pojawia się przy tym pytanie – czy sternikiem nie jest jednak komórka organizacyjna zajmującą się strategią (ew. zarząd) – a architekci korporacyjni odpowiadają za właściwe naoliwienie mechanizmów organizacyjnych. I wreszcie zastosowanie ArchiMate / UML i innych notacji – pełna zgoda – nie można stracić z oczu lasu i wejść w zbytnie szczegóły – ale czasami wymusza to niewyedukowany klient…

Dodaj komentarz

W celu wzięcia udziału w dyskusji jako zalogowany użytkownik możesz zalogować się poprzez jeden z poniższych serwisów.

Twój adres e-mail nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

Captcha Captcha Reload

Możesz użyć następujących tagów oraz atrybutów HTML-a: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>