W praktyce organizacje stosujące “ramy hybrydowe” łączą dwa lub więcej podejścia metodyczne ze sobą. Dzięki temu uzyskują większą elastyczną w tworzeniu architektury i łatwiejszą akceptację koncepcji architektonicznych wewnątrz jednostki.

Proces doboru ram architektonicznych powinien odbywać się na samym początku budowy praktyki architektonicznej w organizacji i uwzględniać kilka czynników (począwszy od tego, czy dana organizacja stosuje na poziomie korporacyjnym/grupy kapitałowej określoną metodykę, aż po branżę w której organizacja działa – szczególnie prosto mają np. służby mundurowe, mogące garściami czerpać doświadczenia z NATO czy Wielkiej Brytanii oraz USA).

W celu ułatwienia poruszania się po gąszczu podejść architektonicznych – przygotowałem katalog ram architektonicznych – zawierający na chwilę obecną ponad 30 pozycji. Starałem się, aby każde z podejść miało odesłanie do strony, na której można znaleźć poszerzoną informację na jego temat.

Oczywiście, proszę o informację –  w komentarzu, albo za pomocą formularza, gdyby okazało się, że jakiegoś podejścia architektonicznego nie uwzględniłem.

Dodatkowo na przestrzeni lat widać bardzo niekorzystną tendencję, zgodnie z którą kryterium to dotyczyło coraz większej liczby zakupów – w roku 2007 było to 87%, a w 2008 – już  89% zakupów. Zupełnie odwrotna tendencja obowiązuje w innych krajach Unii Europejskiej, gdzie w ponad 50% postępowań o wyborze najkorzystniejszej oferty cena nie jest decydującym kryterium.

Takie nastawienie do formułowania kryteriów wyboru powoduje, że bardzo trudno przebić się z zastosowaniem rozwiązań zgodnych z architekturą korporacyjną. W wielu wypadkach okazuje się bowiem, że są to rozwiązanie droższe – przynajmniej na etapie ich wdrażania. Co z tego, że później byłyby potrzebne mniejsze nakłady na ich integrację z innymi rozwiązaniami, co z tego że łatwiej byłoby wprowadzać w nich zmiany, wreszcie co z tego że nie powodują one nieuzasadnionego wzrostu złożoności IT. Nie dostaną one szansy od organizacji – bo nie są najtańsze.

Problem wyboru „tanio teraz – drogo później” czy „drogo teraz i taniej później” jest bardzo często rozstrzygany na korzyść tego pierwszego wariantu (i dotyczy to nie tylko jednostek sektora publicznego, ale także przedsiębiorstw, które nie myślą kategoriami TCO).

Co można zmienić, żeby było lepiej?

Po pierwsze uświadamiać i edukować decydentów w organizacjach (publicznych). Że co prawda cena jest kryterium najwygodniejszym do zastosowania, ale w cale nie oznacza, że najlepszym.

Wprowadzić mechanizm motywacyjny (w przypadku tych organizacji, gdzie jest to możliwe), wiążący premię z wyborem tych systemów, które są w długim okresie czasu optymalne dla organizacji. Dzięki zachęcie finansowej urzędnik będzie chciał podjąć wysiłek dookreślenia dodatkowych kryteriów i przeprowadzenia bardziej złożonego postępowania (nie oszukujmy się, kiedy przychodzi NIK – zawsze łatwiej jest „obronić się” przed ewentualnymi zarzutami, jeżeli wskaże się, że wybrano ofertę najtańszą).

I wreszcie promować właściwe rozumienie dyrektywy 2004/18/WE Parlamentu Europejskiego i Rady z dnia 31 marca 2004 r. w sprawie koordynacji procedur udzielania zamówień publicznych na roboty budowlane, dostawy i usługi. Należy w szczególności zwrócić uwagę na definicję oferty najkorzystniejszej ekonomicznie (a nie równa się to przecież ofercie najtańszej). W dyrektywie tej podkreśla się znaczenie koncepcji „value for money”, co oznacza w praktyce wybór najlepszej oferty za określoną cenę. W dyrektywie tej (w artykule 53) wskazuje się także, że dodatkowymi kryteriami mogą być: jakość, koszty użytkowania, serwis posprzedażowy, wsparcie techniczne. Można tu także dodać koszty użytkowania z punktu widzenia całego cyklu życia systemu, a nie tylko na etapie jego wdrażania. Na pewno w tym zakresie może pomóc stosowanie zaleceń opracowanych przez Ministerstwo Rozwoju Regionalnego zawartych w dokumencie “Kryteria wyboru oferty najkorzystniejszej ekonomicznie – rekomendacje dla beneficjentów realizujących projekty indywidualne”.

Podsumowując: nie ma szans na upowszechnienie w polskiej administracji publicznej podejścia architektonicznego, jeżeli cena będzie jedynym kryterium wyboru ofert. Bo cóż z tego, że stworzymy przemyślane modele, uzyskamy ich akceptację ze strony decydentów organizacji, a i tak na koniec zakupione zostanie rozwiązanie najtańsze, które w bardzo nikłym stopniu uwzględniać będzie wytyczne architektoniczne.

Pozwoliłem sobie nie tylko przetłumaczyć główne punkty z tego opracowania, ale również w niektórych momentach rozszerzyć je i dodać własny komentarz. Zapraszam do lektury i do zastosowania działań zapobiegawczych w praktyce – zgodnie z zasadą zaczerpniętą z Kodeku Dobrych Praktyk Architektów Korporacyjnych – że osoby pełniące tą funkcję cały czas powinny się uczyć i doskonalić swoje działania.

