Sam egzamin miał postać serii pytań testowych jednokrotnego wyboru (obejmujących praktycznie wszystkie aspekty ArchiMate – od notacji, widoków i punktów widzenia, mechanizmów rozszerzeń, aż po relacje z TOGAFem), dodatkowo była również część praktyczna dotycząca tworzenia modeli architektonicznych odnoszących się do konkretnego Case Study. Egzamin był przeprowadzony w języku angielskim i jak dowiadywałem się u źródła (tj. w The Open Group) nie ma w najbliższym czasie planów przygotowania jego polskiego odpowiednika.

Tak jak pisałem już wcześniej, sam ArchiMate w wersji 2.0 miał premierę podczas ostatniej konferencji The Open Group, która miała miejsce w ostatnim tygodniu stycznia 2012 r. Obecna jego wersja ukierunkowana jest na lepsze wsparcie TOGAF 9.x. Przy czym od samego początku notacja ta rozwijana jest w niezależnym Forum The Open Group (nie związanym z Forum Architektonicznym, opowiedzialnym za rozwój TOGAF). Jest to świadoma decyzja The Open Group, który podejmuje starania, aby z ArchiMate uczynić standard modelowania architektury korporacyjnej, niezależny od stosowanych ram architektonicznych (czyli stosując ArchiMate, nie musimy stosować TOGAF’a i odwrotnie – chociaż oczywistym jest, że na styku tych dwóch podejść pojawi się efekt synergii).

W ramach tego ostatniego zagadnienia zostałem poproszony do przygotowania wystąpienia pt. „Od architektury korporacyjnej do infrastruktury informacyjnej państwa”.  W jego tracie będę starał się wykazać, że sektor publiczny staje się obecnie właścicielem olbrzymich ilości informacji gromadzonych w postaci cyfrowej – zarówno ustrukturalizowanej jak i nieustrukturalizowanej. Pojawia się pytanie: co zrobić, aby zapewnić efektywny dostęp do tych informacji i móc świadczyć przy ich wykorzystaniu cyfrowe usługi publiczne. Odpowiedzi na to pytanie muszą udzielić decydenci odpowiedzialni za IT – zarówno na szczeblu całego państwa jak i poszczególnych jednostek publicznych. Postawię tezę, którą będę starał się obronić, że architektura korporacyjna państwa może im w tym pomóc. Można ją bowiem postrzegać jako mechanizm zarządzania cyfrową transformacją organizacji sektora publicznego i fundament budowy sprawnie działającej infrastruktury informacyjnej państwa.

Zapraszam do udziału w konferencji ( z pełnym jej programem można zapoznać się tutaj)!

Zagadnienie to zostało bardzo wyraźnie zaznaczone zarówno w języku ArchiMate oraz w TOGAF’ie. W celu poradzenia sobie ze złożonością modeli architektonicznych wprowadzone zostały tam dwa pojęcia: widok (view) oraz punkt widzenia (viewpoint).

Zgodnie z oficjalną definicją TOGAF widok został określony jako: reprezentacja zbioru powiązanych ze sobą trosk (concerns) interesariusza (interesariuszy). Przy czym troski zdefiniowano jako kluczowe obszary zainteresowania, które mają szczególne znaczenie dla danej grupy interesariuszy. Wskazano również, że widok nie musi mieć postaci graficznej (diagramu) – czyli w szczególności widok może mieć postać tabelaryczną lub macierzy.

Przykładem widoku może być raport wygenerowany z repozytorium architektonicznego dla osoby odpowiedzialnej za bezpieczeństwo w organizacji, w którym to raporcie odniesiono się wyłącznie do zagadnień związanych z bezpieczeństwem (zarówno na poziomie biznesowym jak i IT) – pomijając kwestie związane np. z efektywnością biznesową.

Natomiast punkt widzenia (viewpoint) definiuje perspektywę, z której ujmowany jest dany widok. Zawiera on informacje dla kogo (jakiego grona interesariuszy) dany widok będzie tworzony oraz jaka będzie przyjęta konwencja konstruowania i używania tego widoku. Czyli kontynuując wcześniejszy przykład, punkt widzenia określałby jakie informacje z repozytorium (i w jaki sposób przedstawione) powinny znaleźć się na raporcie dla osoby odpowiedzialnej za bezpieczeństwo.

Tak więc wdrażając repozytorium architektury korporacyjnej nie tylko trzeba określić jego strukturę oraz zdefiniować metamodel zawartości (content metamodel) ale również określić jakie będą potrzebne punkty widzenia i widoki dla poszczególnych grup interesariuszy. Za wykonanie tej pracy odpowiada architekt korporacyjny, który bardzo często musi godzić sprzeczne oczekiwania poszczególnych zainteresowanych.

