What’s New in Visual Paradigm 13.2? Czyli co nowego…

Kolejna odsło­na w roz­wo­ju opro­gra­mo­wa­nia CASE fir­my Visual Paradigm. Agile, pierw­szych katach chur­ra opty­mi­zmu, zaczy­na trosz­kę się kry­sta­li­zo­wać co zauwa­żył już [[Scott Ambler]] 12 lat temu:

książ­ka trak­tu­ją­ca o tym, że zwin­ność nie ozna­cza bała­ga­nu i pospo­li­te­go rusze­nia. Scott Ambler to kolej­ny auto­ry­tet w inży­nie­rii opro­gra­mo­wa­nia. I mimo, że niko­go nie ma sen­su mał­po­wać, na pew­no war­to się uczyć? (Źródło: Agile Modeling. Effective Practices for Modeling and Documentation | | Jarosław Żeliński IT-Consulting)

Visual-Paradigm to tak­że zestaw narzę­dzi Agile pozwa­la­ją­cych z jed­nej stro­ny zwin­nie zarzą­dzać pro­jek­to­wa­niem i pro­jek­tem (to nie jest to samo) z dru­giej nie zanie­dby­wać ana­li­zy i mode­lo­wa­nia tam gdzie to jed­nak pomaga.

Nowe ele­men­ty v.13.2.:

  1. Kanban Board to nowe narzę­dzie pozwa­la­ją­ce zarzą­dzać zakre­sem pro­jek­tu i jego reali­za­cją. Kanban to opra­co­wa­na w latach pięć­dzie­sią­tych w Japonii meto­da ste­ro­wa­nia pro­duk­cją. Słowo kan­ban w wol­nym tłu­ma­cze­niu moż­na w poniż­szym przy­pad­ku oddać jako ?spis widocz­ny?. Tu prak­tycz­nie ozna­cza to co zna­my pod nazwą bac­klog” tyle, że wer­sji widocz­nej” jako tabli­cę postę­pu prac: bil­bo­ard dostęp­ny dla człon­ków zespołu.
  2. User Story Estimation to nowy para­metr obiek­tów user sto­ry”. Generalnie tu (w tym narzę­dziu) user sto­ry to nie pro­za użyt­kow­ni­ka” a sfor­ma­li­zo­wa­na wer­sja zna­na jako sza­blon ja jako .… chciał­bym osią­gnąć.… mając do dys­po­zy­cji …”, histo­ryj­ki te są para­me­try­zo­wa­ne mie­dzy inny­mi (teraz) esty­ma­cja cza­su ich imple­men­ta­cji co bar­dzo uła­twia zarza­dza­nie projektem.
  3. Kroki wyma­ga­ją­ce potwier­dze­nia, nowa cecha spe­cy­fi­ka­cji przy­pad­ków uży­cia, bar­dzo waż­na rzecz w spe­cy­fi­ko­wa­niu przy­pad­ków uży­cia to wska­za­nie tych kro­ków sce­na­riu­szy, któ­re wyma­ga­ją potwier­dze­nia przez system.
  4. Szybki pod­gląd (tak­że zesta­wie­nie) histo­ry­jek użyt­kow­ni­ka, w toku pro­jek­tu klu­czo­we jest śle­dze­nie pro­jek­tu, któ­ry nie raz ma set­ki deta­li w zakre­sie, od teraz dys­po­nu­je­my odpo­wied­ni­mi zesta­wie­nia­mi i pod­su­mo­wa­nia­mi, to jedy­ny spo­sób na spraw­ne zarza­dza­nie zakre­sem projektu.
  5. Makiety ekra­nów to kolej­ny bar­dzo waż­ny ele­ment komu­ni­ka­cji z zama­wia­ją­cym i defi­nio­wa­niem zakre­su pro­jek­tu, roz­bu­do­wa­na zosta­ła pale­ta ele­men­tów i ich cech.
  6. CMMN (Case Management Model and Notation) to nota­cja opu­bli­ko­wa­na for­mal­nie w 2014 roku. Notacja BPMN ma za cel mode­lo­wa­nie pro­ce­sów biz­ne­so­wych czy­li powta­rzal­nych zacho­wań orga­ni­za­cji, CMMN to narzę­dzie do mode­lo­wa­nia kon­kret­nych (ziden­ty­fi­ko­wa­nych) aktyw­no­ści, nie prze­wi­dzia­nych w mode­lach pro­ce­sów, tak­że do mode­lo­wa­nia pro­po­no­wa­nych (zaak­cep­to­wa­nych) roz­wią­zań, w przy­pad­ku gdy dana aktyw­ność stwa­rza problem.
  7. Zarządzanie pli­ka­mi w repo­zy­to­rium TeamWork (ser­wer) z pozio­mu prze­glą­dar­ki diagramów.
  8. Tymczasowe dia­gra­my ana­li­zy wpły­wu. Do tej pory były zawsze zapa­mię­ty­wa­ne co w dużych pro­jek­tach skut­ko­wa­ło dużą ich licz­bą i prze­cią­ża­niem pro­jek­tu, teraz mogą one być two­rzo­ne w locie” bez koniecz­no­ści ich zachowywania.

Źródło: What’s New in Visual Paradigm 13.2? 