• Koncentrowanie się na jednej domenie/obszarze.
  Zakres prac architekta korporacyjnego obejmuje wszystkie cztery domeny architektoniczne – tj: biznesową, aplikacji, danych, techniczną. Wielu architektów woli skoncentrować się w większym stopniu na jednej z domen, w porównaniu do pozostałych domen. Niektórzy architekci koncentrują się na domenie biznesowej architektury i pomijają szczegóły techniczne. Inni wolą odnosić się przede wszystkim do poziomu architektury technicznej, a nie uwzględniać aspektów biznesowych. Wreszcie część architektów ma swoje ulubione obszary organizacji, na których skupia swoją uwagę. Wówczas ich praca przypomina raczej działania architekta obszaru biznesowego (architekta domeny biznesowej) a nie architekta architektury korporacyjnej.
• Niedostosowana do odbiorców złożoność produktów architektonicznych.
  Modele architektury korporacyjnej nie są przeznaczone dla architektów korporacyjnych. Czasami zapomina się o tej oczywistości. Powoduje to, że powstają produkty architektoniczne, które mało kto jest w stanie zrozumieć, nie mówiąc o codziennym ich używaniu (i posługiwaniu się nimi przy podejmowaniu decyzji). Architektura korporacyjna musi być „sprzedawalna” zarówno sponsorowi prac architektonicznych (zwykle jest to poziom C-Level) jak i biznesowi na poziomie operacyjnym. Więc nie należy odnosić się z lekceważeniem do modeli prezentowanych za pomocą Power Pointa.
• Praca w izolowanej „bańce”.
  Architektura korporacyjna ma pomóc rozbić silosy – zarówno technologiczne jak i biznesowe. Niestety, zbyt często architekci korporacyjni sami pracują w silosie (architektonicznym). Podstawową rolą architektów korporacyjnych ma być wprowadzenie procesów ładu architektonicznego i objęcie nimi całej organizacji. To bowiem jej pracownicy muszą odgrywać aktywną rolę w definiowaniu modeli architektonicznych.
• Oderwanie procesów architektonicznych od działalności projektowej.
  Zdefiniowanie i stosowanie procesów ładu architektonicznego jest jednym z najbardziej wymagających aspektów zarządzania architekturą korporacyjną. Jest to również obszar, który jest najczęściej zaniedbany (zwłaszcza w jednostkach o mniejszej świadomości architektonicznej). Oceny zgodności z architekturą powinny być prowadzone dla wszystkich projektów. Bardzo ważne jest także, aby architekt korporacyjny brał bezpośredni udział w dużych projektach i inicjatywach. Dzięki temu buduje on swoją pozycję w organizacji i zapobiega to „oderwaniu się architekta” od rzeczywistości.
• Zaprzestanie działań architektonicznych.
  Części organizacji wydaje się, że wystarczy tylko raz stworzyć architekturę i na tym zakończyć. W praktyce takie podejście równa się wyrzuceniu pieniędzy w błoto. De-facto zarządzanie architekturą jest niekończącym się procesem – przypominającym drogę bez końca.
• Poszukiwanie srebrnych kul.
  Niektórzy architekci korporacyjni mają tendencję do rekomendowania pewnej klasy rozwiązań na rzeczywiste problemy organizacji w każdej sytuacji (bez względu czy ma to większy czy mniejszy sens). Często przybiera to formę modnego buzzwordu takiego jak SOA lub przetwarzanie w chmurze.
• Stosowanie żargonu.
  Większość architektów korporacyjnych jest zaznajomiona ze słownictwem stosowanym w ramach domeny IT (wywodzącym się np. z ITIL’a). Te standardy są świetne, o ile mówisz do innych architektów. Architekt musi umieć używać słownictwa, które jest zrozumiałe dla zdecydowanie szerszej części organizacji.

Oczywiście nie jest to pełna lista błędów popełnianych przez architektów korporacyjnych. Wydaje się także, że w przeciągu jednego czy dwóch najbliższych lat będzie ona ulegać zmianie. Wynika to z faktu coraz większej świadomości w tym obszarze.

Klasyfikacja ta została przygotowana w oparciu o wyniki prac Instytutu Pracy i Spraw Socjalnych, analiz Międzynarodowego Standardu Klasyfikacji Zawodów ISCO 08 oraz z wykorzystaniem materiałów Międzynarodowej Organizacji Pracy. Jest ona wydawana rozporządzeniem ministra właściwego do spraw pracy i jest przede wszystkim narzędziem do prowadzenia badań statystycznych i sporządzania analiz rynku pracy (także do porównań międzynarodowych). Klasyfikacja zawodów pozwala na prowadzenie badań, analiz i prognoz dotyczących rynku pracy oraz badań nad przemianami struktury społecznej w Polsce. Znajduje zastosowanie w prowadzeniu polityki zatrudnienia i przeciwdziałania bezrobociu, a w szczególności jest przydatnym narzędziem w pośrednictwie pracy i poradnictwie zawodowym. Jest niezbędna dla skomputeryzowanego systemu obsługi rynku pracy. Przydatna jest także dla określania i realizacji polityki kształcenia i szkolenia zawodowego, daje podstawę do planowania kierunków edukacji w formach szkolnych i pozaszkolnych, w oparciu o analizy i prognozy trendów na rynku pracy.

