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.

Semantic Core czyli bat na szczegóły

Bardzo czę­sto zasta­na­wiam się, nad przy­czy­na­mi pora­żek pro­jek­tów, przy­czy­na­mi tego, że jed­ne są lep­sze inne gor­sze, a gor­szy to taki, któ­ry wymy­ka się spod kon­tro­li a osta­tecz­ny efekt (pro­dukt), uzy­ska­ny po znacz­nie dłuż­szym cza­sie niż pla­no­wa­no, jest zasko­cze­niem dla wszyst­kich. Na to nakła­da się pro­blem prze­ka­zy­wa­nia wie­dzy pomię­dzy kolej­ny­mi eta­pa­mi pro­jek­tu, gdzie naj­więk­szym ryzy­kiem jest zro­zu­mie­nie pro­ble­mu i prze­ka­zy­wa­nie wie­dzy przez same­go zama­wia­ją­ce­go. Gdzie problem?

Ten arty­kuł pole­cam biz­ne­so­wi” któ­ry szu­ka przy­czyn swo­ich pro­ble­mów, i tym (nie tyl­ko ana­li­ty­kom), któ­rzy mają ambi­cje robić coś w kie­run­ku popra­wy tego sta­nu rze­czy, zamiast uzna­wać obec­ne sta­ty­sty­ki za pew­nik bo takie są fakty”.

Wpadłem jakiś czas temu na stro­nę SemanticCore​.ORG, oto krót­ki cytat z pierw­szej strony :

The seman­tic core repre­sents a vision of com­plex sys­tems that are defi­ned and pro­vi­sio­ned based on high-level models. This vision is being pur­su­ed by mul­ti­ple gro­ups in mul­ti­ple orga­ni­za­tions based on a varie­ty of para­digms such as UML, Ontologies, Business Rules, MOF, EDOC, Data Modeling, OWL, SQL, Etc.. It is the intent of the seman­tic core to inte­gra­te the­se diver­se para­digms into fami­ly of lan­gu­ages that leve­ra­ges the­ir com­mo­na­li­ty whi­le taking advan­ta­ge of the­ir uni­que capa­bi­li­ties. We will defi­ne nor­ma­li­zed Meta-Models cap­tu­ring uni­que seman­tics, inde­pen­dent of the nota­tion. […] It is our intent to cre­ate a com­bi­ned sub­mis­sion appro­pria­te for mul­ti­ple OMG ini­tia­ti­ves inc­lu­ding Ontologies, Business Rules, Business Process Modeling and a UML infra­struc­tu­re libra­ry.[…] the seman­tic core will defi­ne models for a fami­ly of onto­lo­gi­cal­ly gro­un­ded models defi­ning all aspects of sys­tems, inc­lu­ding the­ir requ­ire­ments, envi­ron­ment, spe­ci­fi­ca­tion and imple­men­ta­tion. This will ena­ble a trans­i­tion from tra­di­tio­nal and manu­al sys­tems buil­ding tech­ni­qu­es to an auto­ma­ted and human-focu­sed para­digm. (źr. Semantic Core).

Powyżej (moje wytłusz­cze­nia) głów­ne cele tej orga­ni­za­cji (pole­cam zapo­zna­nie się z całą stroną)

  • nasza wizja to zło­żo­ne sys­te­my opi­sy­wa­ne i przed­sta­wia­ne w posta­ci mode­li na wyso­kim pozio­mie abstrakcji,
  • w tym celu defi­niu­je­my znor­ma­li­zo­wa­ny meta­mo­del opi­sa­ny sys­te­mem zna­czeń (seman­ty­ka) nie­za­leż­nym od notacji,
  • two­rzy­my to w zgo­dzie z ini­cja­ty­wa­mi OMG (www​.omg​.org),
  • seman­tic core” okre­śla stan­dar­do­wy zestaw klu­czo­wych pojęć i ich zna­czeń, opi­su­ją­cych wszyst­kie aspek­ty sys­te­mów, w tym ich wyma­ga­nia, oto­cze­nie, spe­cy­fi­ka­cji i implementacje.

Wygląda jak baj­ka ale nie jest tak źle, a coś takie­go jest bar­dzo przy­dat­ne. Nie ma sen­su budo­wa­nie jed­nej mega-nota­cji do wszyst­kie­go, widać to po pra­cach OMG (i po tym, że UML jed­nak nie zastą­pił innych nota­cji, i nikt roz­sąd­ny chy­ba już tego nie pla­nu­je). Jednak uzna­jąc fakt, że uży­wa­my (dobra prak­ty­ka) nota­cji wła­ści­wych dla roz­wią­zy­wa­ne­go pro­ble­mu (zary­zy­ku­ję tezę: wła­ści­wa to moż­li­wie naj­prost­sza i wystar­cza­ją­ca) war­to jed­nak zadbać o ich kom­pa­ty­bil­ność”. Część wspól­na to nie nowa nota­cja, a utrzy­ma­nie spój­no­ści zna­czeń współ­dzie­lo­nych pojęć ist­nie­ją­cych już notacji.