Narzędzie potęż­nie­je z każ­dą kolej­ną wer­sją. Obecnie ofe­ro­wa­ne jest w dwóch wersjach:

  1. Visual-Paradigm (VP) jako narzę­dzie adre­so­wa­ne do wspie­ra­nia pro­ce­sów inży­nie­rii oprogramowania.
  2. ArchiMetric to roz­sze­rze­nie pakie­tu VP, to narzę­dzie wspie­ra­ją­ce pro­wa­dze­nie ana­liz sys­te­mo­wych orga­ni­za­cji, sze­ro­ko poję­te­go mode­lo­wa­nia archi­tek­tu­ry biz­ne­so­wej (kor­po­ra­cyj­nej).

W 2005 roku wybra­łem to narzę­dzie cał­ko­wi­cie przy­pad­ko­wo, kie­ro­wa­łem się cza­sem od momen­tu zamó­wie­nia do uzy­ska­nia licen­cji, bo dzia­ło się w toku bar­dzo waż­ne­go pro­jek­tu, w któ­rym nie mogłem sobie pozwo­lić ani na prze­rwę ani na zna­ki wod­ne eva­lu­ation ver­sion” w doku­men­tach w cza­sie ocze­ki­wa­nia na licen­cje. Po tych latach korzy­sta­nia z VP i porów­ny­wa­nia pra­cy z inny­mi narzę­dzia­mi spo­ty­ka­ny­mi w pro­jek­tach, nadal mam prze­ko­na­nie, że nie­świa­do­mie doko­na­łem wte­dy chy­ba naj­lep­sze­go moż­li­we­go wyboru.

Więcej o nowin­kach w aplikacji:

Visual Paradigm 13.2 intro­du­ces a num­ber of new featu­res, which includes:

(źr. https://​www​.visu​al​-para​digm​.com/​a​b​o​u​t​u​s​/​n​e​w​s​r​e​l​e​a​s​e​s​/​v​p​1​3​2​.​jsp)

Wymagania biznesowe i Siatka Zachmana

Cztery lata temu pisa­łem o książ­ce Ronalda Rossa Building Business Solutions”:

Druga to pozy­cja nowa, cało­ścio­wo opi­su­ją­ca podej­ście pole­ga­ją­ca na mode­lo­wa­niu orga­ni­za­cji w ana­li­zie biz­ne­so­wej (zawie­ra część mate­ria­łu pierw­szej) . Zwraca uwa­gę na fakt, że nie cho­dzi w ana­li­zie o two­rze­nie mnó­stwa dia­gra­mów a o to, by zro­zu­mieć jak orga­ni­za­cja funk­cjo­nu­je opi­su­jąc to, oraz stwo­rzyć model, któ­ry pozwo­li na pro­gno­zo­wa­nie zacho­wa­nia orga­ni­za­cji w odpo­wie­dzi na bodź­ce, nawet te któ­re jesz­cze nie zaist­nia­ły. (Źródło: Business Rule Concepts ? czy­li jak ?wyłu­skać isto­tę rze­czy? | | Jarosław Żeliński IT-Consulting)

Niedawno wpadł mi w skrzyn­kę kolej­ny wpis na blo­gu R.Rossa:

Zachman?s basic pre­mi­se is that whe­ne­ver you engi­ne­er any­thing of com­ple­xi­ty, no mat­ter what ? a com­plex machi­ne, a sky­scra­per, a micro­chip, a spa­ce­craft, a pro­duct, a busi­ness (an enter­pri­se), or some part of a busi­ness (a busi­ness capa­bi­li­ty) ? the­re are two basic aspects that need to be addres­sed. These two aspects cor­re­spond to the columns and rows of the Framework. (Źródło: What the Zachman Architecture Framework Is ? And How It Relates to Business Rules & Business Analysis | Ronald Ross | LinkedIn, Excerpted from: Building Business Solutions: Business Analysis with Business Rules, 2nd edi­tion, by Ronald G. Ross & Gladys S.W. Lam, 2015)

I oka­zu­je się, że zawsze war­to wra­cać do ksią­żek :). Od daw­na pra­cu­je nad uwol­nie­niem spon­so­rów pro­jek­tów od wyma­ga­nia by rozu­mie­li tech­no­lo­gię i teo­rie sys­te­mów. W lite­ra­tu­rze nie raz mozna spo­tkać poję­cie wyma­gań biz­ne­so­wych, pisa­łem o tym trzy lata temu:

Mianem sys­tem okre­śla się zwy­cza­jo­wo spe­cy­fi­ko­wa­ne opro­gra­mo­wa­nie, jed­nak pro­blem poja­wi się natych­miast, gdy dotknie­my takich pojęć jak wyma­ga­nia funk­cjo­nal­ne na opro­gra­mo­wa­nie i wyma­ga­nia biz­ne­so­we. To ostat­nie nie­sie pew­ną nie­ja­sność. Bo nie wiem czy cho­dzi o wyma­ga­nia wobec (w sto­sun­ku do) biz­ne­su (np. popra­wa jako­ści obsłu­gi klien­ta o 5% w naj­bliż­szym bada­niu jako­ści ISO) czy wyma­ga­nia biz­ne­su wobec (w sto­sun­ku do) opro­gra­mo­wa­nia (np. mini­ma­li­za­cja do zera otrzy­ma­nych i zagu­bio­nych zapy­tań ofer­to­wych). (Źródło: Inżynieria wyma­gań | | Jarosław Żeliński IT-Consulting)