Należy zauważyć, że w tej chwili w klasyfikacji tej występuje 2360 zawodów, ale nie ma w niej zawodu zbliżonego do zadań przypisywanych architektowi korporacyjnemu. Występuje co prawda „architekt systemów teleinformatycznych”, ale występuje on w grupie zawodów „specjaliści do spraw technologii informacyjno-komunikacyjnych”. Z prowadzonych dyskusji (które zmaterializowały się m.in. w formie Kodeksu Dobrych Praktyk Architektów Korporacyjnych) wynika, że zawód architekta korporacyjnego powinien być przyporządkowany do grupy „specjalistów do spraw zarządzania i organizacji”.

Wydaje się, że takie oficjalne „wciągnięcie” architekta korporacyjnego na listę oficjalnych zawodów uprawianych w Polsce podniesie jego rangę (przynajmniej w niektórych typach organizacji) oraz co chyba bardziej jest istotne pozwoli na zaplanowanie programów kształcenia – zarówno na poziomie magisterskim jak i na studiach podyplomowych.

Na koniec pozwolę sobie przytoczyć fragment treści publikacji: „Oczywiście nie należy mylić włączenia zawodu do ewidencji, jaką stanowi klasyfikacja zawodów i specjalności z nadaniem uprawnień do wykonywania tego zawodu. Umieszczenie zawodu w wykazie oznacza jedynie, że nie jest to działalność prawnie zabroniona i jest grupa osób, która ją wykonuje”. Aż boję myśleć, co oznacza dotychczasowy brak wpisu zawodu architekta korporacyjnego na tą listę. Czyżby oznaczało to, że wykonujemy pracę prawnie zabronioną?

Zainteresowane wnioskiem osoby, zapraszam do kontaktu, prześlę im wówczas przygotowany wniosek. Będę wdzięczny za wszystkie ewentualne uwagi.

Mam nadzieję, że przy okazji kolejnej aktualizacji klasyfikacji zawodów i specjalności (wymaga to zmiany odpowiedniego rozporządzenia) uwzględniony zostanie już zawód architekta korporacyjnego. Oczywiście postaram się na serwisie na bieżąco informować o postępach prac w tym zakresie.

Mogą one dotyczyć np. zgody na uruchomienie nowego cyklu ADM (cyklu tworzenia i używania architektury – z ang. Architecture Development Method), zgody na wprowadzenie zmian w modelu docelowym organizacji czy wreszcie zaakceptowania zaproponowanych odstępstw i udzielenie tzw. dyspensy (z ang. dyspensation). Oczywiście, w zależności od kształtu procesów ładu architektonicznego (z ang. architecture governance) w konkretnej organizacji część z tych decyzji może podejmować Główny Architekt (jeżeli zmiany i odstępstwa w modelu architektonicznym spełniają określone kryteria – np. ich skutek finansowy jest mniejszy niż ….). Pozwala to, aby na Radę Architektoniczną trafiały zagadnienia mające charakter strategiczny, lub te, które związane są z rozwiązaniem sytuacji konfliktowej (np. na styku linii kierownik projektu-główny architekt).

Oczywiście Rada Architektury pracuje na materiałach, rekomendacjach i analizach przygotowanych przez Głównego Architekta i jego zespół (Biuro ds. Architektury Korporacyjnej).

Jednocześnie mogą być takie sytuacje, w których Rada nie jest skłonna samodzielnie podjąć decyzje (bo np. przekroczyłaby swoje uprawnienia) i przygotowuje finalne rekomendacje dla zarządu/ścisłego kierownictwa organizacji.

W tym miejscu warto odnieść się do artykułu D. Kahenman, D. Lovallo, O. Sibony „Zanim podejmiesz ważną decyzję” opublikowanego przez Harvard Business Review w marcu 2012 r. Menadżerowie wyższego szczebla (a tacy w większości organizacji są członkami Rad Architektonicznych) narażeni są na wypaczenie w procesie rozumowania – ze względu na pewne (mniej czy bardziej uświadomione) uprzedzenia i skłonności. Autorzy podają przykłady takich sytuacji. Jest to np. „błąd konfirmacji” polegający na ignorowaniu dowodów podważających ich przyjęte z góry założenia. Innym błędem jest „zakotwiczenie”, polegające na tym, że przy podejmowaniu decyzji nadawane jest zbyt duże znaczenie jednej, konkretnej informacji. Wreszcie niechęć do podejmowania strat, powoduje że decydenci są zbyt ostrożni. Taka sytuacja przekłada się na bezpośrednie wyniki finansowe organizacji. Jak wynika z badań przeprowadzonych przez firmę McKinsey te przedsiębiorstwa, które starają się minimalizować ryzyko podejmowania decyzji obarczonych uprzedzeniami mają zyski o 7% wyższe od innych organizacji.

D. Kahenman, D. Lovallo, O. Sibony we wspomnianym wcześniej artykule zaproponowali usystematyzowane podejście pozwalające wykryć i zminimalizować uprzedzenia i skłonności przy podejmowaniu decyzji strategicznych na bazie cudzych rekomendacji i rozstrzygania czy należy je przyjąć, odrzucić, czy przekazać do rozstrzygnięcia kierownictwu/zarządowi. Wydaje się więc, że może ono być bardzo pomocne w kontekście Rady Architektonicznej, która rozważa podjęcie kluczowych decyzji architektonicznych na bazie rekomendacji Głównego Architekta i może te rekomendacje przyjąć, odrzucić, lub delegować w niektórych sytuacjach na najwyższy poziom organizacji.

