Architektura korporacyjna z OMG​.org

Swego cza­su, gdy dowie­dzia­łem się, że nota­cja ArchiMate ma jed­nak być chro­nio­na pra­wa­mi autor­ski­mi przez The Open Group a koszt cer­ty­fi­ka­cji TOGAF to cał­kiem nie­zły haracz, napisałem:

Przyznaję, że rezy­gnu­ję z tej nota­cji jak i z TOGAF?a jako meto­dy­ki. W dwóch pro­jek­tach spraw­dzi­ła się moja hipo­te­za: mode­lo­wa­nie i ana­li­za war­stwy biz­ne­so­wej i IT oraz oce­na wza­jem­nych zależ­no­ści nie wyma­ga nowej nota­cji a dobrze wyko­na­ne­go mode­lu w już zna­nych, wystar­czą nota­cje BMM, BPMN, UML oraz narzę­dzie potra­fią­ce zarzą­dzać rela­cja­mi pomię­dzy obiek­ta­mi na tych mode­lach? zary­zy­ku­ję tezę, że jest to efek­tyw­niej­sze niż two­rze­nie kolej­nych dzie­sią­tek dia­gra­mów ArchiMate. (Pokazać wię­cej z sen­sem? ).

Podstawowym powo­dem jest to, że skąd­inąd dobry pomysł, jakim jest sama archi­tek­tu­ra kor­po­ra­cyj­na, jest obkła­da­ny ide­olo­gią (mar­ke­ting?!) i opła­ta­mi, któ­rych nie rozu­miem (albo raczej rozu­miem, ale nie mam ocho­ty ich pono­sić ;)), moi klien­ci nie raz tak­że nie).

Cóż to jest ta Architektura Korporacyjna (dalej Architektura lub AK)? Ogólnie:

Based on this bro­ade­ning of sco­pe, Enterprise Architecture now covers:

  • Business Architecture
  • Data Architecture
  • Application Architecture
  • Infrastructure Architecture

(pole­cam cały, krót­ki wpis na Business Analyst Interview Questions | Modern Analyst > What is Enterprise Architecture?).

Przytoczę tu pro­stą i bar­dzo dobrą moim zda­niem defi­ni­cję zaczerp­nię­tą z refe­ra­tu [[dr. Andrzeja Sobczaka (SGH)]]:

Architektura kor­po­ra­cyj­na – for­mal­ny opis struk­tu­ry i funk­cji kom­po­nen­tów kor­po­ra­cji (obej­mu­ją­cych ludzi, pro­ce­sy, infor­ma­cje i tech­ni­kę), wza­jem­nych rela­cji pomię­dzy tymi kom­po­nen­ta­mi oraz pryn­cy­pia i wytycz­ne odno­śnie do zarzą­dza­nia pro­jek­to­wa­niem i zarzą­dza­nia zmia­ną tych kom­po­nen­tów w czasie.

Moim zda­niem nie trze­ba nic wię­cej doda­wać. Dla porząd­ku przy­to­czę defi­ni­cję sło­wa pryn­cy­pium ze słow­ni­ka j.polskiego:

pryn­cy­pium, prin­ci­pium [wym. princ-ipium] ?naj­waż­niej­sza dla kogoś lub dla cze­goś zasa­da albo war­tość? (Portal Wiedzy PWN – słow­ni­ki, ency­klo­pe­die, pod­ręcz­ni­ki aka­de­mic­kie, książ­ki spe­cja­li­stycz­ne, repe­ty­to­ria, porad­ni­ki, prze­wod­ni­ki).

Te pryn­cy­pia, to moim zda­niem uzna­nie for­ma­li­zmu w budo­wie mode­li i sfor­ma­li­zo­wa­ne zarzą­dza­nie ich zmianą.

Narzędzia OMG​.org

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. Nie roz­wo­dząc się, całość wyglą­da ogól­nie tak:

Architektura korporacyjna - struktura

Powyższy dia­gram obrazuje:

  • kolej­ne wyma­ga­ne w AK war­stwy (doda­no na szczy­cie tak zwa­ną moty­wa­cję biznesową),
  • mapo­wa­nie zstępujące

W efek­cie, mają zasto­so­wa­nie wska­za­ne narzę­dzia (dia­gra­my, mode­le). Z ich pomo­cą może­my nie tyl­ko opra­co­wać model Architektury Korporacyjnej ale tak­że nad­zo­ro­wać go, budu­jąc macie­rze mapowania.