Wymieniona wyżej książ­ka Rossa zawie­ra roz­dział Understanding Business Requirements i takie jego sło­wa pod tym tytułem:

RonRossBuildingBusinessSolution_17_1

Model biz­ne­so­wy two­rzy­my by opi­sać daną dzia­łal­ność, może być on tak­że uży­ty do stwo­rze­nia wyma­gań biz­ne­so­wych.” Nieco dalej czytamy:

RonRossBuildingBusinessSolution_17_2

Bardzo waż­ne: wyma­ga­nia biz­ne­so­we defi­niu­je­my wobec sys­te­mu a nie wobec biz­ne­su (fir­my). I to fak­tycz­nie jest powo­dem wie­lu nie­po­ro­zu­mień. W tym samym roz­dzia­le Ross powo­łu­jąc się na Siatkę Zachmana przy­wo­łu­je definicje:

RonRossBuildingBusinessSolution_17_3

Od dłuż­sze­go cza­su sto­su­ję w pro­jek­tach poję­cie Wymagań Biznesowych (opi­sa­ne w cyto­wa­nym wyżej, moim arty­ku­le Inżynieria wyma­gań), i po raz kolej­ny zno­wu, skła­niam się do pró­by wyko­rzy­sta­nia siat­ki Zachmana w tym celu, gdyż jeże­li ten szkie­let archi­tek­to­nicz­ny (Siatka Zachmana to tak zwa­ny szkie­let archi­tek­to­nicz­ny archi­tek­tu­ry kor­po­ra­cyj­nej) fak­tycz­nie pozwo­li spraw­nie zarzą­dzać wyma­ga­nia­mi i ich śla­do­wa­niem, to war­to z tego sko­rzy­stać, na razie porów­nu­je się (nakła­da się) ten szkie­let z MDA i jak widać jest świa­teł­ko w tunelu :):

MDA2Zachman

Dla uła­twie­nia siat­ka Zachmana w pol­skiej wer­sji (kard z pakie­tu Visual-Paradigm).

Siatka Zachmana zakres analizy

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.

Teoria komunikacji, dżungla ram i szkieletów

Jak zro­bić krzyw­dę fir­mie? Skopiować w niej model innej fir­my, nawet naj­lep­szej. Proponując jakiej­kol­wiek fir­mie jakie­kol­wiek zmia­ny było by kom­plet­nym bra­kiem odpo­wie­dzial­no­ści bazo­wa­nie wyłącz­nie na wyczu­ciu, doświad­cze­niu i dobrych prak­ty­kach, bo każ­da orga­ni­za­cja jest inna: inni ludzie, inna histo­ria roz­wo­ju, inna wewnętrz­na kul­tu­ra zarzą­dza­nia. Doświadczenia zdo­by­te w innych fir­mach to tyl­ko kolej­na prak­ty­ka. To jak lekarz: każ­de­go pacjen­ta bada, chce zro­zu­mieć przy­czy­nę cho­ro­by zanim posta­wi dia­gno­zę i zaor­dy­nu­je kura­cję. Lekarz, któ­ry sta­wia­jąc dia­gno­zy, ufa tyl­ko temu cze­go się raz wyuczył jest złym leka­rzem, to jak wysta­wia­nie recept na życze­nie i pod dyk­tan­do pacjen­ta. Więc co robić?

Opiszę naj­pierw kon­tekst, pew­ne aspek­ty teo­rii komu­ni­ka­cji by poka­zać role infor­ma­cji w sys­te­mie – nie aż tak wiel­ką jak to nie raz moż­na prze­czy­tać, potem wspo­mnę o spo­ty­ka­nych ramach i szkie­le­tach” budo­wa­nia archi­tek­tu­ry korporacyjnej .

Od pew­ne­go cza­su wiem, że od lat pisze pro­zą”: two­rząc mode­le orga­ni­za­cji mia­łem zawsze jeden cel – zro­zu­mieć tę orga­ni­za­cję zanim zare­ko­men­du­ję jakie­kol­wiek w niej zmia­ny. Jednak by zro­zu­mieć nale­ży poznać przy­czy­ny obec­ne­go sta­nu rze­czy. By cokol­wiek pro­po­no­wać trze­ba umieć prze­wi­dzieć skut­ki. Jak? Trzeba zbu­do­wać model danej orga­ni­za­cji. Ta pro­za” (czy­li coś co robię od daw­na, a od nie daw­na znam nazwę) to archi­tek­tu­ra korporacyjna.