Zaproponowane podejście ma listę 12-tu pytań kontrolnych, które służą ujawnianiu pomyłek oraz błędów poznawczych w rozumowaniu Głównego Architekta i jego zespołu, Pytania zostały podzielone na trzy kategorie:

• pytania, na które Rada Architektoniczna sama musi znaleźć odpowiedź,
• pytania, które należy zadać Głównemu Architektowi,
• pytania dotyczące samej propozycji zgłaszanej przez Głównego Architekta.

Pytania, na które Rada Architektoniczna sama musi znaleźć odpowiedź:

1. Czy istnieją przesłanki, że Główny Architekt celowo przedstawił Radzie rekomendacje zawierającą przekłamania czy też opracował rekomendację zwierającą błędy chroniące jego interesy? Rada musi dokładnie przeanalizować otrzymany materiał i zwrócić w szczególności uwagę na ewentualny ponadnormatywny optymizm.
2. Czy Główny Architekt przygotowując rekomendację „zakochał się w niej”?. Rada powinna zwrócić uwagę, czy rekomendacja nie jest „naładowana” zbytnim ładunkiem emocjonalnym.
3. Czy w zespole Głównego Architekta pojawiły się różnice przy przygotowaniu rekomendacji, a jeżeli tak, to czy z należytą starannością zostały rozważone wszystkie alternatywy? Rada powinna wysondować delikatnie odmienne stanowiska.

Pytania, które należy zadać Głównemu Architektowi:

1. Czy na diagnozę sytuacji mogą wpłynąć istotne analogie o sytuacji z przeszłości? Należy poprosić o wskazanie przez Głównego Architekta co najmniej kilku innych analogi, gdyż jedna nie jest reprezentatywna.
2. Czy rzetelnie rozważano warianty alternatywne. Rada powinna otrzymać od Głównego Architekta rzetelnych opisów alternatywnych opcji.
3. Czy jeżeli Rada miałaby za rok podejmować dokładnie tą samą decyzję, to jakimi dodatkowymi informacjami chciałby wówczas dysponować i czy Główny Architekt może je już obecnie dostarczyć? W praktyce może okazać się, że takie pytanie pozwala dotrzeć do danych rzucających zupełnie nowe światło na rozważane zagadnienie.
4. Czy Rada wie skąd zaczerpnięto dane do przygotowywanych rekomendacji? Czy są to wyłącznie dane rzeczywiste, czy też są wśród nich informacje w nieuzasadniony sposób ekstrapolowane z historii? Czy Główny Architekt uległ zakotwiczeniu na jakiś tak uzyskanych danych?
5. Czy w propozycji Głównego Architekta nie wstępuje efekt „aureoli” – tj. czy podstawowy scenariusz nie jest zbytnio optymistyczny? Należałoby w tym momencie poprosić Głównego Architekta o następującą informację: „jakie organizacje podjęły zbliżone decyzje, a jednak nie osiągnęły zakładanych rezultatów”?
6. Czy Główny Architekt zbytnio nie przywiązuje wagi w swojej rekomendacji do decyzji podjętych w przeszłości? Należałoby rozważyć ją „na świeżo” – w szczególności pomijając np. już zaangażowane środki w dane rozwiązanie/projekt.

Pytania dotyczące samej propozycji zgłoszonej przez Głównego Architekta:

1. Czy rekomendacja Głównego Architekta nie jest przesadnie optymistyczna? Tj. czy nie powstała on jako wynik patrzenia prze „różowe okulary”? Niezbędne jest tutaj porównanie rekomendacji z możliwie analogicznymi przedsięwzięciami i efektami, które udało się osiągnąć w ramach ich realizacji. Można także zastosować technikę symulacyjną „gier wojennych”.
2. Czy rekomendacja Głównego Architekta nie lekceważy zagrożeń, które mogą się zmaterializować – tj. czy najgorszy „czarny scenariusz” jest „wystarczająco czarny”?. W celu zidentyfikowania tej słabości należy zastosować technikę diagnozy premortem – tj. Główny Architekt z zespołem powinien sobie wyobrazić, że stało się najgorsze i stworzyć historię, jakie były przyczyny zajścia tej najgorszej wersji wydarzeń. Można wówczas przygotować się do takiej sytuacji i podjąć kroki zaradcze.
3. Czy rekomendacja Głównego Architekta nie jest zbyt ostrożna? Może się okazać, że Główny Architekt boi się zaproponować rozwiązania, które byłby bardzo korzystne dla organizacji – ale trudne z jego punktu widzenia. Bardzo często przeważa bowiem niechęć przed potencjalnymi stratami/ryzykami (np. związanymi z nieudanym projektem) niż dążenie do osiągnięcia wyraźnej poprawy funkcjonowania organizacji. Jedynym rozwiązaniem takiej sytuacji jest zmiana systemu premiowania Głównego Architekta i jego zespołu – aby warto mu było ponosić zwiększone ryzyko.

Powyższa lista kontrolna powinna być stosowana w sposób systematyczny przez członków Rady Architektonicznej w kontekście przeglądów rekomendacji przygotowywanych przez Głównego Architekta (zakłada się tutaj całkowitą rozdzielczość osób podejmujących decyzję od przygotowujących rekomendacje). Pojawia się pytanie – czy taką listę kontrolną warto stosować – ze względu na czas i nakłady niezbędne do zaangażowania w taką ewaluację. Pozwolę sobie na to pytanie odpowiedzieć następującą historią, opisaną w książce A. Gawande „The Checklist Manifesto”: lekarze, który przyjęli tzw. Surgical Safety Checklist przygotowaną przez WHO i stosowali ja bardzo systematycznie (mimo, że wydawało się iż dotyczy ona rzeczy oczywistych i pojawiała się pokusa aby odejść od części jej zapisów), osiągnęli spektakularne sukcesy – tzn. redukcję liczby powikłań i zgonów pacjentów.