SemanticCore
(źr. SemanticCore​.org)

O złożoności

Na co war­to zwró­cić uwa­gę? Otóż w pro­ce­sie każ­dej więk­szej ana­li­zy poja­wia się zło­żo­ność, nad któ­rą nale­ży zapa­no­wać. Bez tego opa­no­wa­nia poja­wia się coś co zabi­ja pro­jek­ty ana­li­tycz­ne: utra­ta pano­wa­nia nad zło­żo­no­ścią pro­ble­mu, poja­wia­ją się mega-dia­gra­my i mega for­mu­la­rze danych.

Kilka tygo­dni temu, w jed­nym z moich pro­jek­tów, mia­łem oka­zję wejść w mały spór na temat tego, kie­dy udo­ku­men­to­wać szcze­gó­ło­wo spo­sób kla­sy­fi­ka­cji (ozna­cza­nia) pozy­cji budże­to­wych w sys­te­mie zarzą­dza­nia pro­ce­sem two­rze­nia budże­tu i jego reali­za­cji. Zamawiający od razu wcho­dził (wręcz żądał) w szcze­gó­ły, czy­li naście rodza­jów każ­de­go z ogrom­nej licz­by typów wydat­ków. Jeszcze bym dobrze nie ruszył z miej­sca a już został bym zgnie­cio­ny licz­bą tych szcze­gó­łów. Do tego dorzu­ca­no mi peł­ną szcze­gó­ło­wość struk­tu­ry orga­ni­za­cyj­nej (tak­że prze­kła­da się na budżet jako miej­sca wyda­wa­nia środ­ków). Dodam, że struk­tu­ra orga­ni­za­cyj­na zmie­ni­ła się w cią­gu roku trzy razy.

Co z tym zro­bić? Wyrzucić” te szcze­gó­ły na sam koniec! One są na począt­ku zupeł­nie nie­istot­ne (nie licząc zapo­zna­nia się nimi jako obec­nie funk­cjo­nu­ją­cym sys­te­mem), każ­dy zaś kto twier­dzi, że jed­nak są istot­ne już teraz, po pro­stu jesz­cze nie zro­zu­miał ana­li­zo­wa­ne­go problemu.

Problemem są pryn­cy­pia czy­li co i po co” a nie jak”. Owo jak” to dopie­ro pro­jek­to­wa­nie. Tak więc np. budżet, pro­ces jego two­rze­nia a potem reali­za­cji, to jakiś sys­tem pozy­cji budże­to­wych” i zda­rzeń zwią­za­nych z jego reali­za­cją. Jakaś logi­ka tej cało­ści (dalej jako regu­ły biz­ne­so­we i decy­zyj­ne). To jak zosta­nie ozna­czo­na (jakim sym­bo­lem itp.) to efekt tego co chce­my osią­gnąć. Każdy kto chwy­ci się od razu za te szcze­gó­ły (jakieś one są, mamy je już więc dla­cze­go się za nie nie zabrać), zaczy­na od koń­ca i w zasa­dzie zarzu­cił ana­li­zę i odciął sobie (klien­to­wi) moż­li­wość zbu­do­wa­nia opty­mal­ne­go (nowe­go) roz­wią­za­nia (zapew­ne inne­go niż obec­ne) na rzecz obecnego.

Należy na począt­ku pra­co­wać na abs­trak­cji, uogól­nie­niu pozwa­la­ją­cym sku­pić się na kil­ku­na­stu pryn­cy­piach zamiast na tysią­cach szcze­gó­łów. To pierw­sze jest rela­tyw­nie łatwe, to dru­gie w zasa­dzie niemożliwe.

abstraction systemcore_org
(źr. SemanticCore​.org)

Modele

Jak wspo­mnia­no powy­żej, typów mode­li (nota­cji) mamy wię­cej niż jeden. Każdy model (rodzaj mode­lu) ma swój dedy­ko­wa­ny sys­tem pojęć, po ubra­niu go w iko­ny mamy nota­cję (język obraz­ko­wy), czy­li język opi­sa­ny seman­ty­ką (zna­cze­nia pojęć) i syn­tak­ty­ką (ich wza­jem­ne, dopusz­czal­ne rela­cje). Zestaw pojęć powi­nien być dobra­ny sto­so­wa­nie do roz­wią­zy­wa­ne­go pro­ble­mu (wybór wła­ści­wej do eta­pu pra­cy notacji).

