Korzyści z Architektury Korporacyjnej

Temat tego czy i na ile nie­tech­nicz­ne kadry zarząd­cze, czy­li tak zwa­ny biz­nes, rozu­mie­ją nowe tech­no­lo­gie prze­wi­ja się regu­lar­nie przez zarów­no pra­sę jak i blo­gi. Po pierw­sze jest w tym wie­le praw­dy a po dru­gie niby dla­cze­go mia­ło by być ina­czej? Jeżeli jakaś treść jest napi­sa­na tak zwa­nym tech­nicz­nym języ­kiem, to odbior­ca, kim jest, sam się ujaw­ni, podob­nie jak w przy­pad­ku gdy np. w samo­lo­cie nie­miec­kich linii lot­ni­czych ste­war­de­sa zawo­ła do kogoś po pol­sku pod­nio­są się wyłącz­nie Polacy.

Z archi­tek­tu­rą kor­po­ra­cyj­ną jest podob­nie co potwier­dza niżej mój kole­ga dr. hab. Andrzej Sobczak:

Po pierw­sze TOGAF jest napi­sa­ny w bar­dzo nie­przy­stęp­ny spo­sób ? nawet dla osób dobrze zna­ją­cych angiel­ski (wystę­pu­je bar­dzo dużo pojęć, któ­re nie są intu­icyj­ne). Co wię­cej ?czuć?, że TOGAF został napi­sa­ny przez infor­ma­ty­ków dla infor­ma­ty­ków (nale­ży pamię­tać, że TOGAF wywo­dzi się z TAFIM ? tj. Technical Architecture Framework for Information Management, a do wer­sji 7.0 włącz­nie w TOGAF?ie mówio­no wyłącz­nie o archi­tek­tu­rze IT, dopie­ro od wer­sji 8.0 wpro­wa­dzo­no kon­cep­cję archi­tek­tu­ry kor­po­ra­cyj­nej). Po dru­gie jest nie­zwy­kle obszer­ny (spe­cy­fi­ka­cja stan­dar­du liczy oko­ło 700 stron) i nie zawsze jest podzie­lo­na w logicz­ny spo­sób. Po trze­cie wresz­cie spe­cy­fi­ka­cja TOGAF jest miej­sca­mi nie­spój­na (co do kon­cep­cji i ter­mi­no­lo­gii) i w nie­któ­rych obsza­rach moc­no prze­sta­rza­ła (wyni­ka to z histo­rii roz­wo­ju TOGAF?a jako stan­dar­du ? pierw­sza jego wer­sja poja­wi­ła się już w 1996 roku ? bez mała 20 lat temu).

To są minu­sy tego stan­dar­du. Jednak z roku na rok zysku­je on coraz więk­szą popu­lar­ność. Jeszcze 10 lat temu miał on 7% ?ryn­ku ram arch­tek­to­nicz­nych? na świe­cie?, obec­nie jego udział zwięk­szył się do bli­sko 60%. Nie moż­na go więc igno­ro­wać. Niezbędne jest odpo­wied­nie ?sprze­da­nie? tego podej­ścia biz­ne­so­wej czę­ści orga­ni­za­cji. (Jak roz­ma­wiać z biz­ne­sem nt. TOGAF?a? | Architektura Korporacyjna).

Powyżej zwró­co­no uwa­gę na trzy pro­ble­my stan­dar­du TOGAF, któ­ry jak zauwa­ża autor, ma obec­nie 60% udział w ryn­ku (stan­dar­dów tych jest wię­cej, prze­czy­taj mój arty­kuł i książ­kę How to Survive in the Jungle of Enterprise Architecture Frameworks: Creating or Choosing an Enterprise Architecture Framework).

Niezrozumiałość to chy­ba fak­tycz­nie efekt tego, że auto­ra­mi są infor­ma­ty­cy. Jest to aku­rat uza­sad­nio­ne bo rodo­wód TOGAF to ​„kon­ku­ren­cja” dla ITIL.