Tak więc, wydaje się że warto stosować przy ocenie rekomendacji architektonicznych przedstawioną check-listę.

Autorzy tego raportu we wstępie piszą, iż ma on dwa zadania:

• przedstawić w syntetyczny sposób informacje na temat stanu realizacji projektów dotyczących informatyzacji i cyfryzacji wchodzących w zakres kompetencji Ministerstwa Administracji i Cyfryzacji;
• zaprezentować kierunki dalszych działań w obszarze informatyzacji i cyfryzacji Polski, ze szczególnym uwzględnieniem działań na rzecz rozwoju i poprawy e-administracji.

Podkreślone jest, że w ramach polskiej administracji publicznej realizowanych jest obecnie ponad kilkaset projektów. W wyniki przeglądu znacznej części tych projektów (przeprowadzonego na potrzeby przygotowania raportu), okazało się, że większość z nich skażona jest:

• brakiem szerszej strategicznej wizji cyfryzacji państwa,
• koncentracją na zakupie sprzętu i technologii (zamiast na wsparciu świadczenia cyfrowych usług publicznych nakierowanych na potrzeby obywateli),
• koncentracją na perspektywie techniczno–sprzętowej, a nie perspektywie funkcjonalnej,
• petryfikowaniem silosów informatycznych (zamiast zapewnieniu przepływu informacji bez barier pomiędzy poszczególnymi jednostkami), co wynika między innymi z braku koordynacji realizowanych w administracji publicznej projektów informatycznych.

Zdaniem autorów raportu odpowiedzią na te bolączki jest wprowadzenie koncepcji nazwanej „informatyzacją zintegrowaną” działającą w oparciu o cztery podstawowe zasady:

• Informatyzacja musi być podporządkowana obiegowi informacji, a nie odwrotnie.
• Należy mówić o procesach w administracji publicznej i usługach jakie one zapewniają, a nie o projektach informatycznych.
• Wybrane i realizowane rozwiązania muszą gwarantować najlepszą możliwą relację wyników do zaangażowanych nakładów.
• Państwo neutralne technologicznie, gwarantujące obywatelom dostęp do cyfrowych usług, bez względu na wykorzystywanych przez nich system operacyjny/urządzenie.

Ponadto zdaniem twórców niezbędne jest wprowadzenie do administracji publicznej podejścia procesowego, a w szczególności zdefiniowania biznesowych właścicieli procesów, którzy określą zmiany merytoryczne i będą umieli dopasować do nich rolę konkretnych rozwiązań informatycznych (a nie odwrotnie jak jest to realizowane do tej pory).

Zdaniem twórców raportu „informatyzacja zintegrowana” powinna doprowadzić do powstania spójnego systemu informacyjnego państwa. Narzędziem pomocnym w realizacji tego zadania ich zdaniem jest wypracowania modelu architektury logicznej systemu informacyjnego państwa. Za tym powinno iść określenie oraz skatalogowanie usług, jakie dostarczają poszczególne bloki funkcjonalne oraz usług pożądanych, jeśli na tym etapie są znane. Od strony organizacyjnej zakłada się, że:

• do lipca 2012 r. przygotowanie zostaną warunki organizacyjne do wypracowania modelu architektury logicznej systemu informacyjnego państwa,
• do końca 2012 r. opracowany zostanie wstępny modelu architektury logicznej systemu informacyjnego państwa zorientowany na świadczenie e-usług,
• do roku 2020 opracowanie i podjęcie wdrożenia modelu architektury logicznej systemu informacyjnego państwa we współpracy z głównymi właścicielami e-usług, w zakresie niezbędnym z punku widzenia zarządzania oraz wdrożenie mechanizmów jego utrzymania.

W tym momencie należy zastanowić się czy podejście zaprezentowane w raporcie (a w szczególności opracowanie architektury systemu informacyjnego państwa) jest wystarczające.

Punktem wyjścia do udzielenia odpowiedzi na to pytanie jest stwierdzenie, że obecnie nie powinno mówić się praktycznie o projektach informatycznych (z drobnymi wyjątkami), lecz o projektach o charakterze biznesowym (merytorycznym) z mniejszym lub większym udziałem komponentów IT.

Po drugie nawet zakończony sukcesem projekt nie gwarantuje osiągnięcia założonych korzyści biznesowych. Wynika to z faktu, że projekt dostarcza do organizacji wyłącznie produkty (np. rozwiązania informatyczne). Bardzo często jednakże, produkty te nie są właściwie zaabsorbowane przez organizację (z zewnątrz wygląda to tak, że organizacja działa gorzej po wdrożeniu systemu niż przed jego wprowadzeniem). Dlatego raczej należałoby mówić kategoriami wartości publicznej (public value) dostarczanej przez programy (składających się z wielu skoordynowanych ze sobą projektów), które są realizowane w jednostkach sektora publicznego.

