Visual Paradigm 14.0 czyli efektywniejszy analityk

19 Grudnia opu­bli­ko­wa­no nową wer­sję pakie­tu Visual Paradigm: 14.0, w sto­sun­ku do poprzed­nie (13.2) wie­le ulep­szeń i kil­ka nowych zaba­wek”. Nie będę opi­sy­wał wszyst­kich (szcze­gó­ły na stro­nie pro­du­cen­ta, link na koń­cu artykułu). 

Na począ­tek waż­na uwa­ga i wyja­śnie­nie: korzy­sta­nie z narzę­dzi CASE z rów­no­le­głym two­rze­niem doku­men­tów na boku”, z uży­ciem pakie­tów biu­ro­wych jest kom­plet­nie pozba­wio­nym sen­su podej­ściem: tra­ci­my 3/4 war­to­ści tych narzę­dzi, jaką jest gene­ro­wa­nie ad-hoc wyso­kiej jako­ści, spój­nej, kom­plet­nej i nie­sprzecz­nej doku­men­ta­cji. Modele two­rzy­my z kil­ku powo­dów: zapi­su­je­my wyni­ki ana­li­zy, pro­jek­tu­je­my roz­wią­za­nia, testu­je­my je, ale przede wszyst­kim prze­ka­zu­je­my tę wie­dzę, czy­li two­rzy­my doku­men­ty opi­su­ją­ce efek­ty naszej pra­cy. Główną pra­cą jaką wyko­nu­je ana­li­tyk jest ana­li­za i pro­jek­to­wa­nie. Jeżeli więc two­rze­nie doku­men­tów zaj­mu­je mu wię­cej niż umow­ne 20%, sta­je się po pro­stu nie­efek­tyw­ny czy­li bar­dzo kosz­tow­ny. Często spo­ty­kam się z sytu­acją gdy tak na praw­dę 90% cza­su ana­li­zy zaj­mu­je spo­ty­ka­nie się i mozol­ne two­rze­nie doku­men­tów, 10% to fak­tycz­na ana­li­tycz­na i twór­cza pra­ca. To mega mar­no­traw­stwo (lub kom­plet­ny brak sza­cun­ku dla zama­wia­ją­ce­go). Dlatego gene­ro­wa­nie wyso­kiej jako­ści mery­to­rycz­nej doku­men­ta­cji (a nie tyl­ko ślicz­nie sfor­ma­to­wa­nej) jest klu­czo­wym ele­men­tem dobre­go pakie­tu CASE (poza oczy­wi­ście zesta­wem nota­cji i ich zgod­no­ścią ze stan­dar­da­mi). Tu tyl­ko wspo­mnę, że od wie­lu lat nie uży­wam edy­to­rów tek­stów do two­rze­nia pro­duk­tów swo­jej pra­cy (w tym obsza­rze). Czytaj dalej… Visual Paradigm 14.0 czy­li efek­tyw­niej­szy ana­li­tyk”

Target Operating Model, 7S framework i i nne

Od cza­su do cza­su jestem pyta­ny o róż­ne fra­me­wor­ki” i meto­dy­ki doty­czą­ce cało­ścio­we­go opi­su fir­my”. Można spo­tkać wie­le róż­nych, lep­szych lub gor­szych mode­li i sza­blo­nów, ram (fra­me­wor­ków), jed­nak moim zda­niem, podej­ście mini­ma­li­stycz­ne (patrz [[brzy­twa Ockhama]]) jest naj­lep­sze. Zmusza do zro­zu­mie­nia isto­ty rze­czy, bez masko­wa­nia nie­wie­dzy nowy­mi i, nie raz, sztucz­ny­mi poję­cia­mi. Drugim powo­dem, któ­ry moim zda­niem leży u pod­staw pomy­słów na nowe mode­le”, jest pra­wo autor­skie. Opracowanie uni­kal­ne­go fra­me­wor­ka” czy­ni z auto­ra takie­go dzie­ła wła­ści­cie­la meto­dy”, za któ­rą ma pra­wo pobie­rać opła­ty licen­cyj­ne (przy­kła­dem jest np. TOGAF i nota­cja ArchiMate chro­nio­ne pra­wem autor­skim przez komer­cyj­ną orga­ni­za­cję The Open Group).