Obszerność. Hm, tu aku­rat nie uwa­żam by był to zarzut, spe­cy­fi­ka­cja nota­cji BPMN ma podob­ną obję­tość, a UML prze­kro­czył 1000 stron. Ramy archi­tek­to­nicz­ne to tak­że prze­strzeń poję­cio­wa, potęż­ny zestaw ter­mi­nów mają­cych defi­ni­cje i cel ist­nie­nia czy­li opi­sa­nie cze­goś w spój­ny spo­sób. Tu płyn­nie prze­cho­dzi­my do trze­ciej wady: nie­spój­ność. To nie­ste­ty w moich oczach prak­tycz­nie dys­kwa­li­fi­ku­je każ­dy sys­tem jeże­li jest niespójny.

Niespójność ozna­cza powsta­nie poten­cjal­nej nie­jed­no­znacz­no­ści w każ­dym doku­men­cie (mode­lu), w któ­rym zosta­nie uży­ta nie­spój­na prze­strzeń poję­cio­wa (przy­po­mnę, że popraw­na prze­strzeń poję­cio­wa to zestaw pojęć, któ­re cechu­ją: kom­plet­ność, nie­sprzecz­ność, wza­jem­na wyklu­czal­ność). A TOGAF i jego słow­nik ter­mi­nów to nic inne­go jak pew­na prze­strzeń pojęć.

Czy koniecznie musi to być TOGAF?

Ile razy szu­kam w sie­ci i książ­kach defi­ni­cji poję­cia ​„archi­tek­tu­ra kor­po­ra­cyj­na” tyle razy prze­ko­nu­ję się, że jej nie ma bo w zasa­dzie każ­da zna­le­zio­na jest ​„nie­co inna”. Można jed­nak, stu­diu­jąc lite­ra­tu­rę na ten temat, dojść do prze­ko­na­nia, że cho­dzi po pro­tu o tak zwa­ne cało­ścio­we (jak ktoś woli to holi­stycz­ne) sys­te­mo­we podej­ście do patrze­nia na orga­ni­za­cję (ana­li­za sys­te­mo­wa).

Popatrzmy na defi­ni­cje angiel­skie (w tym języ­ku powsta­ły pierw­sze spe­cy­fi­ka­cje AE, źr. Oxford Dictionaries):

ente­pri­se – a busi­ness or com­pa­ny: entre­pre­neu­rial eco­no­mic activity

archi­tec­tu­re – the art or prac­ti­ce of desi­gning and con­struc­ting buil­dings, the com­plex or care­ful­ly desi­gned struc­tu­re of something

Tak więc wypa­da przy­jąć, że archi­tek­tu­ra kor­po­ra­cyj­na to

„(cało­ścio­wa) struk­tu­ra orga­ni­za­cji pro­wa­dzą­cej dzia­łal­ność o cha­rak­te­rze komer­cyj­nym”.

[[Jaap Schekkerman]] w swo­jej książ­ce [[How to Survive in the Jungle of Enterprise Architecture Frameworks: Creating or Choosing an Enterprise Architecture Framework. Creating or cho­osing an Enteprice Architecture Framework]] tak defi­niu­je AK:

Enterprise Architecture in a com­ple­te expres­sion of the enter­pri­se (archi­tek­tu­ra kor­po­ra­cyj­na to kom­plet­ny opis organizacji)

Pozostaje odpo­wie­dzieć na pyta­nie, co zawie­ra ten kom­plet­ny opis? Schekkerman, jak i wie­lu innych, mówi ​„wszyst­ko”:

Mamy więc stra­te­gię i tech­no­lo­gie oraz odpo­wia­da­ją­ce jej zdol­no­ści ope­ra­cyj­ne (zarząd­cze) i tech­no­lo­gicz­ne. Taki opis jest ​„kom­pa­ty­bil­ny” z opi­sem pro­ce­su biz­ne­so­we­go w kon­wen­cji IGOE (Input, Guide, Output, Enablers, model w pro­jek­tach z obsza­ru [[Business Process Manamegent]]) któ­ry, poza swo­im wej­ściem i wyj­ściem, jest defi­nio­wa­ny przez regu­ły (guide) oraz zaso­by umoż­li­wia­ją­ce jego funk­cjo­no­wa­nie – enablers).

Tak więc mamy odpo­wiedź na pyta­nie ​„Co to zna­czy wszyst­ko”. Znaczy to: kon­cep­cja biz­ne­so­wa (stra­te­gia) i spo­sób zarzą­dza­nia oraz wyma­ga­ne tech­no­lo­gie czy­li stra­te­gia ich wyko­rzy­sta­nia i zdol­ność uży­cia (ich absorp­cji). Szczególnie to osta­nie ma głę­bo­ki sens, gdyż sam fakt zaku­pu jakiej­kol­wiek tech­no­lo­gii nie jest rów­no­znacz­ny z jej ope­ra­cyj­nym wdro­że­niem (o czym prze­ko­nał się nie­je­den bene­fi­cjent sys­te­mu np. ERP, CRM czy BI).