Nie raz tu już pisa­łem, że model orga­ni­za­cji to pro­ce­sy biz­ne­so­we wraz z ich wyko­naw­ca­mi i zaso­ba­mi oraz usta­no­wio­ny­mi regu­ła­mi i ogra­ni­cze­nia­mi. Organizacja to jej cele i to jak je reali­zu­je. Wobec tego nie jest celem posia­da­nia opro­gra­mo­wa­nia prze­twa­rza­nie i skła­do­wa­nie danych, celem jest wspie­ra­nie ludzi w ich zada­niach a to nie to samo. Dane i ich prze­twa­rza­nie to tyl­ko ślad po tych dzia­ła­niach. Mało jest danych, mają­cych same w sobie coś do zro­bie­nia”, takim przy­pad­kiem są np. sys­te­my BI (hur­tow­nie danych i rapor­to­wa­nie). Ale po kolei.

Zaglądamy do słow­ni­ka j.polskiego PWN:

komu­ni­ka­cja: prze­ka­zy­wa­nie i odbie­ra­nie infor­ma­cji w bez­po­śred­nim kon­tak­cie z dru­gą osobą

komu­ni­kat: infor­ma­cja prze­ka­zy­wa­na w pro­ce­sie bez­po­śred­niej komu­ni­ka­cji z dru­gą osobą

zna­cze­nie: treść, któ­rej zna­kiem jest wyraz lub wyrażenie

infor­ma­cja: wia­do­mość o czymś lub zako­mu­ni­ko­wa­nie czegoś

teaching nauczanieJak widać infor­ma­cja to treść mają­ca zna­cze­nie, jej prze­sy­ła­nie to komu­ni­ka­cja. To tak­że dane prze­twa­rza­ne przez kom­pu­te­ry (a kon­kret­nie przez ich opro­gra­mo­wa­nie). O prze­twa­rza­niu może­my mówić w ode­rwa­niu od kom­pu­te­rów, nie zapo­mi­naj­my, że nasze umy­sły tak­że prze­twa­rza­ją dane.

Tak więc czło­wiek mając jakiś cel, nie raz reali­zu­je go wraz z inny­mi ludź­mi. Aby było to moż­li­we musi im prze­ka­zy­wać swo­je myśli jako cel wyko­ny­wa­nej pra­cy, np. kolej­ny krok do wyko­na­nia, ocze­ki­wa­ny rezul­tat i wie­le innych swo­ich myśli (zna­czeń).

Prosta proś­ba o poda­nie młot­ka wyma­ga naj­pierw wywo­ła­nia (wska­za­nia) oso­by, któ­rą o to pro­si­my. Należy ją nazwać, w myślach wie­my kogo chce­my popro­sić, nie mogąc go dotknąć (szarp­nąć za rękaw ej Ty…”) musi­my naszą myśl ubrać w uni­kal­ną nazwę (np. imię i nazwi­sko), użyć słów nio­są­cych to zna­cze­nie, zro­zu­mia­łych przez odbior­cę tego komu­ni­ka­tu, któ­ry u woła­ne­go odtwo­rzy, w jego umy­śle utwo­rzy myśl, to co chcie­li­śmy mu przekazać.

Zwracam uwa­gę, że celem komu­ni­ka­cji nigdy nie są komu­ni­ka­ty jako takie, a osią­ga­ne efek­ty (wie­my o tym dosko­na­le pod­czas nie­po­ro­zu­mień). Możliwe jest, że będzie­my chcie­li jakieś komu­ni­ka­ty utrwa­lić, wte­dy zna­cze­nia nale­ży zamie­nić na zna­ki, a te utrwa­lić. To pozwo­li adre­sa­to­wi (patrzą­ce­mu na te zna­ki) ode­brać nasz komu­ni­kat mimo naszej nie­obec­no­ści w tym miej­scu i cza­sie (o… prze­cież tak dzia­ła­ją” książ­ki :)). Tak więc ludzie wyko­nu­ją jakieś zada­nia, współ­pra­cu­jąc poprzez zle­ca­nie sobie zadań: komu­ni­ku­ją się.

Ciekawe jest to, że para­dyg­mat obiek­to­wy ma wie­le wspól­ne­go z teo­rią komu­ni­ka­cji (jej malut­ki frag­ment, ideę, wła­śnie poznaliście).

Paradygmat obiek­to­wy to naj­ogól­niej kon­cep­cja mówią­ca, że sys­tem to zespół komu­ni­ku­ją­cych się obiek­tów w celu reali­za­cji okre­ślo­nych zadań. Takie ele­men­ty jak abs­trak­cja, her­me­ty­za­cja, poli­mor­fizm i dzie­dzi­cze­nie to już imple­men­ta­cja (tu wyko­rzy­sta­nie) pojęć z dzie­dzi­ny teo­rii pozna­nia i lin­gwi­sty­ki, bo tam jest mowa o takim poję­ciu jak kla­sa (kla­sy­fi­ka­tor) oraz jego cechach, w szcze­gól­no­ści dzie­dzi­cze­niu i uogól­nia­niu (zna­czeń). (przy­po­mnę, że poję­cie sys­tem nie jest poję­ciem informatycznym).

Pamiętajmy więc, że komu­ni­kat jest środ­kiem osią­ga­nia celu jakim jest osią­gnię­cie ocze­ki­wa­ne­go rezul­ta­tu w kon­tak­cie z inny­mi ludź­mi. Komunikacja, skła­do­wa­nie danych itp. samo w sobie bar­dzo rzad­ko jest celem. Obiekty, w opro­gra­mo­wa­niu pro­jek­to­wa­nym zgod­nie z obiek­to­wym para­dyg­ma­tem, komu­ni­ku­ją się by zre­ali­zo­wać zada­nie. Organizacja to tak­że sys­tem obiek­to­wy w tej konwencji. 

