Architektura kor­po­ra­cyj­na wzbu­dza w wie­lu fir­mach, u wie­lu ludzi, wie­le emo­cji. Rola oso­by nazy­wa­nej Architektem Korporacyjnym budzi te emo­cje chy­ba z uwa­gi na nie­for­tun­na nazwę, będą­cą pro­stym tłu­ma­cze­niem Enterprise Architect. Tak na praw­dę, moim zda­niem, w języ­ku pol­skim owe ​„sta­no­wi­sko” raczej powin­no mieć nazwę ​„Architekt archi­tek­tu­ry kor­po­ra­cyj­nej”. Źródłem tych emo­cji jest też powszech­na dość opi­nia, że to sztucz­ne, nie­po­trzeb­ne stanowisko.

Czym jest Architektura Korporacyjna (w tym jej udo­ku­men­to­wa­na postać) nie raz tu pisa­łem. Aby nie powta­rzać tych tre­ści, tu napi­sze, że – w moich oczach – klu­czo­wą korzy­ścią z posia­da­nia takiej doku­men­ta­cji jest to, że kolej­ne wdro­że­nia nowe­go opro­gra­mo­wa­nia, a czę­ściej posze­rza­nia lub zmia­ny jego funk­cjo­nal­no­ści, nie wyma­ga­ją każ­do­ra­zo­wej, kosz­tow­nej ​„ana­li­zy przed-wdro­że­nio­wej”. W więk­szo­ści przy­pad­ków prak­tycz­nie każ­de kolej­ne wdro­że­nie IT to ​„ana­li­za sta­nu obec­ne­go” wyko­ny­wa­na przez dostaw­cę lub po stro­nie kupu­ją­ce­go, do tego kolej­ny etap czy­li ana­li­za potrzeb i spe­cy­fi­ko­wa­nie wyma­gań. Czy to zawsze musi być robio­ne od zera? Nie. Mając ​„model cało­ści” w dowol­nym momen­cie może­my go użyć jako ​„doku­men­ta­cji sta­nu obec­ne­go”, zaś fakt, że model archi­tek­tu­ry kor­po­ra­cyj­nej pozwa­la szyb­ko uak­tu­al­nić obszar ​„mode­lu biz­ne­so­we­go” i na jego pod­sta­wie opi­sać ​„to cze­go ocze­ku­je­my w związ­ku z tym” pro­wa­dzi do nie­ma­łych oszczęd­no­ści cza­su i pie­nię­dzy przy każ­dym wdrożeniu.

Kim jest ten, kto to ​„ma na gło­wie”? Poniżej frag­ment pew­nej dys­ku­sji na forum o tym kim jest ów Architekt (pole­cam zaj­rze­nie do całej dys­ku­sji, tu cytu­ję jeden z moich wpisów):

Dla upo­rząd­ko­wa­nia przy­to­czę dia­gram, dość powszech­nie cyto­wa­ny i uznawany:

(źr. http://​www​.bptrend​sas​so​cia​tes​.com/)

ISO to naj­niż­sza war­stwa (naj­niż­sza abso­lut­nie nie zna­czy naj­mniej waż­na, bo jest raczej odwrot­nie), z regu­ły w fir­ma doku­men­to­wa­na i zarzą­dza­na jest tyl­ko ta naj­niż­sza warstwa.

Architektura kor­po­ra­cyj­na to abs­trak­cja (model, zestaw sko­ja­rzo­nych ze sobą dia­gra­mów) łączą­ca czu­bek tej pira­mi­dy z jej dołem, głów­nie pro­ce­sy biz­ne­so­we (one są zawsze abs­trak­cją), jeże­li dys­po­nu­je­my udo­ku­men­to­wa­nym sta­nem war­stwy imple­men­ta­cji (coraz czę­ściej spo­ty­ka­ny, tu ISO, COBIT, ITIL itp.) oraz (to aku­rat rzad­kie) dobry model war­stwy stra­te­gii (np. Business Motivation Model) i całość potra­fi­my połą­czyć od samej góry do same­go dołu (śla­do­wa­nie, wza­jem­ne wyni­ka­nie od ogó­łu do szcze­gó­łu) to teraz dopie­ro mamy moż­li­wość testo­wa­nia wpły­wu np. zmia­ny pro­ce­du­ry na reali­za­cję stra­te­gii albo wska­zać jakiej nowej usłu­gi w IT (ana­li­za wyma­gań) i nowych pro­ce­dur i kadr, będzie wyma­ga­ła np. zmia­na okre­ślo­nej taktyki.

Jeżeli fir­ma jest mała, w zasa­dzie dobry pre­zes da rade sam z note­sem, w mia­rę wzro­stu zło­żo­no­ści fir­my (orga­ni­za­cji) takie ana­li­zy wpły­wu zaczy­na­ją być coraz trud­niej­sze bez mode­li fir­my i dobrych narzę­dzi (zarzą­dza­nie kil­ku­dzie­się­cio­ma dia­gra­ma­mi, związ­ka­mi mie­dzy ich obiek­ta­mi itp).

W moich oczach Architekt Korporacyjny to oso­ba która:

• potra­fi, jako ana­li­tyk, zbu­do­wać taki model (bez prze­sa­dy ze szczegółowością),
• potra­fi go ​„zako­mu­ni­ko­wać” zarządowi
• zarzą­dza zmia­ną mode­lu, to jest na pyta­nie zarzą­du ​„co będzie gdy…” odpo­wia­da ​„natych­miast”, po pod­ję­ciu przez zarząd decy­zji wpły­wa­ją­cych na model, uak­tu­al­nia go.

(Opis sta­no­wi­ska pra­cy archi­tek­ta kor­po­ra­cyj­ne­go – Architekci IT – GoldenLine​.pl).

Tak więc moim zda­niem, celem jest ta doku­men­ta­cja (zawsze aktu­al­ne mode­le) a nie ​„posia­da­nie” w zaso­bach Architekta Korporacyjnego. Wydaje mi się, że ten spo­koj­nie może być kon­trak­to­wym ana­li­ty­kiem na 1/n eta­tu lub na nie­du­żym ryczał­to­wym wyna­gro­dze­niu, za utrzy­ma­nie Architektury Korporacyjnej jako zesta­wu mode­li i zarzą­dza­nie zmia­ną tych mode­li (nowe projekty).

Bardzo cie­ka­wy arty­kuł o roli EA uka­zał się na stro­nach MSDN:

An enter­pri­se architect?s role is mul­ti-face­ted and extre­me­ly dyna­mic. Not only must they keep track of IT con­cerns, but also tho­se of the busi­ness. Through the work per­for­med on stra­te­gic ini­tia­ti­ve, EAs stri­ve to make ali­gn­ment betwe­en IT and the busi­ness more trans­pa­rent. (A Day in the life of an Enterprise Architect).

Podsumowaniem tego arty­ku­łu (pole­cam cały) może zaczerp­nię­ty z nie­go dia­gram (pozio­mo roz­le­głość wie­dzy, pio­no­wo jej głębokość):

Tak więc AK jest to ktoś, kto rozu­mie całość ale nie musi (nawet nie powi­nien) być tym, kto ją imple­men­tu­je, gdyż tu tak­że waż­ne jest roz­dzie­le­nie roli pro­jek­tu­ją­ce­go od wdra­ża­ją­ce­go. Role te mają nie raz sprzecz­ne inte­re­sy: im głę­biej w szcze­gó­łach tkwi dana rola (np. deve­lo­per) tym bar­dziej w jej inte­re­sie leży utrzy­ma­nie sta­tus quo, mniej­szą ma skłon­ność do wpro­wa­dza­nia zmian.