Wreszcie, w celu przełamania występujących obecnie problemów w zakresie modernizacji państwa i przygotowania jednostek sektora publicznego do cyfrowej transformacji, która będzie miała miejsce w nadchodzących latach (autorzy raportu piszą wręcz: „w najbliższych latach zmieni się zarówno rola, jak i sposób funkcjonowania instytucji państwa. Przed urzędnikami stoi wielkie i fascynujące zadanie: w roku 2030 administracja będzie musiała używać innych niż obecnie i dziś nawet trudnych do przewidzenia narzędzi do wykonywania swych zadań, do obsługi obywateli i współpracy z nimi”) nie wystarczy architektura systemów informacyjnych. Potrzeba jest pełna architektura korporacyjna państwa – koncentrująca się przede wszystkim na aspektach organizacyjno-legislacyjnych. Bez tego nie uda się zarówno „nowe otwarcie dla e-administracji” jak i budowa Polski Cyfrowej.

Podsumowując: wydaje się, że raport zawiera dość dobrą diagnozę “choroby nieefektywności” toczącej proces informatyzacji/cyfryzacji polskiej administracji publicznej, ale powinno być zaaplikowane mocniejsze lekarstwo (tj. zamiast architekturze systemu informacyjnego państwa, należałoby mówić o architekturze korporacyjnej państwa – jako narzędziu przygotowującym jednostki sektora publicznego do cyfrowej transformacji).

Tak, jak sygnalizowałem to podczas Forum, Kodeks ma stanowić swego rodzaju drogowskaz, jeżeli chodzi o rozwój praktyki architektonicznej w Polsce. Mam nadzieję, że przyczyni się on także do profesjonalizacji zawodu architekta korporacyjnego i wzmocnienia jego roli w organizacji.

Kliknij, aby pobrać kodeks.

Oczywiście nie jest to materiał zamknięty. Przypuszczam, że w przeciągu następnych kilku miesięcy zbiorę uwagi do powstałej wersji i na tej podstawie przygotowana zostanie jej aktualizacja.

PS. Wszystkie osoby, które są zainteresowane nieodpłatnym otrzymaniem drukowanej wersji kodeksu – proszę o kontakt za pomocą formularza.

Słowo “podręczną” jest celowo ujęte w cudzysłów, gdyż ma ona postać plakatu formatu A0 (niestety nie udało się go zmniejszyć, aby zachować czytelność).

Idea była bardzo podobna, jak przy materiale dotyczącym języka ArchiMate: pomyślałem, że wygodnie byłoby móc umieścić go nad biurkiem i korzystać z niego kiedy prowadzi się dyskusje na tematy związane z wdrażaniem architektury korporacyjnej. W związku z tym na tej płachcie przedstawiłem definicje wszystkich kluczowych pojęć TOGAF – tj. cykl ADM i jego iteracje, kwestie związane z ładem architektonicznym (w tym główne role i ciała), strukturę repozytorium architektonicznego, artefakty przyporządkowane do poszczególnych domen architektonicznych oraz definicje metamodelu zawartości.

Podczas tłumaczenia pojęć i definicji przyjąłem zasadę, aby jak najmniej zmieniać je w stosunku do pierwowzoru, ale też nie starałem się tłumaczyć ich “wyraz po wyrazie”, a raczej zachować ducha tych pojęć. Wszędzie tam gdzie było to możliwe sięgałem do oficjalnego tłumaczenia słownika pojęć TOGAF’owych).

Zapraszam do pobrania roboczej wersji plakatu.

Będę wdzięczny za Państwa uwagi/opinie – zarówno co do samego tłumaczenia jak i zasad dotyczących modelowania. Prosiłbym o ich przesyłanie albo w formie mailowej (za pomocą formularza kontaktowego), albo jako komentarza bezpośrednio pod treścią tego wpisu. Na tej podstawie przygotuję finalną wersję plakatu.

Po pierwsze, to przecież w dobrze prowadzonym repozytorium architektonicznym zapisane są nie tylko kluczowe decyzje architektoniczne (z uzasadnieniem kto i dlaczego je podjął), ale także (a może wręcz przede wszystkim) bezpośrednie przełożenie wiązki celów strategicznych na konkretne procesy, struktury, produkty, rozwiązani IT itd.

Ponadto architektura korporacyjna odzwierciedla teraźniejszość jak i przyszłość organizacji (często również ze stanami pośrednimi).

Pojawia się więc pytanie, czy taki zasób strategiczny może być zrealizowany przez firmę trzecią, a jeżeli tak to w jakim zakresie. Pomijam tutaj kwestie związane z bezpieczeństwem informacji zgromadzonych w repozytorium architektonicznym (chociaż mają one również bardzo istotne znaczenie – ale można zmniejszyć ryzyko w tym zakresie poprzez wprowadzenie odpowiednich zabezpieczeń techniczno-organizacyjno-prawnych).

Chciałbym głównie zwrócić uwagę na dwie inne rzeczy. Po pierwsze tylko bardzo nikła liczba firm konsultingowych zna tak dogłębnie biznes, aby móc zaproponować architekturę korporacyjną dla stanu docelowego organizacji. Oznacza to w praktyce, że architekturę korporacyjną będą tworzyć ludzie z organizacji, a konsultanci mogą ich wspierać jako tzw. „inteligentne długopisy” oraz jako nośnicy „dobrych wzorców” (z innych projektów, innych branż itp.). Bardzo często pracownicy konkretnej organizacji nie mają bowiem zasobów, aby w szczegółach zamodelować architekturę, a z praktycznego punktu widzenia mimo wszystko łatwiej jest odebrać produkty (modele architektoniczne) opracowane przez podmioty trzecie niż tworzyć je od zera. Za patologiczną należy jednak uznać sytuację, kiedy rolę Głównego Architekta pełni ktoś z firmy zewnętrznej (nie będący pracownikiem organizacji, a przynajmniej nie będący zatrudnionym na długim kontrakcie). Wynika to z faktu, że Główny Architekt jest osobą spinającą wszystkie prace architektoniczne i powinien mieć „w głowie” cały masterplan prac nad architekturą korporacyjną i powinien się z tym identyfikować. Należy w tymi miejscu doprecyzować jedną rzecz – jak najbardziej poprawnym jest zatrudnienie w określonych sytuacjach (np. podczas fuzji i przejęć) osoby z zewnątrz na Głównego Architekta – ale na etat lub w ramach innej długoterminowej formy współpracy.