Teraz prze­wrot­nie uży­ję frag­men­tu pod­ty­tu­łu ww. książki:

Creating an Enterprise Architecture Framework

Tworzenie ramy archi­tek­tu­ry kor­po­ra­cyj­nej. Jak? W sumie, o czym wspo­mi­na­łem w nie­jed­nym poprzed­nim arty­ku­le, mamy dar­mo­wy kom­plet narzę­dzi, czy­li sys­te­my poję­cio­we dla każ­de­go z powyż­szych czte­rech obsza­rów: stra­te­gię może­my opi­sać z uży­ciem nota­cji BMM, reguł biz­ne­so­wych oraz pro­ce­sów end-2-end i nota­cji BPMN. Technologię i spo­sób jej wyko­rzy­sta­nia z pomo­cą nota­cji UML. Odpowiednie mapo­wa­nia (powy­żej: pozio­me i pio­no­we) robi­my albo w macie­rzy, albo z pomo­cą Siatki Zachmana. Wybór zale­ży od przy­ję­tej meto­dy i narzę­dzia CASE jakim zamie­rza­my ten pro­jekt doku­men­to­wać (bez narzę­dzia odradzam).

Organizacja OMG dobrze zadba­ła o spój­ność tych nota­cji (Semantic Core), cze­go nie­ste­ty nie moż­na powie­dzieć o TOGAF i The Open Group (nota­cja ArchiMate nie­ste­ty, nie tyl­ko moim zda­niem, pozo­sta­wia nie­co do życze­nia, pomi­jam już jej licencjonowanie).

Teraz pole­cam zapo­zna­nie się arty­ku­łem Produkty w pro­ce­sie ana­li­zy wyma­gań. Proszę zwró­cić uwa­gę, że powyż­sze czte­ry obsza­ry wie­dzy o orga­ni­za­cji: stra­te­gia biz­ne­so­wa, spo­sób zarzą­dza­nia – model biz­ne­so­wy, stra­te­gia i zdol­ność wyko­rzy­sta­nia nowych tech­no­lo­gii, są obję­te opi­sa­ną ana­li­zą przed-wdro­że­nio­wą i ana­li­zą wyma­gań. Wzajemne mapo­wa­nie obiek­tów z tych czte­rech obsza­rów to nic inne­go jak tak zwa­ne śla­do­wa­nie i wali­da­cja: każ­dy ele­ment musi cze­muś słu­żyć i z cze­goś wyni­kać. Moim zdaniem:

Specyfikacja wyma­gań powin­na być pro­duk­tem (wyni­kać z) Architektury Korporacyjnej, a nie powsta­wać każ­do­ra­zo­wo od zera z pro­wa­dzo­nych setek wywia­dów i warsztatów. 

Tak więc projekt

Architektura Korporacyjna, moim zda­niem, nie ma sen­su ​„sam dla sie­bie”. Tego typu doku­men­ta­cja słu­ży naj­pierw do zro­zu­mie­nia dzia­ła­nia zło­żo­nej orga­ni­za­cji a potem do podej­mo­wa­nia decy­zji o każ­dej reor­ga­ni­za­cji czy inwe­sty­cji w zasoby.

Wystarczy, że każ­da ana­li­za wyma­gań będzie pro­wa­dzo­na w ten sam, powta­rzal­ny spo­sób i jako efekt, będzie dawa­ła kom­pa­ty­bil­ne z poprzed­ni mode­le (i doku­men­ty). Narastająco two­rzo­na doku­men­ta­cja pro­stą dro­gą popro­wa­dzi nas do doku­men­tu o nazwie Nasza Architektura Korporacyjna. Zwróci się (kosz­ty stwo­rze­nia meto­dy­ki) naj­praw­do­po­dob­niej już przy dru­gim projekcie.