Aby nie wymyślać „koła od nowa” w ArchiMate 2.0 zdefiniowano kilkanaście przykładowych punktów widzenia i na tej podstawie stworzono odpowiadające im widoki.

Rysunek 1 przedstawia przykładowy punkty widzenia nazwany „Punktem widzenia współpracy biznesowej” (Business Process Co-operation Viewpoint) .

Rysunek 1. Punkt widzenia współpracy biznesowej
Źródło: The Open Group 

Jego odbiorcą zgodnie z ArchiMate są głównie: architekci odpowiedzialni za warstwę biznesową oraz warstwę danych, a także menadżerowie operacyjni. Celem tego punktu widzenia jest: przedstawienie relacji pomiędzy głównymi procesami w ramach organizacji, mapowanie procesów biznesowych na funkcje biznesowe, wskazanie jakie procesy biznesowe realizują jakie usługi biznesowe oraz wskazanie współdzielonych danych. Oczywiście nie ma konieczności tworzenia tak skomplikowanego widoku.

ArchiMate zaleca stworzenie subwidoków. Przykład takiego subwidoku zawiera rysunek 2 (jest to przykład z branży ubezpieczeniowej).

Rysunek 2. Subwidok wygenerowany na podstawie punktu widzenia współpracy biznesowej
Źródło: The Open Group 

Użyte zostały na nim następujące typy elementów z punktu widzenia: rola biznesowa, proces biznesowy, usługa biznesowa oraz usługa aplikacyjna.

Ktoś może zapytać się jaki związek ma ta przypowieść z pracami architekta korporacyjnego. Nie prowadzi on przecież karet ;). Moim zdaniem architekta korporacyjnego można postrzegać jako piechura ostrzegającego osobę powożącą karetą – zaś rolę osoby powożącej karetą pełni najczęściej departament biznesowy organizacji (banku, firmy ubezpieczeniowej, firmy telekomunikacyjnej ale również jednostki publicznej). To najczęściej departament biznesowy chce “na szybko dowieść” rozwiązanie IT (mieć tzw. quic-wina), nie oglądając się na ostrzeżenia padające z ust architekta korporacyjnego – żeby nie robić rozwiązań “wiązanych drutem”, żeby uważać na standardy, żeby przestrzegać pryncypiów architektonicznych, żeby zgłaszać wszystkie zmiany i odstępstwa od modelu docelowego …. I co – i wówczas “biznes” patrzy na takiego architekta i mówi „co za idiota”, chce spowolnić prace, uniemożliwia osiągnięcie kwartalnych celów itp... Nie słucha go, i podejmuje decyzję o wdrożeniu rozwiązania IT, niezgodnego z przyjętą w organizacji architekturą, obowiązującymi standardami, pryncypiami. Bardzo często te prace są jeszcze przyspieszane na skutek podszeptów dostawcy zewnętrznego, który mówi tylko “miłe słówka” biznesowi – że architekci to hamulcowi, że tylko by się droczyli z biznesem bo chcą udowodnić swoją rolę w organizacji, bo my (tj. dostawcy) wdrożymy takie rozwiązanie 3x szybciej niż mówi to zespół architektoniczny i wewnętrzne IT.

Po pierwszych sukcesach, przychodzą jednak wyboje – okazuje się, że nowy system może i można było wdrożyć szybko (tak jak obiecywał zewnętrzny dostawca), ale zintegrować go z istniejącymi rozwiązaniami, to już nie za bardzo. Że nagle w naszej organizacji nie ma specjalisty od egzotycznej technologii, w które stworzono to nowe super rozwiązanie, a rozszerzenie go o nową funkcjonalność (wymaganą na cito przez regulatora) – oooo – tutaj dostawca zaczyna twierdzić, że owszem da się, ale na to potrzeba 2x większy budżet niż na pierwsze wdrożenie. No i nagle biznes  zaczyna przeklinać wszystkich i wszystko, a przede wszystkim… wewnętrzny dział IT (bogu winny w tej sytuacji). A architekt korporacyjny mówi “przecież uprzedzałem, Cię biznesie, abyś wdrażał wolniej, ale w systematyczny sposób, zgodny z podejściem architektonicznym”.

Pytanie tylko, czy biznes umie wyciągnąć właściwe wnioski (i oby nie był to wniosek zwolnienia architekta korporacyjnego z pracy ;) ).