Takich fra­me­wor­ków” jest wię­cej, tu dwa inne przy­kła­dy na popar­cie mojej tezy, TOM:

TOMTarget Operating Model (TOM). Once you’ve arti­cu­la­ted your stra­te­gy, one of the next things to do is to design the orga­ni­sa­tion to deli­ver it. This is usu­al­ly expres­sed in the form of a Target Operating Model (TOM). The gene­ral appro­ach is to defi­ne the people, pro­ces­ses and tech­no­lo­gy requ­ired to deli­ver the stra­te­gy. (za How to design a Target Operating Model (TOM)).

albo ten nazwa­ny 7s:

McKinsey7-SMcKinsey and Co’s 7S fra­me­work pro­vi­des a use­ful fra­me­work for ana­ly­sing the streng­ths and weak­nes­ses of an orga­ni­sa­tion (see also 7 Essential Strategy Analysis Tools). The McKinsey Consulting Firm iden­ti­fied stra­te­gy as only one of seven ele­ments exhi­bi­ted by the best mana­ged com­pa­nies. (za McKinsey 7‑S).

Osobiście sto­su­ję (i nie ja jeden) dar­mo­wy i dobrze opi­sa­ny (moim zda­niem znacz­niej lepiej niż powyż­sze) spój­ny zestaw sys­te­mów poję­cio­wych rodem z OMG (www​.omg​.org, dostęp publicz­ny, nie wyma­ga­ją­cy żad­nych opłat licen­cyj­nych). Powyższe potrze­by” czy­li połą­cze­nie pojęć: ludzie, zaso­by, wie­dza, pro­ce­sy, połą­cze­nie w jeden mecha­nizm, wyglą­da­ją tak:

Jak opisać firmę wewnątrz: model procesów biznesowych

(opra­co­wa­nie wła­sne auto­ra na bazie spe­cy­fi­ka­cji nota­cji OMG​.org)

Łącznikiem jest abs­trak­cja, jaką jest pro­ces biz­ne­so­wy. Proces biz­ne­so­wy jako byt, nie ma w orga­ni­za­cji zma­te­ria­li­zo­wa­nej posta­ci, jed­nak jest ele­men­tem (poję­ciem) łączą­cym wie­dzę (doku­men­ty), ludzi i ich umie­jęt­no­ści, ich struk­tu­rę oraz regu­ły rzą­dzą­ce tym jak powsta­ją pro­duk­ty pro­ce­sów. Proces biz­ne­so­wy to mecha­nizm łączą­cy poję­cia opi­su­ją­ce orga­ni­za­cję. Są to takie poję­cia jak: wie­dza, regu­ły biz­ne­so­we, pro­ce­du­ry, ludzie i ich struk­tu­ra orga­ni­za­cyj­na, narzę­dzia pra­cy (w tym opro­gra­mo­wa­nie). Całość jest powią­za­na razem (o tych powią­za­niach pisa­łem w arty­ku­le Modelowanie w pro­jek­tach inte­gra­cyj­nych). Dysponujemy kom­ple­tem nota­cji pozwa­la­ją­cych opi­sać orga­ni­za­cję od stóp do głów”: [[BMM]] w sfe­rze moty­wa­cji biz­ne­so­wej, [[BPMN]] w sfe­rze prze­pły­wu pra­cy oraz [[UML]] w sfe­rze sys­te­mów. Opisałem to w arty­ku­le Architektura kor­po­ra­cyj­na z OMG​.org.