Tak więc wie­my już, że orga­ni­za­cja to dzia­ła­nia dla jakich powsta­ła. Składa się z ludzi, narzę­dzi ich wspie­ra­ją­cych ale tak­że z opi­su tego do cze­go powsta­ła, tre­ści sta­no­wią­cych opis tego, w tym jak dzia­łać. Celem ist­nie­nia orga­ni­za­cji są jej pro­duk­ty a nie infor­ma­cje jakie prze­twa­rza, te są jedy­nie środ­kiem, narzę­dziem osią­ga­nia celu: są wtór­ne wobec powyż­sze­go celu.

Przypomne jesz­cze zno­wu defi­ni­cje poję­cia system:

System (stgr. ??????? sys­te­ma ? rzecz zło­żo­na) ? obiekt fizycz­ny lub abs­trak­cyj­ny, w któ­rym moż­na wyod­ręb­nić zespół lub zespo­ły ele­men­tów wza­jem­nie powią­za­nych w ukła­dy, reali­zu­ją­cych jako całość funk­cję nad­rzęd­ną lub zbiór takich funk­cji (funk­cjo­nal­ność). Z uwa­gi na fakt, że wyod­ręb­nie­nie wszyst­kich ele­men­tów przy­na­le­żą­cych do sys­te­mu bywa w prak­ty­ce nie­kie­dy bar­dzo trud­ne, dla­te­go do bada­nia sys­te­mów wyko­rzy­stu­je się ich uprosz­czo­ne mode­le. Elementy przy­na­le­żą­ce do jed­ne­go sys­te­mu nie mogą jed­nak sta­no­wić jed­no­cze­śnie ele­men­tów przy­na­leż­nych do inne­go sys­te­mu. (cytat WIKI)

Jeden etap wywo­dów za nami.

A teraz popa­trz­my na tę definicję:

Architektura kor­po­ra­cyj­na (Enterprise Architecture) ? jest to opis struk­tu­ry i funk­cji kom­po­nen­tów orga­ni­za­cji (takich jak: stra­te­gia, pro­ce­sy biz­ne­so­we, jed­nost­ki orga­ni­za­cyj­ne, zaso­by danych, sys­te­my infor­ma­tycz­ne oraz infra­struk­tu­ra tele­in­for­ma­tycz­na), wza­jem­nych powią­zań pomię­dzy tymi kom­po­nen­ta­mi oraz pryn­cy­piów i wytycz­nych zarzą­dza­ją­cych ich two­rze­niem i roz­wo­jem w cza­sie. (źr. dr hab. Andrzej Sobczak, http://​archi​tek​tu​ra​kor​po​ra​cyj​na​.pl/)

Jak widać, jest to nie­mal­że para­fra­za” defi­ni­cji poję­cia sys­tem, owe jed­nost­ki orga­ni­za­cyj­ne, zaso­by danych itp. to kon­kret­ne ele­men­ty (obiek­ty, kom­po­nen­ty) sys­te­mu jakim tu jest organizacja.

Troszkę mnie dzi­wi” zrów­ny­wa­nie tych wszyst­kich pojęć: stra­te­gia, pro­ce­sy biz­ne­so­we, jed­nost­ki orga­ni­za­cyj­ne, zaso­by danych, sys­te­my infor­ma­tycz­ne oraz infra­struk­tu­ra tele­in­for­ma­tycz­na”. Osobiście sto­ję na sta­no­wi­sku, że ist­nie­je oma­wia­na wcze­śniej hie­rar­chia: cel, ludzie go reali­zu­ją­cy oraz narzę­dzia tych ludzi. Oprogramowanie to mię­dzy inny­mi te narzę­dzia. Powyższa defi­ni­cja mówi czym jest archi­tek­tu­ra kor­po­ra­cyj­na. Pozostaje mieć jakiś sys­tem for­ma­li­zu­ją­cy ele­men­ty tej definicji.

Niewątpliwie potrzeb­ny jest model o jakim wspo­mnia­łem na począt­ku: by prze­wi­dy­wać zacho­wa­nia orga­ni­za­cji nale­ży zro­zu­mieć mecha­nizm jej dzia­ła­nia. Teraz ciekawostka:

mecha­nizm: 1. zespół współ­pra­cu­ją­cych ze sobą czę­ści maszy­ny lub przy­rzą­du, wyko­nu­ją­cych jakąś pra­cę, 2. spo­sób, w jaki coś powsta­je, prze­bie­ga lub działa.

Tak więc model opi­su­je (wyja­śnia) mecha­nizm dzia­ła­nia, tu orga­ni­za­cji (fir­my). Bez nie­go nie moż­na prze­wi­dy­wać, z akcep­to­wal­nym praw­do­po­do­bień­stwem, zacho­wa­nia się orga­ni­za­cji po wpro­wa­dza­niu jakich­kol­wiek zmian. Jak wspo­mnia­łem na począt­ku, prze­wi­dy­wa­nie bazu­ją­ce wyłącz­nie na wie­dzy histo­rycz­nej (co się dzia­ło ostat­nim razem w podob­nych warun­kach) to nie­ste­ty wró­że­nie z fusów – tren­dy to nic inne­go jak oce­na tego z jakim praw­do­po­do­bień­stwem powtó­rzy się histo­ria. Ta meto­da nie da nigdy wyni­ku w posta­ci cze­goś nowe­go (lite­ra­tu­ra: meto­dy indukcyjne).

Modelowaniem (doku­men­to­wa­niem) tych wszyst­kich omó­wio­nych aspek­tów zaj­mu­je się wła­snie archi­tek­tu­ra kor­po­ra­cyj­na. Mamy wie­le metod jej opi­su. Najczęściej moż­na spo­tkać się z Siatka Zachmana i TOGAF’em. Jednak to nie jedy­ne meto­dy. Z uwa­gi na to, że sta­no­wią rodzaj opis kon­cep­cji i pewien sys­tem pojęć (słow­nik, to nie nota­cje) same z sie­bie nie sta­no­wię for­ma­li­zmu (for­ma­li­zma­mi są nota­cje takie jak np. UML, BPMN, BMM, ArchiMate).

How to survive in the jungle of Enteprice Architecture Frameworks Jaap Schekkerman

Wpadła mi nie­daw­no w ręce książ­ka: How to survi­ve in the jun­gle of Enterpice Architecture Frameworks (autor Jaap Schekkerman, na Amazon​.com dostęp­ny frag­ment w tym spis treści).

Dla mnie po lek­tu­rze tej książ­ki nasu­wa się jeden wnio­sek: moda na TOGAF to mar­ke­ting pro­wa­dzo­ny przez The Open Group. Są inne, moim zda­niem ani gor­sze ani lep­sze, ramy” archi­tek­to­nicz­ne (książ­ka opi­su­je tak­że inne). Podtytuł książ­ki wie­le mówi: Creating or cho­osing an Enterprise Architecture Framework (Tworzenie lub wybór ram archi­tek­tu­ry kor­po­ra­cyj­nej). W zasa­dzie wystar­czy wziąć przy­ta­cza­ną powy­żej defi­ni­cję AE i pod­jąć powyż­szą decy­zję: stwo­rzyć lub wybrać. Nie jest to – two­rze­nie – łatwe, więk­szość więc wybie­ra goto­we, jed­nak to jedy­nie ramy dla­te­go i tak nie da się tu nicze­go zasto­so­wać jak recepty.

Recepty nie ma…a archi­tek­tu­ra to mode­le, te trze­ba utwo­rzyć a naj­pierw prze­ana­li­zo­wać orga­ni­za­cję: to ana­li­za biz­ne­so­wa. Zaryzykuję tezę, że

każ­dy pro­jekt IT powi­nien się zaczy­nać od ana­li­zy i opra­co­wa­nia kom­plet­ne­go mode­lu orga­ni­za­cji (lub sko­rzy­sta­nia z wcze­śniej opra­co­wa­ne­go). Bez tego zarów­no wyma­ga­nia jak i oce­na tego co chce­my osią­gnąć to dzie­ło przy­pad­ku, co sta­ty­sty­ki zda­ją się potwierdzać.

Uważam, że archi­tek­tu­ra kor­po­ra­cyj­na to opis orga­ni­za­cji, a nie coś co trze­ba stwo­rzyć. Tworzenie mode­li orga­ni­za­cji nie two­rzy tych orga­ni­za­cji a jedy­nie je opi­su­je. Odrębną kwe­stią jest oce­na tego co zoba­czy­my i tego na ile te orga­ni­za­cje moż­na optymalizować.

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. Powyższą książ­kę gorą­co pole­cam, jako źró­dło wie­dzy o tym, że takich ram jest wie­le, o tym czym one są, jakie mają wspól­ne cechy i czym się różnią.

TOGAF or not TOGAF więc może Zachman

Badanie przy­dat­no­ści TOGAF/ArchiMate mam chy­ba za sobą (zapew­ne nie na mia­rę dok­to­ra­tu ale trosz­kę jed­nak tak, cho­ciaż…;)). Na stro­nie moje­go kole­gi: ArchitekturaKorporacyjna​.pl (pole­cam ana­li­ty­kom), w jed­nym z arty­ku­łów poja­wia się cie­ka­we stwierdzenie:

TOGAF wska­zu­je, że nie­wła­ści­we pod­czas mode­lo­wa­nia jest bez­po­śred­nie wią­za­nie pro­ce­su [biz­ne­so­we­go, jak sądzę] z apli­ka­cją go wspie­ra­ją­cą ? ele­men­tem pośred­nim powin­na być funk­cja ? czy­li: apli­ka­cja wspie­ra reali­za­cję funk­cji, a funk­cja obej­mu­je cały pro­ces lub jego frag­ment (w zależ­no­ści od pozio­mu dekom­po­zy­cji funk­cji biz­ne­so­wej). (Komentarze do TOGAF ? meta­mo­del zawar­to­ści (cz. II) | Architektura Korporacyjna).