Tu poja­wia się poję­cie prag­ma­ty­ki w sto­so­wa­niu języ­ka (nota­cji). Ta prag­ma­ty­ka to wspo­mnia­ne już pryn­cy­pia pro­ce­so­we i obiek­to­we, oraz wska­za­ne na dia­gra­mie powy­żej uży­cie pojęć w każ­dej z wymie­nio­nych nota­cji, czy­li co i na co mapu­je­my. Mapowanie wyma­ga dopre­cy­zo­wa­nia seman­ty­ki mode­li czy­li defi­ni­cji pojęć. Jak? Najprościej nie kom­bi­no­wać np. z przy­pad­ka­mi uży­cia na biz­ne­so­we, sys­te­mo­we i inne bo to zupeł­nie nie potrzeb­ne i nie pozwa­la na pro­ste mapowanie.

Jawne mapowanie na diagramach pomiędzy warstwami

Notacja ArchiMate ma moż­li­wość (taki jest jej pośred­ni cel) jaw­ne­go poka­za­nia mapo­wa­nia pomię­dzy obiek­ta­mi warstw na dia­gra­mach. W przy­pad­ku UML też jest to for­mal­nie moż­li­we od wer­sji 2.0, zaś mapo­wa­nia BPMN->UML doko­nu­je się w doku­men­ta­cji (typo­we śla­do­wa­nie Czynność -> Przypadek użycia).

Otóż mapo­wa­nie moż­na poka­zać na wie­le spo­so­bów. Moim zda­niem robie­nie tego na dia­gra­mach, po pierw­sze nie­co je zaciem­nia, po dru­gie i tak nie eli­mi­nu­je przy­dat­no­ści stwo­rze­nia macie­rzy mapo­wa­nia. Ta dru­ga może być wyge­ne­ro­wa­na auto­ma­tycz­nie, jeże­li tyl­ko uży­wa­my dobre­go narzę­dzia CASE (bez nie­go zresz­tą nie wyobra­żam sobie wyko­na­nia żad­ne­go więk­sze­go mode­lu przy zacho­wa­niu roz­sąd­nej pracochłonności).

Po dru­gie nawet śred­ni model, mają­cy kil­ka­dzie­siąt obiek­tów, będzie wyma­gał dużej ilo­ści dodat­ko­wych dia­gra­mów obra­zu­ją­cych samo mapo­wa­nie, któ­re to dodat­ko­we dia­gra­my nie wno­szą war­to­ści doda­nej do pro­jek­tu, bo macierz gene­ro­wa­na auto­ma­tycz­nie z repo­zy­to­rium narzę­dzia CASE i tak jest łatwiej­sza w uży­ciu i per­cep­cji, sta­no­wi też nie­ja­ko auto­ma­tycz­ny wali­da­tor” czy jest ono – mapo­wa­nie – popraw­ne i kompletne.

TOGAF – subiektywnych słów kilka

O tym krót­ko. Wiem, że sta­no­wi swe­go rodza­ju gotow­ca”, ale czy skór­ka war­ta wypraw­ki? Celem budo­wa­nia AK nie jest wdro­że­nie TOGAF”a” (czy też Siatki Zachmann’a), celem jest … no wła­śnie co? O tym na końcu.

W przy­pad­ku TOGAF v 8.x mamy czte­ry obsza­ry modelowania:

  • Business Architecture
  • Data Architecture
  • Applications Architecture
  • Technology Architecture

(źr. The Open Group Architecture Framework Version 8.1.1., nowa wer­sja TOGAF 9, w porów­na­niu z powyż­szym, roz­cią­ga się na ele­men­ty moty­wa­cji biznesowej).

Nie będę się roz­pi­sy­wał na temat wszyst­kich warstw. Kilka słów o jed­nej: Architektura Danych.

TOGAF i ArchiMate (jak ja rozu­miem obie spe­cy­fi­ka­cje) ope­ru­je poję­ciem danych, oddzie­lo­nych od logi­ki biz­ne­so­wej. Obecnie sto­so­wa­ne meto­dy i narzę­dzia w pro­ce­sie wytwa­rza­nia opro­gra­mo­wa­nia opar­te są na para­dyg­ma­cie obiek­to­wym, któ­ry kom­plet­nie igno­ru­je poję­cie wydzie­lo­nych danych jako takich. Mam tu na myśli bazy danych (w szcze­gól­no­ści rela­cyj­ne). Bazy danych, w meto­dach obiek­to­wych, to ele­men­ty imple­men­ta­cji, więc są one poza obsza­rem ana­li­zy i pro­jek­to­wa­nia. Przedmiotem prze­twa­rza­nia w para­dyg­ma­cie obiek­to­wym są obiek­ty biz­ne­so­we wraz z ich wewnętrz­ną logi­ką i zachowaniami.