BIAN i The Open Group razem przygotują przewodnik, którego celem będzie przedstawienie sposobu integracji  głównych elementów rozdzielnych do tej pory podjeść do budowy architektury korporacyjnej. Będzie to praktyczny dokument dedykowany dla architektów korporacyjnych pracujących w bankach i społeczności sprzedawców, którzy chcą czerpać korzyści z obu ram architektonicznych. Ich twórcy zauważają bowiem wyraźną synergię  w połączeniu krajobrazu usług  Bian (BIAN’s Service Landscape) z TOGAF. Podczas stosowania TOGAF w środowisku bankowym, BIAN przyspieszy i ułatwi pracę architektom poprzez zapewnienie specyficznych dla bankowości modeli referencyjnych. W drugą zaś stronę, TOGAF zaoferuje uporządkowane podejście do całościowego procesu projektowania i wdrożenia architektury korporacyjnej.

Członkami BIAN są m.in: Capital Banking Solutions, CGI, Commonwealth Bank of Australia, COREtransform, Credit Suisse, Deutsche Bank, Deutsche Postbank, FERNBACH, HCL Axon, IBM, ifb group, IKOR, Infosys, ING, innobis AG, kutxa, Microsoft, Rabobank, SAP, SunGard, Standard Bank of South Africa, SWIFT, Scotiabank Group, Temenos, UniCredit Group, Zürcher Kantonalbank.

Członkami The Open Group są m.in.: NASA, ING, Royal Philips Electronic, The Boeing Compan, IBM, HP, Microsoft, Accenture, Oracle, SAP, Capgemini, PWC, Ernst & Young.

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.

Zaczyna się wówczas rozglądanie na rynku narzędzi informatycznych, które mają wspomóc  gromadzenie informacji architektonicznych. Faktem jest, że obecnie można wybierać w bardzo szerokim spektrum systemów wspomagających pracę architektów. Występują rozwiązania open-source (typu: Archi, iteraplan czy też Essentials Project), rozwiązania low-costowe (typu: Enterprise Architect) – tj. cena licencji nie przekracza 1000-1500 zł za stanowisko, po systemy ze średniej półki cenowej (np. AdoIT) – tj. cena wynosi około 6000-7000 zł  za stanowisko, aż po bardzo drogie rozwiązania (np. Aris IT Architect, Troux, Alfabet czy też System Architect) – gdzie ceny zaczynają się od 10000 zł za stanowisko. Przy czym poszczególne narzędzia nie różnią się jedynie ceną. Każde z nich ma pewne wyróżniające je funkcjonalności. Część produktów doskonale sprawdza się jako proste narzędzie do tworzenia modeli (np. Enterprise Architect), część jest doskonała do prowadzenia symulacji i analiz (np. Abacus).

Aby ułatwić  poruszanie się po tym gąszczu narzędzi – w porozumieniu z ich twórcami uruchomiłem katalog narzędzi architektonicznych. Jest on dostępny na stronach serwisu ArchitekturaKorporacyjna.pl po kliknięciu tutaj.

Na chwilę obecną umieściłem w nim opisy (w kolejności alfabetycznej): AdoIT, BizzDesign Architect, Essentials Project, SAMU. W ciągu najbliższych kilkunastu dni pojawią się opisy Power Designera oraz Enterprise Architect’a.

Oczywiście będę starał się systematycznie rozszerzać opis narzędzi – w momencie jak tylko otrzymam informacje od ich producentów. Zapraszam do lektury.

PS. Przedstawiony na początku wpisu rysunek przedstawia rekomendowaną przez TOGAF’a w wersji 9.x strukturę repozytorium architektonicznego. Stopień zgodności narzędzi architektonicznych z tą rekomendacją może stanowić również jedno z kryteriów doboru rozwiązania (dotyczy to zwłaszcza organizacji, które planują oprzeć swoją praktykę architektoniczną na bazie TOGAF’a).

TOGAF w wersji 9 został opublikowany w styczniu 2009 roku, zaś w marcu 2009 roku uruchomiono oficjalnie program certyfikacyjny. Zgodnie z założeniami The Open Group (konsorcjum będącego twórcą TOGAF) można uzyskać dwa różne certyfikaty dla TOGAF 9: na poziomie 1 (tzw.  TOGAF Foundation) oraz na poziomie 2 (tzw. TOGAF 9 Certified). Pierwszy certyfikat ma potwierdzać, że osoba go posiadająca zna podstawy TOGAF 9, zaś certyfikat drugi ma świadczyć o tym, że osoba zna nie tylko  materiał zawarty w specyfikacji TOGAF 9, ale umie go również zastosować w praktyce. Czyli poziom pierwszy potwierdza posiadanie  informacji o TOGAF 9, poziom drugi – posiadanie wiedzy nt. TOGAF 9.

