Architektura Korporacyjna (AK), bar­dzo mod­ny ostat­nio temat. Tym razem o … no wła­snie. Co do poję­cia Architektura Korporacyjna, nabie­ram prze­ko­na­nia, że to ?po pro­stu? pew­na (orga­ni­za­cyj­na, biz­ne­so­wa) spe­cja­li­za­cja poję­cia System (zespół ele­men­tów współdziałających).

Jeżeli uzna­my (zgo­dzi­my się), że celem ist­nie­nia orga­ni­za­cji są jej pro­duk­ty (war­tość jaka dostar­cza) a nie infor­ma­cje jakie prze­twa­rza (bo te są jedy­nie środ­kiem, narzę­dziem osią­ga­nia celu: są wtór­ne wobec powyż­sze­go celu), to kon­se­kwen­cją jest uzna­nie, że Archi­tek­tu­ra Korporacyjna to opis orga­ni­za­cji, a nie coś co trze­ba stwo­rzyć (stwo­rzyć nale­ży opis Architektury a nie Architekturę). Pamiętamy tak­że, że two­rze­nie mode­li ist­nie­ją­cych orga­ni­za­cji nie two­rzy tych orga­ni­za­cji a jedy­nie je opi­su­je. (parz: Teoria komu­ni­ka­cji, dżun­gla ram i szkie­le­tów).

Co i jak dokumentować

W defi­ni­cjach AK czę­sto spo­ty­ka­my czte­ry poję­cia: ludzie, pro­ce­sy, infor­ma­cje, tech­ni­ka. Zróbmy pro­sty model poję­cio­wy dla tych pojęć:

Kilka uwag: nie połą­czy­łem bez­po­śred­nio ludzi z tech­ni­ką, gdyż tech­ni­ka to narzę­dzie pra­cy, a więc słu­ży ono do cze­goś czło­wie­ko­wi. Tym co łączy czło­wie­ka z tech­ni­ką jest cele jej uży­cia. Druga uwa­ga: pro­ce­sy i infor­ma­cje to abs­trak­cje, mate­rial­ne są dane (i ich nośni­ki) oraz pro­duk­ty (to co orga­ni­za­cja dostar­cza swo­im klien­tom, nawet usłu­gi są mate­ria­li­zo­wa­ne ich opi­sem). Umieściłem na dia­gra­mie tak­że doku­men­ty i regu­ły biz­ne­so­we by nadać kon­tekst danym i pro­ce­som. Gdyby zaś uznać, że pro­ces biz­ne­so­wy (zgod­nie z jego defi­ni­cją) to tak­że pro­duk­ty i regu­ły biz­ne­so­we, zaś dane jed­nak zawsze repre­zen­tu­ją jakieś obiek­ty biz­ne­so­we (doku­men­ty), to wszyst­kie poję­cia na tym dia­gra­mie sta­ją ele­men­ta­mi AK.

W lite­ra­tu­rze na temat AK poja­wia się tak­że stwier­dze­nie, mówią­ce że w ramach ana­li­zy i doku­men­to­wa­nia AK nale­ży brać pod uwa­gę stra­te­gię fir­my a więc tak­że, będą­cą jej źró­dłem, moty­wa­cję biz­ne­so­wą (model biznesowy).

Po co doku­men­to­wać (mode­lo­wać) AK? Przede wszyst­kim po to by zro­zu­mieć jak dzia­ła orga­ni­za­cja, a potem by móc świa­do­mie, zna­jąc ryzy­ko, podej­mo­wać decy­zje o wpro­wa­dza­niu zmian do niej. 

Na powyż­szym dia­gra­mie ciem­nym kolo­rem zazna­czo­no dane biz­ne­so­we, ludzi i tech­ni­kę. To nama­cal­ne (mate­rial­ne) ele­men­ty każ­dej orga­ni­za­cji, mają one prak­tycz­nie zawsze swo­ją doku­men­ta­cję: ludzie w posta­ci struk­tu­ry orga­ni­za­cyj­nej, dane biz­ne­so­we w posta­ci wzo­rów doku­men­tów, tech­ni­kę w posta­ci reje­stru mająt­ku trwa­łe­go (przy­po­mi­nam, że pro­ce­sy i infor­ma­cje to byty abs­trak­cyj­ne). Wystarczy więc sko­ja­rzyć ze sobą te trzy obsza­ru (spi­sy) per ele­ment i otrzy­ma­my pierw­szy opis poka­zu­ją­cy co z czym jest powią­za­ne czy­li co i na co ma wpływ.