Po drugie wydaje się, że architektury korporacyjnej nie powinni opracowywać konkretni producenci rozwiązań IT (oczywiście nie obejmuje to integratorów rozwiązań, którzy bazują na komponentach pochodzących od różnych firm). Z moich doświadczeń, obserwacji i rozmów wyłania się bowiem obraz, że architektura wówczas jest dopasowywana do konkretnych (tj. pochodzących od danego dostawcy) bloków budowlanych rozwiązań (solution building blocks) a nie na zasadzie „best of bread”. Jest to zaprzeczenie idei, która legła przy tworzeniu koncepcji zarządzania architekturą IT, polegającej na możliwości świadomego zarządzania przez Organizację rozwiązaniami pochodzącymi od różnych dostawców i łatwości ich integracji.

Jedynym wyjątkiem jest sytuacja, w której organizacja świadomie decyduje się na uzależnienie od produktów pochodzących z jednej firmy i jest to jasno wyartykułowane i przedstawione są tego wszystkie silne i słabe strony oraz szanse i zagrożenia (czyli zrobiony jest klasyczny SWOT takiej decyzji).

Pojawia się więc pytanie co można zlecać na zewnątrz w pracach architektonicznych? Na pewno pomoc w ustanowieniu praktyki architektonicznej – w tym w szczególności określenie ról, ciał oraz produktów architektonicznych. Warto także wspomóc się siłami zewnętrznymi przy definiowaniu przebiegu procesów architektonicznych. Na pewno przydatna będzie także pomoc zewnętrznych konsultantów przy wdrażaniu narzędzi informatycznych (np. repozytorium architektonicznego). Przy czym w tym ostatnim wypadku warto wcześniej ustalić metamodel zawartości (content metamodel) – aby być suwerennym w podejmowaniu decyzji nt. kształtu repozytorium, gromadzonych typów artefaktów i poziomu szczegółowości ich opisu. Innym zadaniem, które jest wręcz zalecane, aby realizował wykonawca zewnętrzny jest okresowa ocena dojrzałości architektonicznej. Wykorzystanie firmy zewnętrznej pozwoli na zachowanie obiektywizmu i wniesie świeże spojrzenie do praktyki architektonicznej.

Wreszcie ostatnim elementem, który bardzo często oddaje się w outsourcing jest zrealizowanie zaprojektowanej architektury – czyli dostawca zewnętrzny wykonuje w ramach projektów produkty, wynikające z opracowanego modelu docelowego. Oczywiście musi się to odbywać pod odpowiednim nadzorem architektów korporacyjnych poprzez wdrożenie niezbędnych mechanizmów ładu architektonicznego.

W szczególności należy wskazać tutaj relacje występujące na linii:

• architektury korporacyjnej i planowania strategicznego,
• architektury korporacyjnej i prowadzenia projektów i programów,
• architektury korporacyjnej i wytwarzania oprogramowania,
• architektury korporacyjnej i utrzymania systemów IT.

Do mniej rozpoznawalnych (co nie oznacza jednak, że mniej istotnych) związków zaliczyć można relacje na styku:

• architektury korporacyjnej i ciągłości działania,
• architektury korporacyjnej i zarządzania ryzykiem,
• architektury korporacyjnej i ładu IT,
• architektury korporacyjnej i działań zakupowych.

Relacje architektury korporacyjnej z jej otoczeniem można rozpatrywać na dwóch poziomach: ujęcia metodycznego oraz podejścia koncepcyjnego.

W pierwszym przypadku można podejść do integracji następujących podejść metodycznych (skoncentrowałem się na TOGAF, jako standardzie de-facto w zakresie ram architektonicznych):

• TOGAF a strategiczna karta wyników (Balance Scorecard),
• TOGAF a PRINCE2/PMI/MSP,
• TOGAF a RUP/metodyki zwinne np. SCRUM,
• TOGAF a ITIL,
• TOGAF a COBIT,
• TOGAF a MoR.

Zanim zejdzie się na poziom integracji podejść metodycznych o wiele ważniejsze wydaje się określenie relacji koncepcyjnych pomiędzy tymi obszarami. Poniższe rozważania będą rozważane z punktu widzenia podejścia architekturocentrycznego – tj. takiego, w którym architektura jest w centrum działań. Jest to jedno z możliwych podejść. Podejściami alternatywnymi są: usługocentryczność (czyli zarządzanie usługami jest w centrum działań) oraz zarządzanie przez portfel inicjatyw.

Z przeprowadzonych przeze mnie analiz wynika, że:

• Efekty planowania strategicznego powinny być wsadem do tworzenia architektury korporacyjnej, ale jednocześnie architektura korporacyjna powinna stanowić weryfikator realizowalności tworzonej strategii organizacji.
• Konkretne projekty i programy powinny być zarządzane przez Biuro Projektów i Programów, ale powinny się one wyłaniać z modeli architektury korporacyjnej (czyli de-facto najpierw powinien powstać model docelowy organizacji, którego realizacja zostanie następnie „rozpisana” na poszczególne projekty i programy).
• Architektura korporacyjna nadaje „ton” pracom programistycznym – tj. poprzez nią można określić wymagane standardy (np. integracyjne, w obszarze bezpieczeństwa itp.), sposób dokumentowania, zasady reużywalności. Z drugiej strony to konkretne prace programistyczne są najlepszym weryfikatorem stworzonych modeli architektonicznych (zwłaszcza w ramach architektury IT)  – na ile modele te uwzględniają rzeczywistość technologiczną.
• Aby rozwiązać określony problem zidentyfikowany na poziomie usług IT bardzo często trzeba wprowadzić modyfikację na poziomie architektonicznym; z drugiej strony każda zmiana przewidywana do realizacji powinna być oceniona, czy i w jakim zakresie ma wpływ na architekturę korporacyjną.
• Architektura korporacyjna (w szczególności usystematyzowana wiedza zawarta w repozytorium architektonicznymi i możliwość prowadzenia analiz wpływu typu „what-if”) jest bardzo pomocna przy planowaniu ciągłości działania organizacji i zarządzania ryzykiem – z tego względu podejście architektoniczne powinno być zintegrowane z korporacyjnym zarządzaniem ryzykiem (Enterprise Risk Management).
• Architektura korporacyjna jest bardzo dobrym narzędziem do definiowania przedmiotów zamówienia – pozwala bowiem na uzyskanie spójnej i kompletnej listy odpowiedzi na pytanie „co ma być zrobione” bez odpowiadania na pytanie „jak to ma być zrobione”. Na pierwsze pytanie odpowiada zgodnie ze sztuką architekt, na drugie – wyłoniony w drodze postępowania dostawca.

Podsumowując, należy zadać sobie jedno pytanie – skoro jest tak wiele potencjalnych obszarów synergii i współdziałania, dlaczego tak trudno jest to przełożyć na codzienną praktykę organizacyjną. Wydaje się, że odpowiedź powinna być udzielona wielopłaszczyznowo.

Po pierwsze – występują trudności (lub wręcz niespójności) terminologiczne. Każdy z tych obszarów (a przynajmniej każda z wiodących metodyk/ram w danym obszarze) wypracował się własnego słownika. W praktyce oznacza to, że zanim porozumieją się  TOGAF’owiec z ITIL’owcem w sprawie rozumienia np. terminu „usługa” czy też „aplikacja” muszą spędzić bardzo dużo czasu na wspólnym rozumieniu poszczególnych pojęć.

Po drugie integracja poszczególnych podejść metodycznych powoduje, że pojawia się stosunkowo złożony system zarządczy, wymagający sporej konsekwencji i dyscypliny. Nie każda organizacja jest w stanie w takich „karbach” działać.

Ostatnim czynnikiem (ale zgodnie z zasadą „last but not least” nie najmniej istotnym) są kwestie związane z formalną i nieformalną władzą w organizacji. Może się okazać, że część struktur organizacyjnych mających bardzo silną nieformalną władzę, musi ustąpić przed nowym porządkiem (proszę zwrócić np. uwagę jak zmienia się pozycja Biura Projektów i Programów w momencie kiedy wychodzimy od zarządzania portfelem inicjatyw/projektów, a kiedy wychodzimy od architektury korporacyjnej, a portfel projektów jest tylko pochodną architektury). Nie każdemu nowa rola i związana z tym pozycja w organizacji może odpowiadać.

Pojawia się pytanie, co można zrobić w takiej sytuacji? Z jednej strony architektura korporacyjna nie może być rozpatrywana jako samotna wyspa w organizacji. Jednocześnie wydaje się, że dochodzimy do miejsca, w którym poszczególne metodyki zaczynają zawłaszczać coraz większe fragmenty organizacji (proszę np. zwrócić uwagę na kierunek rozwoju ITIL – od zarządzania usługami IT do próby całościowego zarządzania usługami, w tym biznesowymi). Wydaje się, że nie jest to najwłaściwsza droga. Niezbędne jest raczej stworzenie „metodycznej platformy integracyjnej” łączącej poszczególne światy. Oczywiście nie mam tutaj na myśli konkretnego narzędzia informatycznego. Raczej chodzi o zidentyfikowanie punktów styku pomiędzy zasygnalizowanymi wcześniej podejściami metodycznymi i zaproponowanie mechanizmów harmonijnego ich współistnienia, aby zgodnie z zasadą „best of bread”, organizacja mogła stosować najlepsze/ulubione metodyki/ramy, a przy tym zapewniony byłby efekt synergii pomiędzy nimi.

Obecnie w ramach moich prac badawczych w Katedrze Informatyki Gospodarczej rozpocząłem prace nad projektem mającym na celu wypracowanie wzorców łączenia poszczególnych podejść metodycznych, co prowadzić ma do ładu metodycznego w organizacji. Zakładam, że punktem łączącym różne metodyczne światy będzie architektura korporacyjna i TOGAF. Tak więc w polu projektu będą takie połączenia jak np. TOGAF i ITIL czy też TOGAF a P30, ale i TOGAF a strategiczna karta wyników. W miarę możliwości będę starał się na serwisie ArchitekuraKorporacyjna.pl przedstawiać postępy realizowanych prac.