Jaki jest więc sens brnię­cia wstecz do cza­sów ana­li­zy struk­tu­ral­nej (odręb­nie ana­li­zo­wa­ne i imple­men­to­wa­ne dane i funk­cje ich przekształcania)?

Przypomnę tu tyl­ko deli­kat­nie, że np. celem pro­ce­su sprze­da­ży nie są dane zapi­sa­ne na Fakturze VAT a pozy­ska­nie środ­ków ze sprze­da­ży pro­duk­tów, obiekt biz­ne­so­wy Faktura VAT wraz z regu­ła­mi nali­cza­nia podat­ku, to jakaś mate­ria­li­za­cja tego fak­tu a nie cel sam w sobie. Powoływanie się więc na dane” w moich oczach nie jest żad­nym postę­pem”.

Na zakończenie

Mamy więc pomysł o wdzięcz­nej nazwie Architektura Korporacyjna. Jej defi­ni­cję, moim zda­niem, moż­na spro­wa­dzić do treści:

Architektura Korporacyjna to model i jego doku­men­ta­cja, zawie­ra­ją­cy całą i wystar­cza­ją­cą wie­dzę o tym, co ma wpływ na dostar­cza­nie pro­duk­tu (J.Żeliński)

Po nam to? Po co nam taka doku­men­ta­cja? Przykłady korzy­ści z jej posiadania:

  • mamy na tacy” model sys­te­mu zależ­no­ści (w tym ana­li­za wpły­wu) pozwa­la­ją­cy natych­miast oce­nić ryzy­ka zwią­za­ne z wza­jem­nym wpły­wem na sie­bie pro­ce­sów, ludzi, zaso­bów (np. jakie skut­ki będzie mia­ło wyłą­cze­nie kon­kret­ne­go ser­we­ra czy spóź­nie­nie do pra­cy kon­kret­ne­go pracownika),
  • mamy na tacy” wyma­ga­nia na opro­gra­mo­wa­nie, bez nie­po­trzeb­ne­go zwin­ne­go” ich poszu­ki­wa­nia meto­dą prób i błę­dów, nie­za­leż­nie od tego czy kupu­je­my nowe czy wymie­nia­my (nie­ste­ty, tak zwa­ne zwin­ne meto­dy to nie raz bar­dzo duże kosz­ty zarzu­co­nych bocz­nych ście­żek” odkry­wa­nych burzą mózgów),
  • od razu zauwa­ży­my, że idea posia­da­nia mono­li­tycz­ne­go sys­te­mu ERP II nie bar­dzo ma sens, usztyw­nia orga­ni­za­cje oraz two­rzy potęż­ny [[„sin­gle point of failu­re”]] (zło­śli­wi doda­ją sin­gle point of big cost” :)),
  • i naj­waż­niej­sze: jak tyl­ko prze­pro­wa­dzi­my ana­li­zę i wyko­na­my model AK, szyb­ko wychwy­ci­my tak zwa­ne osie­ro­co­ne wyma­ga­nia na opro­gra­mo­wa­nie, osie­ro­co­ne sta­no­wi­ska pra­cy, osie­ro­co­ne pro­ce­du­ry, … (osie­ro­co­ne: nie­wy­ko­rzy­sty­wa­ne), to nie raz źró­dło samo w sobie – eli­mi­na­cja sie­rot” – ogrom­nych oszczęd­no­ści juz na samym począt­ku projektu,
  • i inne …

Jak tym zarzą­dzać? Na pew­no nie ręcz­nie, bez opro­gra­mo­wa­nia CASE w zasa­dzie nie­re­al­ne. Czy to kosz­tow­ne? Hm… kła­nia się ana­li­za ROI, każ­da orga­ni­za­cja ma swój próg ren­tow­no­ści. Jednak od sie­bie powiem tak: oszczęd­no­ści poja­wia­ją się natych­miast w posta­ci iden­ty­fi­ka­cji sie­rot”. Kolejny etap oszczęd­no­ści to reor­ga­ni­za­cja kosz­tów i ryzyk zarzą­dza­nia orga­ni­za­cją, kosz­tów posia­da­nia opro­gra­mo­wa­nia, kosz­tów jego roz­wo­ju, kosz­tów zaku­pu i two­rze­nia. Dobra wia­do­mość: począ­tek każ­dy już ma w posta­ci pro­wa­dzo­nej doku­men­ta­cji w dzia­le HR.