Tak więc po co mno­żyć byty? Profesjonalne narzę­dzia CASE, pozwa­la­ją na wyko­rzy­sta­nie opi­sa­nych tu nota­cji (tych chro­nio­nych pra­wa­mi autor­ski­mi nota­cji, raczej nie obsłu­gu­ją albo robią to za dodat­ko­wą opła­tą), OMG dba bar­dzo dobrze o ich spój­ność poję­cio­wą (opi­sa­na w arty­ku­le o SOA). Wydaje mi się, że nowe sys­te­my i fra­me­wor­ki” nie wno­szą żad­nej nowej war­to­ści, budu­ją jed­nak – gdy ich użyć – pew­ne uza­leż­nie­nie od ich twórców.

Przewodnik po Architekturze Korporacyjnej

Mam w ręku książ­kę Guide to Enterprise IT Architecture (Springer Professional Computing, auto­rzy Col Perks, Tony Beveridge). Co praw­da wyda­na w 2003 roku jed­nak, auto­rzy sku­pi­li się na pryn­cy­piach dzię­ki cze­mu uzy­ska­li pew­na ponad­cza­so­wość”. Co praw­da auto­rzy powo­łu­ją się dość czę­sto na TOGAF, ale książ­ka jest nie o TOGAF’ie (jest tu trak­to­wa­ny jako przy­kład ram) a o tym czym jest (jak postrze­gać) archi­tek­tu­rę kor­po­ra­cyj­ną, zwra­ca­ją uwa­gę, że cho­dzi o cel a nie o dokumentację.

Nie jest to abso­lut­nie żaden pod­ręcz­nik, jest to książ­ka ukie­run­ko­wa­na na poka­za­nie czym jest archi­tek­tu­ra kor­po­ra­cyj­na, jakie war­to­ści doda­ne ona wno­si. Mam na swo­jej pół­ce dzie­siąt­ki ksią­żek, wśród nich mam takie, któ­rych nie trak­tu­ję jako pod­ręcz­nik, opis, wzo­rzec dzia­ła­nia (bo gene­ral­nie takich mam mało…), jest to książ­ka, kora daje pogląd, pozwa­la wyro­bić sobie zda­nie. Nie znaj­dzie­cie tu pro­mo­cji AK, nie jest to mate­riał przy­go­to­wu­ją­cy do egza­mi­nu. Polecam te książ­kę jako zebra­na infor­ma­cję czym w ogó­le AK jest. Jest to moim zda­niem bar­dzo dobry przewodnik.

ArchiMate i TOGAF. Czy nie do zastąpienia?

W popu­lar­nym ser­wi­sie o archi­tek­tu­rze kor­po­ra­cyj­nej (Enterprise Architecture, EA), EA Voice, poja­wił się arty­kuł na temat współ­ist­nie­nia” nota­cji ArchiMate oraz BPMN i UML:

Archimate was deli­be­ra­te­ly desi­gned to be map­pa­ble to BPMN and UML, but not to repla­ce them. Not paral­lel uni­ver­ses but com­ple­men­ta­ry ones.

Archimate is for model­ling at an Enterprise Architecture level of deta­il and not at the Solution Architecture and Software deve­lop­ment level of deta­il. BPMN and UML have much more deta­il in them than ArchiMate. Conversely neither BPMN or UML can repla­ce ArchiMate either.

(źr. ArchiMate, BPMN and UML toge­ther | EA Voices).

W pierw­szym zda­niu czy­ta­my, że ArchiMate celo­wo został tak pomy­śla­ny by moż­li­we było mapo­wa­nie na BPMN i UML a nie zastę­po­wa­nie tych nota­cji. Słusznie, gdyż w moich oczach pró­ba wal­ki z tymi nota­cja­mi była by pró­bą samo­bój­czą, mie­dzy inny­mi dla­te­go, że nota­cje rodem z OMG (BPMN i UML nimi są) to spe­cy­fi­ka­cje dar­mo­we, któ­rych moż­na uży­wać komer­cyj­nie bez żad­nych opłat licen­cyj­nych, cze­go nie­ste­ty nie moż­na powie­dzieć o ArchiMate (rocz­ne opła­ty, Licencja ArchiMate).

