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”

Visual Paragim Agilian 11.0

Pojawiła się ocze­ki­wa­na wer­sja 11 pakie­tu CASE fir­my Visual-Paradigm. Przede wszyst­kim roz­wój pro­duk­tu idzie w kil­ku głów­nych kie­run­kach: wspar­cie dla wizu­al­ne­go pro­jek­to­wa­nia apli­ka­cji (mock-up’y, kolej­ne uła­twie­nia w two­rze­niu i inte­gro­wa­niu mode­li UML), sta­ły roz­wój wspar­cia dla archi­tek­tu­ry kor­po­ra­cyj­nej (to narzę­dzie pozwa­la two­rzyć mode­le powią­za­ne ze sobą, pozwa­la na pro­wa­dze­nie ana­liz wpły­wu i wie­lu innych, wspie­ra tak­że nota­cję ArchiMate) oraz na praw­dę bar­dzo sil­ne wspar­cie dla pra­cy gru­po­wej. Co dzi­siaj ogła­sza producent:

Visual Paradigm International Limited today [16.12.2013] anno­un­ced the rele­ase of Agilian (AG) 11.0, a Visual Modeling tool for Agile Modeler. In this rele­ase, Agilian intro­du­ces 49 new featu­res and enhan­ce usa­bi­li­ty of vario­us types of diagrams.

What’s new in Agilian 11.0?

  • Supported ArchiMate Viewpoint
  • Use Case List
  • Actor List
  • Requirement List
  • Use Case Notes
  • Web wire­fra­me
  • Android pho­ne wireframe
  • Android tablet wireframe
  • iPhone app wireframe
  • iPad app wireframe
  • Desktop appli­ca­tion wireframe
  • Plan and mana­ge deve­lop­ment acti­vi­ty with Tasifier

(New Releases and Feature Enhancements of Visual Paragim Products).

Nowe narzę­dzie wspie­ra­ją­ce pro­ces ana­li­zy wymagań:

W moich oczach to narzę­dzie wysu­wa się na czo­ło w tym seg­men­cie. Koszt vs. uży­tecz­ność zosta­wia w tyle zarów­no dro­gie pro­duk­ty IBM (Rational Rose) jak i mało przy­dat­ne (nie trzy­ma­nie stan­dar­dów) SPARX Enterprise Architect. Do tego pro­dukt VP jest w ok. 80% spo­lsz­czo­ny (pra­ce trwa­ją). pro­jek­ty Rational Rose mogą być impor­to­wa­ne, pro­jek­ty SPARX EA tyl­ko w czę­ści (EA nie respek­tu­je w peł­ni stan­dar­du UML/XMI).

Oprogramowanie Visual-Paradigm to tak­że wspar­cie dla gene­ro­wa­nia kodu, inży­nie­rii wstecz­nej (doku­men­to­wa­nie kodu ist­nie­ją­ce­go), pro­jek­to­wa­nia baz danych i mapo­wa­nia ORM, całe­go pro­ce­su ana­li­zy i rein­ży­nie­rii pro­ce­sów biz­ne­so­wych wraz z testo­wa­niem mode­li i symu­la­cja­mi procesów.

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.

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