i to jest coś co jako pierw­sze mnie zra­zi­ło w nota­cji ArchiMate: prze­rost poję­cio­wy (roz­drob­nie­nie albo jak kto woli nad­mier­na gra­da­cja). Umieszczenie dodat­ko­we­go poję­cia – funk­cja – pomię­dzy pro­ce­sem biz­ne­so­wym (pamię­ta­my, że samo­dziel­na czyn­ność to tak­że pro­ces) a narzę­dziem pra­cy jakim jest opro­gra­mo­wa­nie wyda­je się sztucz­ne. To trosz­kę jak umiesz­cze­nie pomię­dzy młot­kiem a pro­ce­sem wbi­ja­nia gwoź­dzia funk­cji wbi­ja­nie”, nie wiem jaką war­tość wno­si to do mode­lu, sko­ro mło­tek ma funk­cję (przy­pa­dek uży­cia) wbi­ja­nie” (pamię­taj­my, że opro­gra­mo­wa­nie to narzę­dzie pra­cy akto­ra, zasób).

Prowadzi to do nie­kom­pa­ty­bil­no­ści z sys­te­mem poję­cio­wym para­dyg­ma­tu obiek­to­we­go (MDA/OMG), na któ­ry ArchiMate się powo­łu­je, tym bar­dziej, że jed­nak MDA to stan­dard pro­ce­su obiek­to­we­go two­rze­nia opro­gra­mo­wa­nia więc po co z nim wal­czyć? Testowałem mode­le ArchiMate na ludziach” i oka­zy­wa­ło się, że dla wie­lu z nich tak­że są one nie­in­tu­icyj­ne. Trudno mi też wytłu­ma­czyć ten nad­miar poję­cio­wy: sko­ro w natu­rze” czyn­ność jest wspie­ra­na usłu­gą sys­te­mu” to po co pako­wać mię­dzy nie, mię­dzy tę wód­kę a zaką­skę” ;), poję­cie biz­ne­so­wej funk­cji opro­gra­mo­wa­nia sko­ro ono świad­czy jakąś usłu­gę, bo jest ona funk­cjo­nal­no­ścią tego oprogramowania.

Trzy warstwy modelowaniaAutorzy ArchiMate wska­zu­ją, że tam gdzie ArchiMate jest zbyt ogól­ne, nale­ży użyć odpo­wied­nio BPMN lub UML. Ale tu poja­wia się pro­blem: w UML usłu­ga opro­gra­mo­wa­nia to przy­pa­dek uży­cia powią­za­ny bez­po­śred­nio z akto­rem, któ­ry ma swój cel dzia­ła­nia (uży­cia sys­te­mu w trak­cie reali­za­cji pro­ce­su biz­ne­so­we­go). Czyli usłu­ga opro­gra­mo­wa­nia jest jed­nak poję­cio­wo bez­po­śred­nio zwią­za­na z czyn­no­ścią w pro­ce­sie, któ­rą wspie­ra (cel pra­cy akto­ra). To tyl­ko jed­na z nie­spój­no­ści. Jeżeli uznać, że pro­ces two­rze­nia opro­gra­mo­wa­nia to trzy fazy MDA opi­sa­ne przez OMG czy­li CIM, PIM i PSM (model biz­ne­so­wy, model logi­ki sys­te­mu, model jego imple­men­ta­cji), to nie­ste­ty TOGAF i ArchiMate są z nim nie­kom­pa­ty­bil­ne a TOGAF/ArchiMate nie daje nic w zamian, więc jest problem…

Z dru­giej stro­ny potrzeb­ne jest w każ­dym więk­szym pro­jek­cie upo­rząd­ko­wa­nie wie­dzy o orga­ni­za­cji z pomo­cą mode­li (któ­rych tu będzie wię­cej nią jeden) czy­li zro­zu­mie­nie jej zacho­wa­nia, wyma­ga to uję­cia tych mode­li w struk­tu­rę. Po co? By mieć mier­nik pozwa­la­ją­cy odpo­wie­dzieć na pyta­nie: Czy mamy już wszyst­kie potrzeb­ne mode­le, czy rozu­mie­my tę orga­ni­za­cję. Modele te to: pro­ce­sy biz­ne­so­we oraz obiek­to­we struk­tu­ry opro­gra­mo­wa­nia. Do tego mode­le poję­cio­we i regu­ły biz­ne­so­we. Wszystko to – nota­cje i ich mode­le poję­cio­we – jest bar­dzo dobrze opra­co­wa­ne w przez OMG. Czego bra­ku­je? Metamodelu cało­ści. Tu z pomo­cą przy­cho­dzi tak zwa­na [[Siatka Zachmana]]. Cóż to jest?

Siatka Zachmana (ang. Zachman Framework) ? sza­blon i spo­sób postę­po­wa­nia, któ­ry pozwa­la w spo­sób for­mal­ny i ści­śle ustruk­tu­ra­li­zo­wa­ny defi­nio­wać archi­tek­tu­rę sys­te­mów kor­po­ra­cyj­nych. Używa siat­ki bazu­jąc na sze­ściu pod­sta­wo­wych pyta­niach (Co, Jak, Gdzie, Kto, Kiedy, Dlaczego) zada­nych pię­ciu gru­pom użyt­kow­ni­ków (Planujący, Właściciel, Projektant, Twórca, Podwykonawca) aby przed­sta­wić holi­stycz­ny obraz przed­się­bior­stwa, któ­re jest mode­lo­wa­ne. (Siatka Zachmana ? Wikipedia, wol­na ency­klo­pe­dia).

