Wczoraj mia­ła miej­sce kon­fe­ren­cja: Business Intelligence GigaCon 2011. Więcej tu: Hurtownie danych jako stan­dar­do­we modu­ły COTS (Commercial off the shelf) nowo­pro­jek­tow­nych sys­te­mów dedy­ko­wa­nych December 6th.

Poruszyłem mię­dzy inny­mi pro­ble­ma­ty­kę: aspek­ty pro­jek­to­we sys­te­mów dedy­ko­wa­nych i dosto­so­wy­wa­nych oraz ?core doma­in? i poję­cie COTS (Szczegółowe infor­ma­cje http://​giga​con​.org/​b​i​_​2​011).

Nie jest moim celem powie­la­nie tu refe­ra­tu, dla­te­go tyl­ko kil­ka kwe­stii a potem mała uwa­ga na temat metod argu­men­ta­cji osób rekla­mu­ją­cych swo­je pro­duk­ty, ale po kolei.

Hurtownia danych jako skład historii

W swo­im refe­ra­cie wska­za­łem na hur­tow­nie danych i meto­dy skła­do­wa­nia tam danych oraz na poję­cie sys­tem dedy­ko­wa­ny”. I tak:

  1. MIT: Oprogramowanie dedy­ko­wa­ne to kosz­tow­ne, dłu­go wyko­ny­wa­ne i ryzy­kow­ne, pro­jek­ty two­rze­nia opro­gra­mo­wa­nia od zera dla klienta,
  2. PRAWDA: Oprogramowanie dedy­ko­wa­ne to opro­gra­mo­wa­nie (System) zapro­jek­to­wa­ne na bazie dobrze opi­sa­nych wyma­gań, zło­żo­ne z kom­po­nen­tów (typo­we goto­we kom­po­nen­ty to ERP, CRM, SCM, inne).

To zna­czy, że doce­lo­wo – jako sys­tem dedy­ko­wa­ny – klient otrzy­ma zestaw zin­te­gro­wa­nych kom­po­nen­tów (pod­sys­te­mów, apli­ka­cji). Możliwe jest, że nie­któ­re zosta­ną opra­co­wa­ne i wyko­na­ne spe­cjal­nie dla nie­go. Pełny Zintegrowany System wspo­ma­ga­ją­cy zarzą­dza­nie (wszyst­kie apli­ka­cje w fir­mie) naj­czę­ściej nawet w 90% skła­da się z opro­gra­mo­wa­nia goto­we­go (COTS ? Commercial of the shelf).

Kolejnym mitem jest teza, że koszt inte­gra­cji jest duży. Powiem tak: zły pro­jekt zawsze koń­czy się wyso­ki­mi kosz­ta­mi, pro­jekt inte­gra­cyj­ny także.

Praktyka poka­zu­je, że popraw­nie posta­wio­ne wyma­ga­nia oraz pro­jekt wyko­na­ny przed wybo­rem roz­wią­za­nia, to naj­czę­ściej pro­jek­ty, w któ­rych kosz­ty inte­gra­cji są wie­lo­krot­nie niż­sze od kosz­tów kasto­mi­za­cji sys­te­mów zin­te­gro­wa­nych ERP i para­dok­sal­nie trwa to krócej.

Po trze­cie wdra­ża­nie eta­pa­mi (apli­ka­cja po apli­ka­cji) pozwa­la na to, by te poszcze­gól­ne pod­sys­te­my pra­co­wa­ły na sie­bie bez cze­ka­nia na cał­ko­wi­te zakoń­cze­nie wdro­że­nia cało­ści, jak to ma miej­sce naj­czę­ściej pod­czas wdra­ża­nia duże­go i zin­te­gro­wa­ne­go sys­te­mu. Warto tak­że zauwa­żyć, że taka – tak zwa­na kom­po­nen­to­wa – archi­tek­tu­ra jest łatwa w mody­fi­ka­cji (moż­li­wa jest wymia­na dowol­ne­go skład­ni­ka bez szko­dy dla innych cze­go nie moż­na powie­dzieć o dużych sys­te­mach ERP). Przykład z sys­te­ma­mi BI (Business Inteligence), któ­re będę tu zwał Raportowaniem.

Ogólnie wyma­ga­nia na sys­tem wspo­ma­ga­ją­cy zarzą­dza­nie maja taką strukturę:

Diagram Przypadek uzycia

Diagram jest pro­sty. Chcę zwró­cić uwa­gę na to, że wie­le funk­cjo­nal­no­ści (może nawet wszyst­kie) sys­te­mów wspo­ma­ga­ją­cych zarzą­dza­nie moż­na na takie dwie kate­go­rie podzie­lić. Przypomnę, że dia­gra­my przy­pad­ków uży­cia to nie pro­jek­ty sys­te­mu” a ich spis tre­ści”. Projektem, na wyso­kim pozio­mie abs­trak­cji (ang. HLD czy­li [[Hihg Level Design]]), jest dopie­ro to:

Model komponentow

Załóżmy, że archi­tekt sys­te­mu stwo­rzył powyż­szy model. Decyzja pro­jek­to­wa: sys­tem trans­ak­cyj­ny obsłu­gu­je naszą spe­cy­fi­kę biz­ne­so­wą, jest odpo­wie­dzią na wyma­ga­nie: Obsługa tego co się teraz dzie­je. Opracowano dokła­da­nie wyma­ga­nia, na ryn­ku nie zna­le­zio­no wyma­ga­nych funk­cjo­na­li­ści i ta część sys­te­mu zosta­nie wytworzona.

W ramach wyma­gań jed­nak, jak widać na poprzed­nim dia­gra­mie, mamy tak­że wyma­ga­nie: Pokaż co wyda­rzy­ło się kie­dyś. Są to funk­cjo­nal­no­ści rapor­to­we. Raportowanie jako funk­cja sys­te­mu jest dość dobrze opa­no­wa­na, są na ryn­ku goto­we pro­duk­ty (jest ich wie­le). Więc z pro­jek­tu deve­lo­per­skie­go (opro­gra­mo­wa­nie pro­jek­to­wa­ne) wyłą­czo­no ten zakres i kupio­no pod­sys­tem, popu­lar­nie zwa­ny hur­tow­nia danych. Większość tego typu apli­ka­cji ma bar­dzo dobre, uni­wer­sal­ne inter­fej­sy, więc ich inte­gra­cja nie sta­no­wi żad­ne­go problemu.

System trans­ak­cyj­ny, pro­jek­to­wa­ny, w ogó­le nie zaj­mu­je się histo­rią, prze­twa­rza wyłącz­nie dane bie­żą­ce dzię­ki cze­mu stał się znacz­nie prost­szy, czy­taj tań­szy w wyko­na­niu. Wszelkie dane o histo­rycz­nych sta­nach naszych danych są w hur­tow­ni danych a tę mamy już goto­wą, taniej niż koszt wytwo­rze­nia podob­ne­go systemu.

I tak: ta część, któ­ra opi­su­je spe­cy­fi­kę naszej orga­ni­za­cji (ozna­czo­na na nie­bie­sko), to tak zwa­ne core doma­in” czy­li głów­ny ele­ment dzie­dzi­ny sys­te­mu. Jeżeli nie znaj­dzie­my na ryn­ku pro­duk­tu, któ­ry w 100% mu odpo­wia­da nale­ży wydzie­lić taki frag­ment i stwo­rzyć sobie dedy­ko­wa­ny. Kastomizacja goto­we­go pro­duk­tu zawsze jest kom­pro­mi­sem, naj­czę­ściej bar­dzo kosz­tow­nym. (wię­cej o prak­ty­ce pro­jek­to­wa­nia zwa­nej DDD).

Pojecie [[COTS (Commercial off the shelf)]], o któ­rym już na blo­gu nie raz wspo­mi­na­łem, to tu nasz goto­wy kom­po­nent: hur­tow­nia danych. W efek­cie wszel­kie funk­cjo­nal­no­ści zwią­za­ne z rapor­to­wa­niem imple­men­tu­je­my w tej hur­tow­ni, pozo­sta­łe musi­my wytwo­rzyć. To dodat­ko­wa korzyść: baza danych sys­te­mu trans­ak­cyj­ne­go sta­je się dużo prost­sza, czy­taj tań­sza, bo model danych nie musi obsłu­gi­wać historii”.

Jeżeli potrzeb­ne nam zaawan­so­wa­ne meto­dy rapor­to­wa­nia i ana­liz nale­ży raczej zaku­pić apli­ka­cję z rodza­ju Business Inteligence zamiast zle­cać dostaw­cy sys­te­mu (np. ERP) kolej­ne imple­men­to­wa­nie wyra­fi­no­wa­nych – kosz­tow­nych w opra­co­wa­niu i utrzy­ma­niu – raportów.

Przy oka­zji: uży­cie hur­tow­ni danych w tle”, to nic inne­go jak clo­ud com­pu­ting :), tu tak zwa­na chmu­ra prywatna”.

