Architektura korporacyjna wzbudza w wielu firmach, u wielu ludzi, wiele emocji. Rola osoby nazywanej Architektem Korporacyjnym budzi te emocje chyba z uwagi na niefortunna nazwę, będącą prostym tłumaczeniem Enterprise Architect.  Tak na prawdę, moim zdaniem, w języku polskim owe “stanowisko” raczej powinno mieć nazwę “Architekt architektury korporacyjnej”. Źródłem tych emocji jest też powszechna dość opinia, że to sztuczne, niepotrzebne stanowisko.

Czym jest Architektura Korporacyjna (w tym jej udokumentowana postać) nie raz tu pisałem. Aby nie powtarzać tych treści, tu napisze, że – w moich oczach – kluczową korzyścią z posiadania takiej dokumentacji jest to, że kolejne wdrożenia nowego oprogramowania, a częściej poszerzania lub zmiany jego funkcjonalności, nie wymagają każdorazowej, kosztownej “analizy przed-wdrożeniowej”.  W większości przypadków praktycznie każde kolejne wdrożenie IT to “analiza stanu obecnego” wykonywana przez dostawcę lub po stronie kupującego, do tego kolejny etap czyli analiza potrzeb i specyfikowanie wymagań. Czy to zawsze musi być robione od zera? Nie. Mając “model całości” w dowolnym momencie możemy go  użyć jako “dokumentacji stanu obecnego”, zaś fakt, że model architektury korporacyjnej pozwala szybko uaktualnić obszar “modelu biznesowego” i na jego podstawie opisać “to czego oczekujemy w związku z tym” prowadzi do niemałych oszczędności czasu i pieniędzy przy każdym wdrożeniu.

Kim jest ten, kto to “ma na głowie”? Poniżej fragment pewnej dyskusji na forum o tym kim jest ów Architekt (polecam zajrzenie do całej dyskusji, tu cytuję jeden z moich wpisów):

Dla uporządkowania przytoczę diagram, dość powszechnie cytowany i uznawany:

(źr.

ISO to najniższa warstwa (najniższa absolutnie nie znaczy najmniej ważna, bo jest raczej odwrotnie), z reguły w firma dokumentowana i zarządzana jest tylko ta najniższa warstwa.

Architektura korporacyjna to abstrakcja (model, zestaw skojarzonych ze sobą diagramów) łącząca czubek tej piramidy z jej dołem, głównie procesy biznesowe (one są zawsze abstrakcją), jeżeli dysponujemy udokumentowanym stanem warstwy implementacji (coraz częściej spotykany, tu ISO, COBIT, ITIL itp.) oraz (to akurat rzadkie) dobry model warstwy strategii (np. Business Motivation Model) i całość potrafimy połączyć od samej góry do samego dołu (śladowanie, wzajemne wynikanie od ogółu do szczegółu) to teraz dopiero mamy możliwość testowania wpływu np. zmiany procedury na realizację strategii albo wskazać jakiej nowej usługi w IT (analiza wymagań) i nowych procedur i kadr, będzie wymagała np. zmiana określonej taktyki.

Jeżeli firma jest mała, w zasadzie dobry prezes da rade sam z notesem, w miarę wzrostu złożoności firmy (organizacji) takie analizy wpływu zaczynają być coraz trudniejsze bez modeli firmy i dobrych narzędzi (zarządzanie kilkudziesięcioma diagramami, związkami miedzy ich obiektami itp).

W moich oczach Architekt Korporacyjny to osoba która:

• potrafi, jako analityk, zbudować taki model (bez przesady ze szczegółowością),
• potrafi go “zakomunikować” zarządowi
• zarządza zmianą modelu, to jest na pytanie zarządu “co będzie gdy…” odpowiada “natychmiast”, po podjęciu przez zarząd decyzji wpływających na model, uaktualnia go.

(Opis stanowiska pracy architekta korporacyjnego – Architekci IT – GoldenLine.pl).

Tak więc moim zdaniem, celem jest ta dokumentacja (zawsze aktualne modele) a  nie “posiadanie” w zasobach Architekta Korporacyjnego. Wydaje mi się, że ten spokojnie może być kontraktowym analitykiem na 1/n etatu lub na niedużym ryczałtowym wynagrodzeniu, za utrzymanie Architektury Korporacyjnej jako zestawu modeli i zarządzanie zmianą tych modeli (nowe projekty).

Bardzo ciekawy artykuł o roli EA ukazał się na stronach MSDN:

An enterprise architect?s role is multi-faceted and extremely dynamic. Not only must they keep track of IT concerns, but also those of the business. Through the work performed on strategic initiative, EAs strive to make alignment between IT and the business more transparent. (A Day in the life of an Enterprise Architect).

Podsumowaniem tego artykułu (polecam cały) może zaczerpnięty z niego diagram (poziomo rozległość wiedzy, pionowo jej głębokość):

Tak więc AK jest to ktoś, kto rozumie całość ale nie musi (nawet nie powinien) być tym, kto ją implementuje, gdyż tu także ważne jest rozdzielenie roli projektującego od wdrażającego. Role te mają nie raz sprzeczne interesy: im głębiej w szczegółach tkwi dana rola (np. developer) tym bardziej w jej interesie leży utrzymanie status quo, mniejszą ma skłonność do wprowadzania zmian.