Taka kom­plet­na siat­ka (matry­ca) wyglą­da tak:

Siatka Zachmana zakres analizy

Jest to peł­ny opis orga­ni­za­cji. Nie zawsze jest potrze­ba two­rze­nia cało­ści. Na eta­pie typo­wej ana­li­zy biz­ne­so­wej i ana­li­zy wyma­gań potrzeb­ne są eta­py CIM i PIM. W siat­ce Zachmana moż­na pomi­nąć zbęd­ne (tu nad­mia­ro­we, Zachman dopusz­cza czę­ścio­we struk­tu­ry) kolum­ny i wier­sze nadal zacho­wu­jąc kom­pa­ty­bil­ność z MDA:

Siatka Zachmana zakres analizy CIM PIM

Powyższe to nic inne­go jak matry­ca pozwa­la­ją­ca zbu­do­wać upo­rząd­ko­wa­ny model orga­ni­za­cji i umie­ścić w nim ist­nie­ją­ce, wspie­ra­ją­ca ją opro­gra­mo­wa­nie i (lub) opi­sać to, któ­re powin­no się w niej poja­wić czy­li wyma­ga­nia. Powyższe mapu­je się w 100% na model MDA: CIM i PIM. Nie trze­ba więc nicze­go zmie­niać a model poję­cio­wy jest spój­ny. Jeżeli ktoś korzy­sta z mode­lu MDA/OMG, bez pro­ble­mu może przy­po­rząd­ko­wać polom (prze­cię­cia wier­szy i kolumn) mode­le nota­cji BPMN, UML i BMM, a tak­że sys­te­my reguł biz­ne­so­wych i słow­nik pojęć dzie­dzi­no­wych. (powyż­sze zrzu­ty ekra­no­we narzę­dzia Agilian)

Z każ­dym kolej­nym pro­jek­tem skła­niam się ku tezie, że Architektura Korporacyjna, jako cało­ścio­we (lub jak kto woli: holi­stycz­ne) podej­ście do doku­men­to­wa­nia (mode­lo­wa­nia) orga­ni­za­cji, bliż­sza jest Siatce Zachmana niż TOGAF’owi, któ­ry w moich oczach jest po pro­tu prze­kom­bi­no­wa­ny i nie­kom­pa­ty­bil­ny z nota­cja­mi, od któ­rych raczej nie ma uciecz­ki (BPMN, UML, BMM a nawet struk­tu­ral­ne ERD i DFD).

Powyższy uprosz­czo­ny (wyłą­czo­ne nie­uży­wa­ne wier­sze i kolum­ny) kształt Siatki Zachmana, coraz czę­ściej słu­ży mi jako zakres pro­jek­tu ana­li­tycz­ne­go i korzeń jego struk­tu­ry. Poszukując mate­ria­łów na ten temat zna­la­złem opra­co­wa­nie opu­bli­ko­wa­ne na stro­nie Business Process Trends już w 2003 roku o wdzięcz­nym tytu­le: [[The Zachman Framework and the OMG’s Model Driven Architecture]]. Poniżej, na zakoń­cze­nie, dwa dia­gra­my zapo­ży­czo­ne z tego opracowania:

- mapo­wa­nie MDA na Siatkę Zachmana:

MDA2Zachman

oraz wska­za­nie, gdzie zasto­so­wać nota­cje UML:

UML2ZachmanPowyższy dia­gram war­to uzu­peł­nić uwa­gą, że zasto­so­wa­nie nota­cji BPMN w obsza­rze pro­ce­sów biz­ne­so­wych wyda­je się być obec­nie znacz­nie roz­sąd­niej­sze (w 2003 roku, nie była sto­so­wa­na), zaś w obsza­rze moty­wa­cji dosko­na­le spra­wu­je się BMM. OMG daje tak­że upo­rząd­ko­wa­ne sys­te­mu zapi­su reguł biz­ne­so­wych i słow­ni­ków pojęć.

TOGAF ma ambi­cje porów­ny­wa­nia się z Siatką Zachmana, jed­nak w moim odczu­ciu obsza­ro­we porów­na­nie – zgod­ność – to nie to samo z kom­pa­ty­bil­ność (tu już jej brak) z sys­te­ma­mi poję­cio­wy­mi (uzna­ny­mi za stan­dar­dy nota­cja­mi), bo to tu tkwi sens i sed­no pro­ble­mu. Jak na razie nie sądzę, by nota­cja ArchiMate – język wyra­zu TOGAF’a – wypar­ło doro­bek OMG, a nie­ste­ty nie jest w sta­nie go zastą­pić. Obecna postać Siatki Zachman v.3.0. to już ugrun­to­wa­na onto­lo­gia. (czy­sty pla­kat ZachmaFramework 3.0, widać na nim bar­dzo waż­ną rzecz: śla­do­wa­nie, mapo­wa­nie pomię­dzy modelami).

Siatka Zachmana w uży­ciu – pakiet Visual-Paradigm.

c.d.n.