Trzy poziomy dojrzałości koncepcji architektury korporacyjnej

Do przygotowania tego wpisu skłoniły mnie rozmowy z przedstawicielami kilku firm, które były zainteresowane wdrożeniem u siebie elementów podejścia architektonicznego. Z rozmów tych wynikało, że utożsamiali oni architekturę korporacyjną z tworzeniem modeli. Ponieważ schemat podczas tych rozmów powtórzył się kilkukrotnie, dlatego stwierdziłem, że warto “w zarodku” spróbować wyjaśnić problem. Zacznę to tego, że architektura korporacyjna, jak każda idea/koncepcja – rozwija się i ewoluuje w czasie. I nie mówię tutaj od przejściu od “architektury IT” do architektury korporacyjnej (czyli dołączeniu do domeny aplikacji, danych i technicznej – czwartego elementu, jakim jest domena biznesowa). Chciałbym zauważyć, że bezpośrednio dla architektury korporacyjnej można zaobserwować co najmniej trzy poziomy dojrzałości.

Pierwszy z poziomów dojrzałości – związany z tworzeniem modeli architektonicznych zaczął się w momencie pojawienia się samej koncepcji EA i dominował na świecie do około 2004-2005 roku. Na tym etapie uważano, że można przygotować modele architektoniczne, które rozwiążą wszystkie problemy ;). Czyli architekturę korporacyjną utożsamiano z ustrukturalizowaną, skodyfikowaną wiedzą nt. organizacji, lub nt. jej wcześniej ustalonego zakresu. Oczywiście, to co się zmieniało przez te lata – to języki modelowania. Na początku była wykorzystana notacja strukturalna (wiem, że to może dziwne, ale w USA o architekturze korporacyjnej zaczęto mówić, zanim pojawił się UML), potem upowszechnił się UML, obecnie popularność zdobywa ArchiMate.

Drugi poziom dojrzałości pojawił się około roku 2006 i można powiedzieć, że trwa do dzisiaj. Zauważono bowiem, że same, nawet najlepsze, modele nie załatwią sprawy. Trzeba spowodować, że decyzje podejmowane z ich wykorzystaniem będą respektowane w całej organizacji. Tak narodziła się koncepcja ładu czy też nadzoru architektonicznego (architecture governance). Czyli architektura korporacyjna to już nie tylko modele, ale również całe mechanizmy ich wykorzystania (w rozumieniu procesów architektonicznych) wewnątrz organizacji i związane z tym role i ciała  (takie jak np. rada architektoniczna). Ten poziom dojrzałości koncepcji architektonicznej bardzo silnie adresuje również aspekty miękkie, kulturowe. Większość istniejących ram architektonicznych (np. TOGAF) pozwala na zbudowanie praktyki architektonicznej właśnie na tym poziomie.

Trzeci poziom dojrzałości dopiero teraz zaczyna się kształtować. Stwierdzono bowiem, że tradycyjne podejście do modelowania i ładu architektonicznego przestaje wystarczać. Po pierwsze organizacje wymagają coraz większej elastyczności/zwinności – a klasyczne EA nie zapewnia tego (albo bardziej precyzyjnie – nie zapewnia tego w wystarczającym stopniu, bez ponoszenia dużych nakładów). Po drugie coraz więcej elementów świata IT nie ma – jak do tej pory – postaci klasycznych systemów informatycznych, o zamkniętym zbiorze funkcjonalności – ale ma charakter dynamiczny – tj. np. bytów zwirtualizowanych, urządzeń mobilnych, dynamicznie uruchamianych funkcjonalności na platformach informatycznych, usług złożonych z usług atomowych itp… Jak docelowo ten poziom dojrzałości koncepcji architektonicznej będzie wglądał – sądzę, że dowiemy się o tym najwcześniej za 3-4 lata. Być może wykorzystane tutaj zostaną elementy symulacji, zaawansowanych wizualizacji [w tym w 3d], analizy sieciowej.

Powyższe rozważania dotyczą spojrzenia na koncepcję architektoniczną z perspektywy krajów Europy Zachodniej (m. in. Holandii, Belgii, Anglii), USA oraz Australii. W Polsce – stawiam tezę – że jesteśmy w większości organizacji na pierwszym poziomie dojrzałości koncepcji architektonicznych. Czyli wielu firmą (ale i konsultantom) wydaje się, że jak powstaną modele (w UML, BPMN, ArchiMate,… ) zawarte w repozytorium (bez względu na to czy to będzie narzędzie za 300 USD czy 3000 USD za licencję) to będzie to tożsame z wdrożeniem podejścia architektonicznego. Niestety – modele, repozytorium, raporty itp. są ważne – ale to warunek konieczny, a nie dostateczny, aby móc powiedzieć że nasza organizacja posiada architekturę korporacyjną.