Demagogia na konferencji

Z ust oso­by pro­mu­ją­cej pewien pro­dukt zali­czo­ny do Business Intelligence padło stwier­dze­nie: Nasz pro­dukt jest pro­sty, pobie­ra dane do rapor­tów bez­po­śred­nio z sys­te­mu ERP, nie musi­my więc dodat­ko­wo inwe­sto­wać w pośred­ni­czą­cy sys­tem hur­tow­ni danych, kto­ry może mieć dane nie­ak­tu­al­ne. Tezę tę miał poprzeć dia­gram podob­ny do tego:

Demagodia OLAP vs Proste BI

U góry mam skom­pli­ko­wa­ny sys­tem BI” a na dole nasz pro­sty i łatwy w obsłu­dze sys­tem”. To jak by usu­nąć zie­lo­ny kom­po­nent z powyż­sze­go dia­gra­mu kom­po­nen­tów. Gdzie haczyk? Ano tu:

Model danych ERP vs OLAP

Górny dia­gram to przy­kład mode­lu danych dla hur­tow­ni danych. Jest pro­sty, w prak­ty­ce sko­men­to­wa­ny po ludz­ku”, jako meta­da­ne, jest czymś, z czym może pra­co­wać każ­dy, kto tyl­ko zna daną dzie­dzi­nę, taki model danych (tak zwa­na gwiaz­da) odwzo­ro­wu­je w pro­sty spo­sób zna­ne biz­ne­so­we pojęcia.

