Kim jest architekt – czyli o nieporozumieniach przy braku określenia odpowiedzialności
Kwiecień 23, 2011
W połowie kwietnia miałem okazję wziąć udział w konferencji poświęconej architekturze w przedsiębiorstwach. Sama nazwa konferencji – Forum Architektów IT [1] – sugerowała, że będzie to spotkanie architektów, na którym przedstawiciele przedsiębiorstw i firm doradczych prezentują własne przemyślenia i pomysły na szeroko rozumianą architekturę w przedsiębiorstwach.
Choć w nazwie konferencji pojawił się skrót „IT” to zakres tematyczny oscylował pomiędzy architekturą IT i architekturą korporacyjną. Prelegenci czasami zbyt łatwo mówiąc o architekturze korporacyjnej faktycznie omawiali wyłącznie obszary IT działania przedsiębiorstwa. Przysłuchując się kolejnym prezentacjom zaczęło mnie zastanawiać, czy na pewno wszyscy rozumiemy różnicę pomiędzy jedną a drugą architekturą i czy nie żonglujemy rolami architektonicznymi zbyt dowolnie. Później okazało się, że to odczucie nie było pozbawione podstaw.
Po zakończeniu części wykładowej (prezentacyjnej), rozpoczął się krótki panel dyskusyjny prowadzony przez publicystę poczytnego magazynu. Do udziału w którym zaproszono część osób wcześniej wygłaszających prezentacje oraz dodatkowo przedstawicieli komórek architektonicznych w kilku przedsiębiorstwach.
Prowadzący zadał wówczas pytanie – Kim jest architekt IT? W tym momencie rozpoczęła się pełna nieporozumień wymiana myśli pomiędzy prelegentami, z których każdy podawał inną definicję roli architekta (IT/korporacyjny/inny?). To co zaczęło zastanawiać mnie w trakcie prezentacji teraz zaczęło być co najmniej niepokojące. Padły między innymi takie spostrzeżenia prelegentów:
- architekt (IT/korporacyjny/inny?) jest jak architekt cywilny – to co stworzy może przetrwać lata a jego nazwisko będzie znane,
- architekt (IT/korporacyjny/inny?) nie ma prawa zablokować realizację projektu,
- rola architekta IT może kiedyś przekształci się w rolę architekta korporacyjnego,
- rolą architekta jest tworzenie standardów.
Włączyłem się do dyskusji i zwróciłem uwagę na próbę definiowania pojęcia „architekt” przy jednoczesnym braku określenia o jakiej faktycznie roli dyskutują prelegenci. Po kilku bezowocnych próbach uzyskania jednoznacznej odpowiedzi o kim dyskutujemy uzyskałem odpowiedź od jednej z osób, że właśnie próbują to ustalić. Ustalić coś nie podając warunków brzegowych jest co najmniej postawą zaskakującą zwłaszcza w ujęciu dyscyplin wywodzących się ze świata inżynierii oprogramowania.
Skąd te nieporozumienia? Zarówno organizatorzy jak i prelegenci w swych przedsiębiorstwach używają pojęcia architekt do opisu ról, którym to rolom przydzielone są inne obowiązki i przełożenie. Na początku dyskusji nikt z uczestników wyraźnie nie zdefiniował o jakich rolach architektonicznych ma być mowa, chociaż prowadzący w pytaniu wskazał na architekta IT. Nieporozumień było coraz więcej. Dodając do tego, że uczestnicy widzą architekturę inaczej z uwagi na doświadczenia własnych przedsiębiorstw pojawiło się nawet stwierdzenie, jakoby architekt był artystą. Całe szczęście, że szeroko rozumiani architekci w przedsiębiorstwach artystami nie są bo wówczas aplikacje i systemy informatyczne zaczęłyby przypominać kościół Sagrada Familia w Barcelonie – ciekawy z zewnątrz i nieskończony od kilkudziesięciu lat. No i wciąż niemożliwy do pełnienia swoich podstawowych funkcji.
Spróbujmy usystematyzować to co próbowano ustalić w trakcie konferencji. Ról architektonicznych, które występują w przedsiębiorstwach może być nawet kilkanaście, np.
- Architekt biznesowy,
- Architekt aplikacji,
- Architekt infrastruktury,
- Architekt IT,
- Architekt domenowy,
- Architekt linii biznesowej,
- Architekt rozwiązania / projektu,
- Architekt grupy projektów,
- Architekt systemu,
- Architekt korporacyjny.
W trakcie własnego szkolenia dotyczącego architektury korporacyjnej podaję zawsze jedną prostą zasadę: Architekt korporacyjny w odróżnieniu od pozostałych ról architektonicznych pokrywa całość przedsiębiorstwa podczas, gdy pozostałe role skupiają się bądź to na konkretnej warstwie (biznes, aplikacje, infrastruktura), grupie warstw (IT – aplikacje i infrastruktura) czy przecinają wszystkie warstwy od góry do dołu (architekt linii biznesowych, architekt domenowy). Z uwagi na szerszy zakres architekt korporacyjny pokrywa w swej odpowiedzialności więcej, ale przez to musi robić to na wyższym poziomie abstrakcji aniżeli pozostałe role. Czym większy obszar odpowiedzialności tym poziom ogólności musi być większy aby ludzki umysł był w stanie objąć ten zakres. I tu znów pojawia się słowo „zakres”, które często przywołuję w artykułach.
Niezależnie od roli architektonicznej podstawowe funkcje architektoniczne można określić jako:
- F1. funkcja tworzenia produktów architektonicznych,
- F2. funkcja monitorowania zgodności produktów innych ról w przedsiębiorstwie z produktami własnymi,
- F3. funkcja wsparcia w zakresie obszaru odpowiedzialności.
Tylko od konkretnego opisu obowiązków zależy co wytwarza rola architektoniczna (F1) i w jakim stopniu to co wytwarza przekłada się na inne produkty procesów przedsiębiorstwa. Oraz czy w ramach funkcji monitorującej (F2) architekt ma prawo czy też nie ma prawa zablokować wymaganie, grupę wymagań, czy też cały projekt i jakimi narzędziami dysponuje aby poza odpowiedzialnością mógł tę funkcję pełnić skutecznie.
Całe zamieszane w trakcie konferencji wzięło się prawdopodobnie z kilku powodów:
- różne rozumienie pojęcia architekt i przekładania tej roli do własnego przedsiębiorstwa;
- brak wyraźnych kryteriów brzegowych dotyczących omawianej roli;
- moda, czyli dziś lepiej mówić o tym co jest nośne (architektura korporacyjna) niż o tym co faktycznie się robi i za co odpowiada (np. architektura aplikacji).
Szkoda, że po co najmniej dekadzie istnienia pojęcia architektury korporacyjnej w kraju nad Wisłą jest to dyscyplina wciąż enigmatyczna. Szkoda, że do zdefiniowania roli architekta potrzeba paneli dyskusyjnych. Szkoda, że tak wiele osób bardziej przywiązuje się do swoich nazw funkcji zawodowych niż faktycznie pełnionych funkcji w przedsiębiorstwach.
Ostatecznie bardzo cieszę się, że mogłem wysłuchać wielu ciekawych prelekcji ponieważ uzmysłowiły mi one, jak wiele jeszcze jest do zrobienia w zakresie architektury w polskich przedsiębiorstwach. I jak wiele do zrobienia mają sami architekci aby ich role oraz to co mogą one wnieść do przedsiębiorstw były zrozumiałe i przynosiły spodziewany efekt.
Odnośniki