Problem w tym, że taki opis z jed­nej stro­ny jest zbyt szcze­gó­ło­wi do bie­żą­cej pra­cy z nim. By jaka­kol­wiek ana­li­za była w ogó­le wyko­ny­wal­na nale­ży ten opis spro­wa­dzić (uogól­nić) do ​„roz­sąd­nie małej licz­by” obiek­tów. Aby to zro­bić nale­ży wpro­wa­dzić pew­ne abs­trak­cie, ukry­wa­ją­ce przez nami zbęd­na szcze­gó­ło­wość. Te abs­trak­cje to wła­sne infor­ma­cje i pro­ce­sy. Ludzi zaś i tech­ni­kę uogól­nia­my odpo­wied­nio do ele­men­tów struk­tu­ry orga­ni­za­cyj­nej i apli­ka­cji (któ­re, w przy­pad­ku tech­ni­ki IT ​„ukry­wa­ją” przez nami koniecz­ny do ich ist­nie­nia sprzęt).

Przy oka­zji: czę­sto moż­na usły­szeć, że orga­ni­za­cja to ludzie. Zgadzam się z tym, pro­szę zwró­cić uwa­gę, że mój powyż­szy model poję­cio­wy jest antropocentryczny.

Z per­spek­ty­wy orga­ni­za­cji, każ­da ana­li­za wpły­wu zmia­ny, będzie wyma­ga­ła zro­zu­mie­nia tego co ma wpływ na pro­dukt – to on nie­sie war­tość ryn­ko­wą. Jak widać mamy pro­sty ​„łań­cu­szek” poka­zu­ją­cy, że łącza się kolej­no: pro­dukt, pro­ces go two­rzą­cy, ludzie reali­zu­ją­cy pro­ces, infor­ma­cje jakich czło­wiek wyma­ga, dane nio­są­ce te infor­ma­cje i tech­ni­ka zarzą­dza­ją­ca tymi dany­mi. Przerwanie tego łań­cu­cha spo­wo­du­je prze­rwa­nie dostar­cza­nia pro­duk­tu dla­te­go war­to go dokład­nie zro­zu­mieć i zarzą­dzać nim (pano­wać nad nim).

Tak więc AK to doku­men­ta­cja, model, zawie­ra­ją­ca całą i wystar­cza­ją­cą wie­dzę o tym, co ma wpływ na dostar­cza­nie produktu.

Można do tego jesz­cze dodać ele­men­ty mode­lu biz­ne­so­we­go, któ­ry uza­sad­ni nam dostar­cza­nie takie­go a nie inne­go pro­duk­tu i mamy kom­plet. Od cze­go nale­ży zacząć? Od zbu­do­wa­nia wła­snej (lub wybo­ru ) meto­dy­ki two­rze­nia tej doku­men­ta­cji oraz zatrud­nie­niu Architekta. (c.d. Jak roz­ma­wiać z biz­ne­sem nt. Architektury Korporacyjnej).

Czy to musi być jakiś stan­dard np. TOGAF? Nie jestem prze­ko­na­ny. ArchiMate (nota­cja zale­ca­na w TOGAF) to nic inne­go jak sys­tem poję­cio­wy. Czy mamy wybór? Oczywiście, że mamy. Od daw­na OMG dostar­cza spraw­dzo­ne i otwar­te stan­dar­dy notacyjne. 

Co mamy w ?skrzyn­ce narzę­dzio­wej OMG? (www​.omg​.org)? Ludzie i pro­ce­sy to nic inne­go jak BPMN i struk­tu­ra orga­ni­za­cyj­na (ta dru­ga w BPMN lub jako sfor­ma­li­zo­wa­ny orga­ni­gram). Informacje i tech­ni­ka to nic inne­go jak UML i dia­gra­my struk­tu­ral­ne. (Architektura kor­po­ra­cyj­na z OMG​.org). W razie potrze­by udo­ku­men­to­wa­nia stra­te­gii (moty­wa­cji biz­ne­so­wej) mamy nota­cje BMM. Notacje, któ­re ?wpa­dły? w ręce OMG maja też bar­dzo pożą­da­ną i przy­jem­ną cechę: są ze sobą kom­pa­ty­bil­ne i uzu­peł­nia­ją się (czy­taj Semantic Core).

Ale o tym, AK z OMG jak widać już pisałem :).