Diagram niżej to model danych nie­wiel­kie­go sys­te­mu biz­ne­so­we­go (model danych sys­te­mu ERP, mają­cy nawet tysią­ce rela­cyj­nych, nic nie mówią­cych zwy­kłe­mu śmier­tel­ni­ko­wi tabel, był­by w tej pro­por­cji zwy­kłą kolo­ro­wą nie­czy­tel­ną pla­mą…). Wykonanie samo­dziel­nie jakie­go­kol­wiek rapor­tu z tego dru­gie­go sys­te­mu tabel gra­ni­czy z cudem. Można przy­go­to­wać (admi­ni­stra­tor bazy) tak zwa­ne wido­ki” dla użyt­kow­ni­ków co nie zmie­nia fak­tu, że ich opra­co­wa­nie to wie­dza tajem­na” i nikt z biz­ne­su” sam tego nie zro­bi. I naj­waż­niej­sze: dostęp do peł­ne­go mode­lu danych naj­czę­ściej wyma­ga zła­ma­nia zasad bez­pie­czeń­stwa to jest udo­stęp­nie­nia danych z pomi­nię­ciem mecha­ni­zmów kon­tro­l­nych apli­ka­cji ERP.

Hurtownia danych to model stwo­rzo­ny pod kątem prze­twa­rza­nia fak­tów histo­rycz­nych na pro­stym mode­lu danych (dia­gram powy­żej, gór­ny, to tak zwa­na kost­ka OLAP). Opracowanie takie­go mode­lu wyma­ga spe­cjal­nej ana­li­zy i pro­jek­tu, ale nie zapo­mi­naj­my: ana­li­zę się robi raz a rapor­ty sta­le… tu prze­szko­lo­ny użyt­kow­nik biz­ne­so­wy sam daje radę bez problemu.

Tak więc sza­now­ni Państwo. Jeśli tyl­ko Wasza fir­ma jest bli­żej czo­łów­ki niż ogo­na ran­kin­gu ryn­ku w Waszej bran­ży, nie daj­cie się namó­wić na jeden zin­te­gro­wa­ny ERP i jakiś model refe­ren­cyj­ny, bo nawet jak uda się go wdro­żyć, to zmia­na cze­go­kol­wiek będzie trud­na a upgra­de do now­szej wer­sji nie­moż­li­wy. Opracowanie pro­jek­tu sys­te­mu skła­da­ją­ce­go się z kom­po­nen­tów, pozwo­li Wam dobrać naj­le­piej speł­nia­ją­ce Wasze wyma­ga­nia apli­ka­cje. Jak z kloc­ków LEGO moż­na zło­żyć dedy­ko­wa­ny sys­tem” poma­ga­ją­cy utrzy­mać prze­wa­gę na ryn­ku, a nie cofa­ją­cy Waszą fir­mą do pozio­mu innych pod­mio­tów w bran­ży”.

Prognozowanie

Problem w tym, że z tych samych danych róż­ne fir­my ana­li­tycz­ne potra­fią wycią­gnąć róż­ne wnio­ski. Nie mam wąt­pli­wo­ści, że w naj­bliż­szych cza­sie cze­ka nas wysyp firm spe­cja­li­zu­ją­cych się w ana­li­zie danych pły­ną­cych z inter­ne­tu, ale póki co, wnio­ski są fru­stru­ją­ce: nie potra­fi­my wia­ry­god­nie prze­wi­dy­wać tren­dów ryn­ko­wych. (Piotr Podleśny, pre­zes fir­my Atena, źr. Prognozy wyma­ga­ją zro­zu­mie­nia danych – Computerworld).

Nauka wyka­za­ła, że sama ana­li­za danych histo­rycz­nie nie sta­no­wi żad­nej pro­gno­zy. Do tak zwa­nej pre­dyk­cji wyma­ga­ny jest model przed­mio­tu”, któ­re­go zacho­wa­nia chce­my prze­wi­dy­wać. Czy to moż­li­we? Tak. Czy to łatwe? Znowu odpo­wiem: nie. Potrzebny jest model a nie tyl­ko dane histo­rycz­ne (te pozwa­la­ją wyłącz­nie na ana­li­zę tego co było), wię­cej o tym w arty­ku­le o meto­dach nauko­wych ana­li­zy.

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).

Ten post ma jeden komentarz

  1. Bogusław

    Dziękuję, za to że jest ktoś kto ma siły demen­to­wać mar­ke­tin­go­we bzdu­ry. Wraz z upły­wem cza­su ilość zło­to­ustych sprze­daw­ców rośnie w zastra­sza­ją­cym tem­pie. Rzetelność to coraz rza­dziej spo­ty­ka­na przy­pa­dłość”.

Dodaj komentarz

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