Dalej czy­ta­my, że ArchiMate to poziom archi­tek­tu­ry kor­po­ra­cyj­nej w prze­ci­wień­stwie do BPMN i UML, któ­re słu­żą do mode­lo­wa­nia szcze­gó­łów archi­tek­tu­ry i imple­men­ta­cji. Tu nie­ste­ty nie wiem to zna­czy poziom archi­tek­tu­ry kor­po­ra­cyj­nej”, oba­wiam się, że to jakiś magicz­ny, nie­zde­fi­nio­wa­ny poziom hipo­te­tycz­nie zastrze­żo­ny” dla EA, TOGAF i ArchiMate. Tu moim zda­niem ma miej­sce jakaś wal­ka” o rząd dusz, The Open Group podej­mu­je pró­by zawłasz­cza­nia poję­cia EA i mode­lo­wa­nia wyż­szych pozio­mów abs­trak­cji. Diagram powy­żej, poka­zu­ją­cy, miej­sce ArchiMate na tle BPMN i UML, to pró­ba takie­go zawłaszczenia.

The Open Group zda­je się igno­ro­wać to, że poję­cie archi­tek­tu­ry kor­po­ra­cyj­ne to nie ich pomysł (ich pomy­łem jest TOGAF, jeden z wie­lu sys­te­mów ram EA). Ignorują tak­że to, że nota­cje BPMN i UML nie mają ogra­ni­cze­nia na budo­wa­nie wyż­szych warstw abs­trak­cji, że ist­nie­je od kil­ku lat nota­cja BMM, któ­ra dosko­na­le (moim zda­niem lepiej niż ArchiMate 2.1) radzi sobie z mode­lo­wa­niem pozio­mu moty­wa­cji biz­ne­so­wej, w tym czyn­ni­ków wpły­wu i ryzy­ka. OMG zadba­ło bar­dzo dobrze o peł­ną wza­jem­ną kom­pa­ty­bil­ność (zgod­ność i nie­sprzecz­ność wspól­nych dla swo­ich nota­cji pojęć) cze­go nie­ste­ty nie moż­na powie­dzieć o zgod­no­ści ArchiMate i BPMN czy UML (pro­ble­my z inter­pre­ta­cją i mapo­wa­niem pojęć ArchiMate: Aktor, Rola, inter­fejs biz­ne­so­wy czy funk­cja apli­ka­cji). Więc teza jako­by nie dało się zastą­pić ArchiMate inny­mi nota­cja­mi, w mode­lo­wa­niu Architektury Korporacyjnej, jest moim zda­niem moc­no naciągana.

Poniżej porów­na­nie jakie wyko­na­łem po poja­wie­niu się ArchiMate 2.0:

Trzy warstwy modelowania

Więcej na temat uży­cia nota­cji OMG w mode­lach archi­tek­tu­ry kor­po­ra­cyj­nej w arty­ku­le Architektura Korporacyjna z OMG. Tak więc mnie widzę w TOGAF/ArchiMate jakiejś szcze­gól­nej prze­wa­gi na inny­mi podej­ścia­mi. Niewątpliwie jed­nak pro­ces cer­ty­fi­ka­cji i licen­cjo­no­wa­nia to rynek, o któ­ry The Open Group wal­czy i to aku­rat rozumiem.

c.d. nt. Architektury Korporacyjnej

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ęć:

Model pojęciowy czterech elementow architektury korporacyjjnej

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 :).

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”:

Jaap Schekkerman Enterprise Architecture
źr. Jaap Schekkerman, How to Survive in the Jungle of Enterprise Architecture Frameworks: Creating or Choosing an Enterprise Architecture Framework

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.

architektura korporacyjna rentowność
Koszty ana­liz i projektowania

(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.