(linia czer­wo­na obra­zu­je kolej­ne pro­jek­ty ana­li­tycz­ne i ich nara­sta­ją­cy koszt, linia nie­bie­ska to kolej­ne pro­jek­ty ana­li­tycz­ne zastą­pio­ne stwo­rze­niem i utrzy­ma­niem doku­men­ta­cji Architektury Korporacyjnej pod­czas pierw­sze­go pro­jek­tu, źr. Jarosław Żeliński, opra­co­wa­nie własne)

Od cze­go nale­ży zacząć? Od zbu­do­wa­nia wła­snej (lub wła­sne­go warian­tu) meto­dy­ki jej two­rze­nia oraz zatrud­nie­niu Architekta. Czy to powi­nien być wła­sny pra­cow­nik? Moim zda­niem nie, gdyż po pierw­sze nie będzie­my w sta­nie obcią­żyć go pra­cą na 100%. Po dru­gie powi­nien to być ktoś z zewnątrz, by nie był uwi­kła­ny w wewnątrz­or­ga­ni­za­cyj­ne zależ­no­ści – Architekt kor­po­ra­cyj­ny nigdy nie powi­nien być inte­re­sa­riu­szem w pro­jek­cie zwią­za­nym z reor­ga­ni­za­cją a jako pra­cow­nik zawsze nim będzie (podob­nie jak lekarz domo­wy to raczej nikt z domow­ni­ków). Kolega w innym swo­im arty­ku­le pisze:

Architektura kor­po­ra­cyj­na nie powin­na być utoż­sa­mia­na z for­mal­nym opi­sem orga­ni­za­cji (jak to defi­niu­je TOGAF) i nie powin­na być tak ?sprze­da­wa­na? wewnątrz organizacji.

Jeżeli nie tak ? to w jaki inny spo­sób? W tym miej­scu nale­ży koniecz­nie odwo­łać się do ?ojca? kon­cep­cji archi­tek­tu­ry kor­po­ra­cyj­nej ? czy­li J. Zachmana. Uważa on, że archi­tek­tu­ra kor­po­ra­cyj­na poma­ga roz­wią­zy­wać pro­ble­my orga­ni­za­cji w ite­ra­cyj­ny i przy­ro­sto­wy spo­sób. Przedstawiciele fir­my iCMG idą wręcz dalej ? nazy­wa­ją oni archi­tek­tu­rę kor­po­ra­cyj­ną dys­cy­pli­ną nauko­wą zaj­mu­ją­cą się two­rze­niem, dzia­ła­niem i roz­wo­jem orga­ni­za­cji. (Czy już pora wymy­ślić od nowa archi­tek­tu­rę kor­po­ra­cyj­ną? | Architektura Korporacyjna).

i wypa­da mi się z nim zgo­dzić 🙂 poza jed­nym: uwa­żam, że powi­nien być to opis for­mal­ny bo tyl­ko wte­dy będzie jed­no­znacz­ny i ​„nauko­wy”. Tylko wte­dy będzie moż­li­we jego ​„bada­nie” np. prze­pro­wa­dze­nie ana­li­zy skut­ków decy­zji o reor­ga­ni­za­cji zanim ją rozpoczniemy.

Teraz zapew­ne ktoś powie, że piszę tak tyl­ko dla­te­go, że świad­czę takie usłu­gi. Otóż jest dokład­nie odwrot­nie: świad­czę takie usłu­gi bo głę­bo­ko wie­rzę, że tak wła­śnie nale­ży postę­po­wać, bo – jeże­li orga­ni­za­cja ist­nie­je to ona, archi­tek­tu­ra, też jest, nale­ży ją tyl­ko prze­ana­li­zo­wać, zbu­do­wać jej model i korzy­stać z nie­go przy podej­mo­wa­niu każ­dej ryzy­kow­nej decy­zji. Dobry model powi­nien wol­no się zmie­niać, tak jak wol­no się zmie­nia orga­ni­za­cja. Jeżeli model jest zbyt szcze­gó­ło­wy i wyma­ga dużych nakła­dów na jego aktu­ali­za­cje jest złym modelem.

Inne artykuły na podobny temat

• Architektura kor­po­ra­cyj­na z OMG​.org
• Architektura kor­po­ra­cyj­na w roku 2015 ? prognoza
• Wzorce pro­jek­to­we w ana­li­zie i pro­jek­to­wa­niu mode­lu dzie­dzi­ny systemu
• Obiektowy model systemu
• Teoria komu­ni­ka­cji, dżun­gla ram i szkieletów