Jak wska­za­no wyżej, mamy czte­ry klu­czo­we sys­te­my pojęciowe:

  1. UML czy­li obiek­to­wy para­dyg­mat opi­su i projektowania,
  2. Ontologia (biz­ne­so­wa, sys­te­mo­wa), któ­rą obec­nie repre­zen­tu­ją Model Motywacji Biznesowej (w mię­dzy cza­sie tak­że doro­bił się ikon), SBVR i sys­te­my poję­cio­we opi­sy­wa­nia archi­tek­tu­ry kor­po­ra­cyj­nej, struk­tu­ry organizacji,
  3. Procesy biz­ne­so­we,
  4. Reguły biz­ne­so­we.

Wspólny śro­dek ma już swo­je zarze­wie”. W 2010 roku wyda­no ostat­nią spe­cy­fi­ka­cję Modelu Motywacji Biznesowej (ang. BMM). Można przy­jąć, że ten sys­tem poję­cio­wy (teraz tak­że nota­cja) to ele­ment biz­ne­so­wej onto­lo­gii. Pojawił się w niej doda­tek F zaty­tu­ło­wa­ny Powiązane spe­cy­fi­ka­cje mode­lo­wa­nia w OMG. I co my tu mamy?

Ano mamy stwier­dze­nie, że ta kom­pa­ty­bil­ność jest potrzeb­na. Napisano, że BMM współ­dzie­li pew­ne poję­cia z taki­mi sys­te­ma­mi poję­cio­wy­mi jak:

  1. BPMN (w BMM poja­wia się poję­cie pro­ces biznesowy)
  2. SBVR (BMM tak­że ope­ru­je poję­ciem Reguła Biznesowa)
  3. OSM (Organization Structure Metamodel, BMM uży­wa poję­cia komór­ka organizacyjna”).

Co cie­ka­we poję­cia te mają w OMG wspól­ne defi­ni­cje (te same poję­cia lub poję­cia dają­ce się mapo­wać 1:1). Utrzyma jest zgod­ność roli w pro­ce­sie biz­ne­so­wym i roli jako ele­men­tu struk­tu­ry orga­ni­za­cyj­nej w tych sys­te­mach (OSM, BPMN, BMM).

W spe­cy­fi­ka­cji BMM v.1.1 znaj­dzie­my taki oto diagram:

BMMOvierwiev