Jak więc wyglą­da­ją narzę­dzia rodem z OMG, któ­re w zupeł­no­ści wystarczą??

Jest to zestaw nota­cji (BMM, BPMN, UML), któ­ry ma nie­mal­że każ­dy pakiet CASE. Notację ArchiMate mają nie­ste­ty tyl­ko nie­któ­re z nich, a jak The Open Group zacznie egze­kwo­wać opła­ty licen­cyj­ne to będzie chy­ba tyl­ko gorzej (co cie­ka­we sami twó­cy ArchiMate piszą, że uszcze­gó­ło­wie­nie mode­lu AK wyko­na­ne­go z pomo­cą ArchiMate wyma­ga uży­cia nota­cji UML). Koszty jed­nej licen­cji pakie­tu CASE (nie raz wystar­czy mieć jed­ne­go Architekta w orga­ni­za­cji) w wie­lu przy­pad­kach nie prze­kra­cza­ją 1000USD. Jeżeli więc uda się unik­nąć kolej­nej ana­li­zy wyma­gań za kil­ka­dzie­siąt tysię­cy to już ROI mamy w kieszeni.

A po co te for­ma­li­zmy (pryn­cy­pia)? Na eta­pie ana­li­zy i mode­lo­wa­nia pozwa­la­ją wery­fi­ko­wać popraw­ność mode­li i całej struk­tu­ry. Na eta­pie zarzą­dza­nia zmia­ną pano­wać nad kosz­ta­mi zmian i ryzy­ka­mi w rodza­ju i czasopisma”…:)

Druga dobra wia­do­mość: spo­koj­nie moż­na to (rola Architekta) out­so­ur­so­wać, będzie jesz­cze taniej.

Inne artykuły na podobny temat