Od momentu uruchomienia procedury certyfikacji, liczba osób posiadających takie uprawnienie gwałtownie rośnie na całym świecie. The Open Group pod koniec stycznia 2012 roku przedstawił kilka interesujących statystyk. Poniżej zaprezentowano dwa wybrane wykresy. Na pierwszym z wykresów przedstawiony jest wzrost certyfikatów od samego początku do grudnia 2011 roku włącznie. Co interesujące, mimo że zdecydowanie trudniejsze jest uzyskanie certyfikatu na poziomie 2-gim, posiada go więcej osób niż certyfikat na poziomie 1-szym.

Drugi z wykresów przedstawia rozkład certyfikatów ze względu na kraje pochodzenia ich właścicieli (jest to stan na połowę stycznia 2012 roku). Skoncentrowano się na 10-ciu krajach, w których wystawiono największą liczbę certyfikatów (bardziej szczegółowo: wykres przedstawia 11 krajów, bo dwa z nich mają taką samą liczbę certyfikatów). Generalnie certyfikaty są  uzyskiwane w ponad 50 krajach.

Dociekliwy obserwator może zwrócić uwagę, że na powyższym wykresie nie ma Polski. Nie zmieściła się ona w pierwszej 11-ce. Z moich informacji wynika, że 90-ciu Polaków może pochwalić się posiadaniem jednego z dwóch certyfikatów TOGAF 9 (poziom 1 lub poziom 2), co stanowi 0.7% całości wystawionych na świecie certyfikatów.

Modernizacja państwa odbywa się poprzez realizację określonych przedsięwzięć, które mogą mieć charakter transformacyjny (głęboka zmiana organizacyjna, przebudowująca więcej niż jeden z podsystemów organizacji) lub dopasowawczy/doskonalący (są to zmiany o mniejszym zakresie i płytsze).

Przy czym architekturę korporacyjną państwa można wyrazić dwojako – tj. jako:

• architekturę korporacyjną na poziomie strategicznym, koncentrującą się na kluczowych dla Państwa przedsięwzięciach, ich zmianach w czasie oraz relacjach pomiędzy nimi (obejmuje ona zarówno modele architektoniczne na wysokim poziomie ogólności [w tym sposoby ich wytwarzania] jak i mechanizmy nadzoru architektonicznego);
• kaskadę architektur (od poziomu strategicznego – dla całego państwa, poprzez poszczególne segmenty funkcjonowania państwa, aż po architektury poszczególnych jednostek), obejmującą administrację publiczną (rządową i samorządową) – przy czym architektury niższego szczebla muszą być spójne z architekturami wyższego szczebla.

Jednocześnie warto wskazać na trzy wyznaczniki architektury korporacyjnej państwa:

• Architektura korporacyjna nie jest to zbiór nawet najlepszych modeli i opisów, ale mechanizm [narzędzie] wspomagający podejmowanie racjonalnych decyzji w organizacjach publicznych, uwzględniający całościowe (holistyczne) potrzeby modernizacji państwa.
• Architektura korporacyjna państwa umożliwia zburzenie „chińskiego muru” pomiędzy jednostkami administracji publicznej i odejście od „Polski resortowej”.
• Architektura korporacyjna państwa nie powinna być postrzegana jako zamach na samorządność lecz jako wsparcie dla samorządów – w celu zapewnienia skoordynowanych działań i racjonalizacji wydatków publicznych.

Przygotowałem narzędzie diagnostyczne, które pozwala dokonać własnej oceny, czy funkcjonujący obecnie w Polsce model zarządzania informatyzacją (szerzej: modernizacją z wykorzystaniem IT) organizacji sektora publicznego jest Pani/Pana zdaniem wystarczający oraz jaką rolę może pełnić architektura korporacyjna państwa w tych działaniach. Wykorzystanie narzędzia polega na udzieleniu odpowiedzi na 10 pytań. Pytania te należy traktować również jako inspirację do samodzielnych przemyśleń.

Udzielone odpowiedzi pozwolą na dokonanie klasyfikacji respondenta do jednej z czterech kategorii:

• zwolennik utrzymania status-quo w obszarze zarządzania IT w sektorze publicznym,
• zwolennik punktowych zwycięstw (quick-wins) IT w sektorze publicznym,
• zwolennik koordynacji prac w obszarze IT na poziomie poszczególnych projektów,
• zwolennik systemowego podejścia do zarządzania IT w sektorze publicznym.

Uwaga: wszystkie udzielone odpowiedzi są anonimowe. Nie zbieramy, nie przetwarzamy i nie przechowujemy żadnych z udzielonych odpowiedzi. Wynik udostępniany przez narzędzie poznaje jedynie osoba korzystająca z niego.

Zapraszam do skorzystania z narzędzia.