Notacje, któ­re wpa­dły” w ręce OMG maja wła­śnie tę bar­dzo pożą­da­ną i przy­jem­ną cechę: są kom­pa­ty­bil­ne. Wspominałem swe­go cza­su o nota­cji ArchiMate (obec­nie nale­ży do The Open Group podob­nie jak i TOGAF). Niestety nie ma tu tej kom­pa­ty­bil­no­ści, mimo że TOGAF nie jest samo­wy­star­czal­nym mode­lem (wyma­ga sto­so­wa­nia innych nota­cji poza ArchiMate), w efek­cie nie widzę moż­li­wo­ści pro­ste­go” zasto­so­wa­nia ram TOGAF”a jako bazo­wej archi­tek­tu­ry kor­po­ra­cyj­nej, bo kolej­ne eta­py uszcze­gó­ła­wia­nia mode­li (a od tego nie ma uciecz­ki w pro­jek­tach) albo będą mia­ły kło­po­ty z jed­no­znacz­no­ścią albo będą wyma­ga­ły jakie­goś dedy­ko­wa­ne­go sys­te­mu tłu­ma­cze­nia pojęć TOGAF na UML, BPMN (BMM nie, bo TOGAF od ostat­niej wer­sji dublu­je – nie wiem czy w 100% i po co – poję­cia mode­lu moty­wa­cji biznesowej.

Nie wymie­ni­łem tu nota­cji UML bo ta słu­ży do obiek­to­we­go mode­lo­wa­nia (para­dyg­mat obiek­to­wy) sys­te­mów. Nie widzę sen­su wpy­cha­nia” jej w dzie­dzi­nę onto­lo­gii zarzą­dza­nia. Paradygmat obiek­to­wy to inne spoj­rze­nie, sys­te­mo­we, opi­su­ją­ce współ­dzia­ła­ją­ce obiek­ty”, jed­nak to wtór­ny model, bo te obiek­ty sys­te­mo­we repre­zen­tu­ją” komór­ki orga­ni­za­cyj­ne, stra­te­gie, regu­ły biz­ne­so­we, doku­men­ty itp. Modele obiek­to­we są dosko­na­łe jako wstęp do pro­jek­to­wa­nia opro­gra­mo­wa­nia imple­men­to­wa­ne­go z pomo­cą obiek­to­wo zorien­to­wa­nych narzę­dzi. Są kom­plet­nie nie­przy­dat­ne jako biz­ne­so­wy sys­tem poję­cio­wy. Owszem, nie raz tu wspo­mi­na­ny DDD (spo­sób mode­lo­wa­nia dzie­dzi­ny sys­te­mu) to pew­ne takie połą­cze­nie, ale to raczej most niż ekwi­wa­lent. Patrząc na ten pro­blem z per­spek­ty­wy MDA (OMG, Model Driven Architecture) model CIM (Computing Independent Model) to powyż­sze mode­le (BMM, BPMN), UML ma zasto­so­wa­nie dla czę­ści PIM (wstęp­ny model imple­men­ta­cji w posta­ci opro­gra­mo­wa­nia) i tu jest dopie­ro miej­sce na DDD.

Tak więc bat na szcze­gó­ły jest: to pro­sta zasa­da od ogó­łu do szcze­gó­łu”, na każ­dym eta­pie mamy sto­sow­ną nota­cję (pro­sty sys­tem pojęć). Należy uogól­niać i mode­lo­wać, i potem stop­nio­wo uszcze­gó­ła­wiać mode­le aż do momen­tu doj­ścia do imple­men­ta­cji dane­go systemu.

TheMetaModelArchitecture

Powyżej obraz z nanie­sio­ny­mi eta­pa­mi [[MDA]] (wię­cej o Model Driven Architecture oraz Meta Object Facility – powyż­szy rysu­nek – na stro­nach OMG). Core Semantic to szczyt (M3) powyż­sze­go. Wymienione wyżej nota­cje to war­stwa M2 (UML dodat­ko­wo obej­mu­je tak­że M1).

Konkluzja jest taka: bazy danych zawie­ra­ją­ce szcze­gó­ło­wość sys­te­mu, pro­jek­tu­je­my na koń­cu. Szczegóły ele­men­tów budże­tu (przy­ta­cza­ny przy­kład) opra­co­wu­je­my dopie­ro jako pomysł na imple­men­ta­cję, mamy to jed­nak dwa pozio­my implementacji:

  1. roz­wią­za­nie pro­ble­mu efek­tyw­ne­go zarzą­dza­nia budże­tem w nowej for­mie np. sys­tem zna­ko­wa­nia pozy­cji budżetowych,
  2. imple­men­ta­cja tego sys­te­mu jako opro­gra­mo­wa­nia wspo­ma­ga­ją­ce­go ten pro­ces w organizacji.

To wszyst­ko powin­no być jed­nak poprze­dzo­ne ana­li­zą. Analiza obec­nej sytu­acji nie pole­ga jed­nak na jej 100% odwzo­ro­wa­niu w doku­men­tach ana­li­tycz­nych, a jedy­nie na pozna­niu w celu zro­zu­mie­nia celu biz­ne­so­we­go, opra­co­wa­nie jego mode­lu, i potem dopie­ro roz­wią­zy­wa­nie pro­ble­mu: jak to osiągnąć.

Na koniec pew­na uwa­ga :). Ktoś może powie­dzieć: biz­nes tego (nota­cje, mode­le itp.) nie rozu­mie. I ma racje, bo to narzę­dzia a nie pro­duk­ty ana­liz. Produktem ana­li­zy dla biz­ne­su są zawsze reko­men­da­cje (wyma­ga­nia na opro­gra­mo­wa­nie to tak­że rodzaj reko­men­da­cji brzmią­cej: zale­cam by takie warun­ki speł­nia­ło to opro­gra­mo­wa­nie). Zamawianie przez biz­nes mode­li jako takich, to jakieś kosz­mar­ne nie­po­ro­zu­mie­nie. To tak jak by np. praw­nik, jako pro­dukt zle­ce­nia opi­nia praw­na” oddał wybra­ny stos kodek­sów z komen­ta­rza­mi. Nie, dobry praw­nik odda­je jed­na stro­nę reko­men­da­cji: opi­nie praw­ną. To, że sko­rzy­stał z tych kodek­sów to jego narzę­dzie pra­cy, moż­li­we, że załą­czy je do tej tej opi­nii (ale raczej jako mate­riał dla inne­go praw­ni­ka lub audytora).