Komentarze

  1. jacek2v 3 stycznia 2013 at 22:53

    Czyli OooMyGood 🙂
    Kiedyś bar­dzo sza­no­wa­łem OMG za CORBA, ale jak zaczę­li kom­pli­ko­wać bez umia­ru, prze­sta­ło mi się to podobać.

    • Jarek Żeliński 4 stycznia 2013 at 07:42

      OMG to kil­ka­dzie­siąt róż­nych spe­cy­fi­ka­cji, nie ocze­kuj­my że każ­da każ­de­mu przy­pa­su­je. To co moim zda­niem dobre­go wno­si ta orga­ni­za­cja to stan­da­ry­za­cja. Każdy stan­dard, któ­ry OMG wchło­nie”, a w zasa­dzie przyj­mie (tam się apli­ku­je), sta­je się po pierw­sze otwar­ty (z zasa­dy nie pod­le­ga paten­to­wa­niu czy ochro­nie mająt­ko­wej) po dru­gie zosta­je dodat­ko­wo dopra­co­wa­ny od stro­ny teo­re­tycz­nej (widać to ład­nie po zmia­nach jakie zaszły w nota­cji BMM). To trosz­kę jak z języ­ka­mi, moż­na sobie odpu­ścić i pisać slan­giem, nie dbać o skład­nie, wtrą­ca bez powo­du wyra­że­nia obco­ję­zycz­ne, pro­wa­dzi to jed­nak to zawę­ża­nia licz­by odbior­ców takie­go tek­stu. Ma głę­bo­ki sens pury­stycz­ne uży­wa­nie języ­ka (tak­że wła­sne­go). Rolą OMG nie jest uprasz­cza­nie a ujed­no­li­ca­nie. Jednak rolą ich jest tak­że sil­ne opar­cie tego co robią na teo­rii, co z jed­nej stro­ny bar­dzo poma­ga w utrzy­ma­niu spój­no­ści tych stan­dar­dów, z dru­giej pozwa­la utrzy­mać ich nauko­wy cha­rak­ter, czy­li przy­dat­ność tak­że do prac aka­de­mic­kich (podob­nie zresz­tą jak języ­ki pro­gra­mo­wa­nia). Nadmiarowość to nie to samo co komplikowanie.

  2. RF 4 stycznia 2013 at 09:09

    Panie Jarosławie, jestem wiel­kim zwo­len­ni­kiem Pańskiej filo­zo­fii i kul­tu­ry infor­ma­tycz­nej i nie­jed­no­krot­nie czer­pię z tego inspiarację 😉

    Powyższa wykład­nia EA – Data Architecture jest jed­nak dale­ko idą­cym uprosz­cze­niem całej kon­cep­cji. Wydaje mi się, że tro­chę depre­cjo­nu­jesz rolę Architekta Danych (w uję­ciu EA) i spro­wa­dzasz ją do pozio­mu Projektanta Baz Danych. To o nie o to tu cho­dzi. Fizyczny model danych to poten­cjal­nie jeden z deli­ve­ra­bles” archi­tek­tu­ry i wca­le nie naj­waż­niej­szy. Celem archi­tek­tu­ry danych jest stwo­rze­nie pew­ne­go porzad­ku, zasad, upo­rzad­ko­wa­nie seman­ty­ki, zarza­dza­nia, etc. Ma to szcze­gól­ne zna­cze­nie w przy­pad­ku kor­po­ra­cji, dużych orga­ni­za­ji gdzie rela­cje biz­ne­so­we są zło­żo­ne, sys­te­mów i baz danych są set­ki czy tysiące.

    Taka mała reflek­sja, któ­ra przy­szła mi na myśl po prze­czy­ta­niu Twojego artykułu.

    Pozdrawiam,
    RF

    • Jarek Żeliński 4 stycznia 2013 at 14:15

      Przyznaję, że nie­co zaata­ko­wa­łem” poję­cie Data Architecture (taka mała pro­wo­ka­cja ;)), ale to efekt tego z czym się spo­ty­kam. Nie jestem guru TOGAF’a ale widu­ję czę­sto doku­men­ty trak­tu­ją­ce owe dane jako model danych”, stąd mój opór. Problem jaki spo­ty­kam w wie­lu pro­jek­tach to myle­nie pojęć (nie wiem czy na pew­no wła­śnie myle­nie). Mamy takie obiek­ty biz­ne­so­we jak: Faktura VAT, opis pro­duk­tu, umo­wa, doku­ment prze­wo­zo­wy, doku­ment WZ, i masa innych ale ope­ru­je­my taki­mi dany­mi jak: dane adre­so­we pod­mio­tów gospo­dar­czych, dane adre­so­wa­ne osób, dane o pro­duk­tach ofe­ro­wa­nych, dane wła­sne fir­my, itp… (uogól­nia­jąc: dane o wybra­ne atry­bu­ty obiek­tów). Pytanie brzmi: czym jest tu Data Architecture? W obec­nie pro­jek­to­wa­nych i wyko­rzy­sty­wa­nych sys­te­mach obiek­to­wych (jeże­li fak­tycz­nie są w tym para­dyg­ma­cie pro­jek­to­wa­ne i imple­men­to­wa­ne) obiek­tem jest np. Faktura VAT, Adres pod­mio­tu to może być tak zwa­ny ValueObject (albo atry­bu­ty obiek­tu Faktura VAT), jed­nak dane w bazie z pola­mi uli­ca, nr pose­sji, nr loka­lu, mia­sto, kod itp… to dane w bazie danych, zapew­ne znor­ma­li­zo­wa­nej czy­li total­na siecz­ka. Przeciętny śmier­tel­nik w orga­ni­za­cji nie ope­ru­je dany­mi o doku­men­ta­mi czy­li obiek­ta­mi biznesowymi. 

      Z cze­go i na co mapo­wać dane” i czym one tu są? Gdzie widzę pro­blem”? Czynność Wystawienie Faktury VAT w pro­ce­sie sprze­da­ży, przej­dzie” (mapo­wa­nie) w usłu­gę sys­te­mu (jego przy­pa­dek uży­cia) Wystawienie Faktury VAT (czyn­ność ma wej­ście i wyj­ście, przy­pa­dek uży­cia ma dane począt­ko­we i dane wytwo­rzo­ne). Dokument Faktura VAT jest inte­gral­ną” czę­ścią tej usłu­gi (bo ona bez tego doku­men­tu nie zaist­nie­je). Jedyne miej­sce gdzie leżą” Faktury VAT jako coś”, to model dzie­dzi­ny (kla­sy) i kon­kret­ne obiek­ty w sys­te­mie” (bo na tym pozio­mie nie w bazie”). Ja tu nadal szu­kam” jakiejś zasa­dy, ale jak na razie dane” na pozio­mie archi­tek­tu­ry kor­po­ra­cyj­nej nijak mi tu nie pasu­ją.… ale mogę się mylić :). Moim zda­niem jest tu potęż­na nie­kon­se­kwen­cja” w TOGAF’ie, zresz­tą seman­ty­ka ArchiMate nie pasu­je w 100% do UML mimo, że jej auto­rzy zazna­cza­ją, że uszcze­gó­ło­wie­nie mode­li ArchiMate nale­ży (moż­na) two­rzyć w BPMN i UML zależ­nie od warstwy. 

      Ot zagwozd­ka…

  3. RF 4 stycznia 2013 at 21:55

    Przeciętny śmier­tel­nik w orga­ni­za­cji nie roz­róż­nia pojęć pro­ces, wyma­ga­nie, regu­ła biz­ne­so­wa etc. Przeciętny infor­ma­tyk ma pro­blem z abs­trak­cją, kon­cep­cją, logi­ką i fizy­ką czy to danych czy cze­go­kol­wiek innego. 

    Zgadzam się, że TOGAF czy też inne fra­me­wor­k’i” z archi­tek­tu­rą w tle jest cza­sem nie­kon­se­kwent­ny i moż­na lawirować/interpretować pew­ne defi­ni­cje w zależ­no­ści od per­spek­ty­wy. Biorąc pod lupę jed­nak Architekturę Danych to w TOGAF brzmi ona mnie wię­cej tak: Logiczny i fizycz­ny opis struk­tu­ry danych oraz zaso­bów do zarzą­dza­nia nimi”.

    Projektant/Programista uda­ją­cy archi­tek­ta zacznie od ERD, typów i rela­cji – i pew­nie to jest trak­to­wa­ne jako głów­ny arte­fakt archi­tek­to­nicz­ny i być może myl­nie (lub z peł­nym prze­ko­na­niem) jest to nazwa­ne archi­tek­tu­rą danych.

    W mojej defi­nicj Architaktura Danych to nie tyl­ko struk­tu­ra fizycz­na i logicz­na ale przedew­szyst­kim te zaso­by do zarzą­dza­nia nimi”. Tutaj, bar­dzo krót­ko – sze­ro­ko poję­te Data Management kie­ro­wa­ny przez rolę typu: Lead Data Modeler, Chief Data Architect, Corporate Data Architect etc. Głównym celem archi­tek­tu­ry danych jest nie ERD prak­ty­ki rodza­ju: Data Governance, Data Quality, Data Standards, Data Stewardship etc. 

    Być może traf­niej­szym okre­śle­niem był­by ter­min Data Management zamiast Data Architecture ale to pozo­sta­wiam The Open Group 🙂 Osobiście w IT w moim wyko­na­niu roz­róż­niam dodat­ko­wo jesz­cze jed­ną archi­tek­tu­rę: Integration Architecture i jestem nie­zmier­nie zain­te­re­so­wa­ny wyni­ka­mi Data Architecture oraz Business Architecture. 

    Pozdrawiam,
    RF

    • Jarek Żeliński 4 stycznia 2013 at 23:59

      Teraz rozu­miem i zga­dzam się :). Z każ­dym kolej­nym pro­jek­tem nara­sta moje zaufa­nie” do obiek­to­we­go para­dyg­ma­tu… dane to narzę­dzie pra­cy a nie byt sam w sobie, czło­wiek ma wie­le umie­jęt­no­ści, wie tak­że kie­dy się uro­dził i jak się nazy­wa, jed­nak to czło­wiek coś robi a nie jego imię i nazwi­sko, to ostat­nie słu­ży jedy­nie do iden­ty­fi­ka­cji. System IT co naj­wy­żej gro­ma­dzi dane o ludziach, jeże­li jest czymś wię­cej niż reje­strem, potra­fi zacho­wy­wać się zgod­nie z prze­wi­dzia­ny­mi recep­tu­ra­mi… :), pro­blem pole­ga na tym, że oddzie­le­nie «wie­dzy o tym jak” o d wie­dzy co” pro­wa­dzi do utra­ty kon­tek­stu czy­li tego czym cha­rak­te­ry­zu­ją się meto­dy strukturalne. 

      Architektura Danych to dla mnie obiek­ty biz­ne­so­we”, Architektura Biznesowa… cóż to takie­go :), chy­ba że mowa o obiek­to­wy model organizacji…

Dodaj komentarz

Twój adres email nie zostanie opublikowany

Komentuj i zadawaj pytania autorowi.

Identyfikator *
E-mail *
Witryna internetowa

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.