Biznes wychodzi z objęć systemu … monolitycznego ERP

Koniec roku się zbli­ża, czas na pod­su­mo­wa­nia i pro­gno­zy :), pierw­sze publi­ka­cje już są. Co się pisze o ERP:

Monolityczne roz­wią­za­nia wspie­ra­ją­ce zarzą­dza­nie to prze­szłość. Dziś liczą się: wszech­stron­ność, otwar­tość na zmia­ny, pro­sto­ta obsłu­gi, moż­li­wo­ści inte­gra­cyj­ne. Wybór naj­lep­sze­go sys­te­mu ERP sta­je się coraz trud­niej­szy. (za Biznes wycho­dzi z objęć sys­te­mu – Computerworld).

Jak osią­gnąć wszech­stron­ność i otwar­tość na zmia­ny”? Na począ­tek może małe review moich wcze­śniej­szych tek­stów na ten temat:

Przewiduję powol­ne odcho­dze­nie od idei sys­te­mów zin­te­gro­wa­nych. Dotychczasowa ich zale­ta czy­li peł­na inte­gra­cja prze­sta­je być zale­tą a sta­je się gar­bem. System zin­te­gro­wa­ny moż­na już ?skle­ić? ze spe­cja­li­zo­wa­nych apli­ka­cji, kom­po­nen­tów. […] Drugim powo­dem prze­wi­dy­wa­ne­go odej­ścia od tej idei są ogrom­ne kło­po­ty z oce­ną ren­tow­no­ści wdro­że­nia sys­te­mu ERP. Nie raz jest to po pro­stu wręcz nie­moż­li­we z powo­du bra­ku moż­li­wo­ści oce­ny jakim kosz­tem wspie­ra­my poje­dyn­czy pro­ces biz­ne­so­wy bo trud­no z jed­ne­go ogrom­ne­go sys­te­mu wykro­ić” koszt wspar­cia poje­dyn­cze­go pro­ce­su. (Marzec 2007, Czy to już nad­cho­dzą­cy koniec zin­te­gro­wa­nych ERP?)

Jeżeli dostaw­ca duże­go ERP mówi, że duży ERP jest naj­lep­szy to nale­ży to trak­to­wać tak samo jak ofer­tę dostaw­cy duże­go zesta­wu garn­ków ze sta­li nie­rdzew­nej, z któ­rych i tak na co dzień uży­wa­my jed­ne­go a nale­śni­ki i tak robi­my z pomo­cą kupio­nej wcze­śniej dobrej teflo­no­wej patel­ni bo do nale­śni­ków lep­sza a zamia­na jej na nową z nie­rdzew­ki tyl­ko dla­te­go, że ?z kom­ple­tu? prze­czy zdro­we­mu roz­sąd­ko­wi i uży­wa się jej mimo, że pokryw­ka z zesta­wu lek­ko wysta­je ? ale przy­kry­wa bo taki jest jej głów­ny cel (w zasa­dzie tyl­ko nie powin­na być mniej­sza ani zbyt duża). (Listopad 2009 Nigdy wię­cej ERP w jed­nym kawał­ku!).

Jak zacząć? Najpierw ana­li­za tego co i jak robi­my. Potem podział tego na obsza­ry stan­dar­do­we, któ­re obsłu­ży­my narzę­dziem uni­wer­sal­nym i pozo­sta­łe, któ­rych z regu­ły jest bar­dzo mało ale są bar­dzo waż­ne dla nas. te dru­gie obsłuż­my po swo­je­mu ale nie pakuj­my się w niszo­we lub prze­sta­rza­łe tech­no­lo­gie. Nie dawaj­my tak­że wia­ry w to, że kup­no tego co ma (powie­le­nie tego co robi) nasz kon­ku­rent uczy­ni nas bar­dziej kon­ku­ren­cyj­ny­mi bo prak­ty­ka poka­zu­je coś zupeł­nie odwrot­ne­go. (sier­pień 2010, Wymagania na opro­gra­mo­wa­nie ERP wspo­ma­ga­ją­ce zarzą­dza­nie: dwie kup­ki).

Nowe sys­te­my zin­te­gro­wa­ne ERP będą pew­ny­mi zesta­wa­mi goto­wych funk­cjo­nal­no­ści, zbu­do­wa­ny­mi w opar­ciu o szkie­le­ty opro­gra­mo­wa­nia zaś inte­gra­cja będzie bazo­wa­ła nie na współ­dzie­le­niu danych, a na wymia­nie ich pomię­dzy modu­ła­mi i zewnętrz­ny­mi sys­te­ma­mi na rów­nych pra­wach. Rozwój sys­te­mu w takim przy­pad­ku pole­ga na two­rze­niu nowych modu­łów tym śro­do­wi­sku a nie na mody­fi­ka­cji już ist­nie­ją­cych. (Styczeń 2011, Frameworks Introduction ? czy­li jak się psu­je dobre ERP).1

Bo nie­za­leż­nie od tego jak ?uni­wer­sal­ny? jest sys­tem ERP zawsze będzie gor­szy od kil­ku dobrze dobra­nych ale nie­za­leż­nych kom­po­nen­tów. Gorszy nie dla­te­go, że ?brzyd­szy? ale dla­te­go, że będzie kulą u nogi fir­my, któ­ra powin­na jed­nak reago­wać na zmia­ny na ryn­ku w cią­gu tygo­dni a nie lat? Po dru­gie mody­fi­ka­cja jakie­go­kol­wiek opro­gra­mo­wa­nia zawsze wyma­ga testo­wa­nia cało­ści, tak więc im mniej­sze kawał­ki mamy tym szyb­ciej i taniej wpro­wa­dza się do nich zmia­ny bo ich odda­nie do użyt­ku po mody­fi­ka­cji jest łatwiej­sze i szyb­sze zara­zem. Pamiętajmy pew­ną sta­rą rekla­mę: ?Banki od wszyst­kie­go są do nicze­go??. (Kwiecień 2011, Czego naj­bar­dziej bra­ku­je sys­te­mom kla­sy ERP?).

Od lat mówi się o SOA, jako o meto­dzie budo­wy i inte­gra­cji sys­te­mów (tu już mamy inte­gra­cję a nie tyl­ko zdal­ne uży­cie). Jednak poja­wia się tu potrze­ba two­rze­nia pośred­ni­czą­ce­go, kosz­tow­ne­go, ele­men­tu archi­tek­tu­ry (ESB) co sku­tecz­nie ogra­ni­czy­ło zasto­so­wa­nie tej meto­dy (a raczej tech­no­lo­gii) inte­gra­cji sys­te­mów. Cloud Computing to zupeł­nie inne podej­ście. To kom­po­nen­to­wa archi­tek­tu­ra zna­na od lat. (Październik 2011, Cloud Computing to archi­tek­tu­ra sys­te­mu).2

Pojawia się teza:

ERP jest dziś narzę­dziem do gro­ma­dze­nia i skła­do­wa­nia wszel­kich infor­ma­cji potrzeb­nych do podej­mo­wa­nia decy­zji w biz­ne­sie. Jako takie jest dziś waż­niej­sze niż kie­dy­kol­wiek wcze­śniej” – pod­kre­śla Nidal Haddad.3 (za Biznes wycho­dzi z objęć sys­te­mu – Computerworld).

Jeżeli fak­tycz­nie tak dostaw­cy postrze­ga­ją sys­te­my ERP (co zresz­tą wyda­je się być wła­ści­we) to nie dzi­wi fakt, że np. zarzą­dza­nie doku­men­ta­mi, wspo­ma­ga­nie prze­pły­wu pra­cy (work­flow) czy wspo­ma­ga­nie podej­mo­wa­nia decy­zji (sys­te­my rapor­to­we, busi­ness inte­li­gen­ce) to coraz czę­ściej jed­nak odręb­ne, inte­gro­wa­ne pod­sys­te­my. Widać ten trend już na ryn­ku. Np. jeden z lide­rów ryn­ku ERP, fir­ma SAP, kupił pro­dukt (fir­mę) Business Object włą­cza­jąc go do swo­jej ofer­ty jako narzę­dzie BI,4 do zarzą­dza­nia doku­men­ta­mi i ich prze­pły­wem SAP pole­ca dedy­ko­wa­ny do tego celu sys­tem OpenText. 5SAP nie jest tu jedy­nym dostaw­cą ERP. Podobną stra­te­gię zaczy­na­ją pre­zen­to­wać i inni lide­rzy ryn­ku ERP. Tak więc już nie jeden ERP II… O czym to świad­czy? O roz­pa­dzie” idei sys­te­mu zintegrowanego:

Uniwersalność opro­gra­mo­wa­nia wspie­ra­ją­ce­go zarzą­dza­nie powo­du­je, że zacie­ra­ją się histo­rycz­ne podzia­ły bran­żo­we. Wcześniej myśla­no o sys­te­mach kla­sy ERP jako o narzę­dziach dają­cych prze­wa­gę kon­ku­ren­cyj­ną. Dzisiaj roz­wią­za­nia tego typu sta­ły się bar­dziej powszech­ne. Standaryzacja poprzez ERP nie daje prze­wa­gi nad kon­ku­ren­cją” – pod­kre­śla Tomasz Bejm, Technology Consulting Leader w fir­mie PrcewaterhouseCoopers.3.

I jak widać nie ja jeden tak uwa­żam, powie­la­nie roz­wią­zań nie daje prze­wa­gi a wręcz ją zabi­ja. wspo­mi­na­łem o tym już w 2007 roku (cytat na począt­ku tekstu).

Pora na Cloud Computing:

Analitycy są zgod­ni, że szcze­gól­ną rolę w zakre­sie roz­wo­ju opro­gra­mo­wa­nia biz­ne­so­we­go odgry­wać będzie tech­no­lo­gia Cloud Computing. W mia­rę roz­wo­ju tech­no­lo­gii inter­ne­to­wych spo­dzie­wać się moż­na wzro­stu uży­tecz­no­ści opro­gra­mo­wa­nia biz­ne­so­we­go ofe­ro­wa­ne­go w mode­lu usłu­go­wym.3 .

Jednak tu nale­ży się pew­ne wyja­śnie­nie. Cloud Computing (CC) to nie zwy­kły out­so­ur­cing opro­gra­mo­wa­nia w posta­ci zna­nej od ponad 10 lat jako ASP czy ostat­nie SaaS (oso­bi­ście nie widzę róż­ni­cy poza tech­no­lo­gią). CC to roz­bu­do­wa­ne, ofe­ro­wa­ne na ryn­ku, goto­we do uży­cia kom­po­nen­ty. Moim zda­niem poda­wa­nie jako przy­kła­du CC roz­wią­zań, któ­rych uży­wa się jak innych apli­ka­cji jest błę­dem. CC to coś do posze­rza moż­li­wo­ści posia­da­ne­go opro­gra­mo­wa­nia ale w tle:

Moim zda­niem każ­dy, chcą­cy liczyć się na ryn­ku dostaw­ca ERP, w zasa­dzie musi się z tym pogo­dzić lub wypad­nie z ryn­ku. Najpierw rynek zmu­sił dostaw­ców ERP do udo­stęp­nia­nie inter­fej­sów inte­gra­cyj­nych, tak zwa­nych API (ang. appli­ca­tion pro­gam­ming inter­fejs) , choć nadal są opor­tu­ni­ści wśród dostaw­ców tych sys­te­mów. Teraz pora pogo­dzić się z tym, że powsta­ją (będą) kom­po­nen­ty roz­sze­rza­ją­ce funk­cjo­nal­no­ści pod­sta­wo­wych wer­sji ERP a koszt udo­stęp­nie­nia API (licen­cjo­no­wa­nie) będzie spa­dał. Możliwości udo­stęp­nia­ne przez te API od pew­ne­go cza­su pozwa­la­ją już na budo­wa­nie ?chmur?6.

Podsumowanie

Rynek sta­le się roz­wi­ja i doj­rze­wa. Praktycznie każ­da więk­sza fir­ma doświad­czy­ła w jakiejś for­mie wdro­że­nia goto­we­go, dosto­so­wy­wa­ne­go do potrzeb, opro­gra­mo­wa­nia ERP. Warto jed­nak pod­kre­ślić, że idea jed­ne­go super sys­te­mu” ERP II, odcho­dzi powo­li do lamu­sa. Moim zda­niem to kwe­stia roku, dwóch. Pierwsze symp­to­my to zale­ce­nia pro­du­cen­tów dużych sys­te­mów: wdra­żać goto­we opro­gra­mo­wa­nie w posta­ci goto­wej” tyl­ko tam gdzie pasu­je, obsza­ry spe­cy­ficz­ne dla fir­my opi­sać i zapro­jek­to­wać dla nich dedy­ko­wa­ne roz­wią­za­nie i zin­te­gro­wać. Dobry sys­tem ERP to śro­do­wi­sko pro­gra­mi­stycz­ne (tak zwa­ny fra­me­work, szkie­let). Systemy, nazwę je zapóź­nio­ne”, nadal wyma­ga­ją inge­ren­cji w ich kod by cokol­wiek osią­gnąć. Kompromisem jest sytu­acja, w któ­rej sys­tem ERP ma boga­ty inter­fejs (tak zwa­ne [[API, Application Programming Interface]]) pozwa­la­ją­cy na inte­gra­cję dedy­ko­wa­nych pod­sys­te­mów lub wła­śnie zewnętrz­nych kom­po­nen­tów czy­li korzy­sta­nia z moż­li­wo­ści jakie daje Cloud Computing). Przyszłość to komponenty…

(J.Ż. 2011)

Rok 2018

Polskie fir­my odcho­dzą od wdra­ża­nia sys­te­mów mono­li­tycz­nych. W cza­sach cyfro­wej trans­for­ma­cji i dyna­micz­nych zmian na ryn­ku trwa­ją­ce ponad rok wdro­że­nia mono­li­tycz­nych sys­te­mów ERP nie zapew­nia­ją dosta­tecz­nej ela­stycz­no­ści. Długotrwałe, czę­sto kasto­mi­zo­wa­ne roz­wią­za­nia prak­tycz­nie unie­moż­li­wia­ją wpro­wa­dza­nie nowych funk­cji czy zmia­nę logi­ki sys­te­mu w trak­cie wdro­że­nia. Oznacza to duże ryzy­ko utra­ty jego zasad­no­ści przed zakoń­cze­niem prac, a jesz­cze więk­sze, zanim zaku­pio­ny sprzęt czy licen­cje zosta­ną zamor­ty­zo­wa­ne. Monolityczne sys­te­my wią­żą przed­się­bior­stwo z okre­ślo­nym dostaw­cą, co w śred­niej i dłu­giej per­spek­ty­wie cza­so­wej utrud­nia wpro­wa­dza­nie zmian i zwięk­sza kosz­ty. 7

Przypisy

1.
Frameworks… IT​-Consulting​.pl. https://it-consulting.pl//index.php/2011/02/03/frameworks-introduction-czyli-jak-sie-psuje-dobre-erp/. Published April 17, 2018. Accessed April 17, 2018.
2.
Cloud Computing. IT-Consulting. https://it-consulting.pl//index.php/2011/10/11/cloud-computing-to-architektura-systemu/. Published April 17, 2018. Accessed April 17, 2018.
4.
SAP Software Solutions | Business Applications and Technology. SAP. . Published April 17, 2018. Accessed April 17, 2018.
5.
SAP Software Solutions | Business Applications and Technology. SAP. . Published April 17, 2018. Accessed April 17, 2018.
6.
Zelinski J. Cloud com­pu­ting – czy aby na pew­no nowin­ka… | Jarosław Żeliński IT-Consulting. Jarosław Żeliński IT-Consulting – Analiza Biznesowa i Systemowa, Wymagania. https://it-consulting.pl//index.php/2010/11/25/cloud-computing-czy-aby-na-pewno-nowinka/. Published November 25, 2010. Accessed April 17, 2018.

Zarządzanie zmianą w projekcie analitycznym

No cóż, temat się w roz­mo­wach powta­rza, jest nie łatwy więc kil­ka słów. Pomijając narzę­dzie, któ­rym się tu posłu­żę, cho­dzi o pryn­cy­pia” :): bez­pie­czeń­stwo pro­jek­tu oraz zarzą­dza­niem wer­sja­mi, zmia­ną, w tym wymaganiami.

Zarządzanie zmia­ną

Po pierw­sze wyda­je mi się, że chy­ba naj­lep­szym spo­so­bem na zarzą­dza­nie wer­sja­mi, zmia­na­mi, śle­dze­niem pro­jek­tu itp. są wypra­co­wa­ne mecha­ni­zmy zna­ne każ­de­mu kto korzysta(ł) z takich narzę­dzi do zarzą­dza­nia pro­jek­ta­mi jak SVN ([[Subversion]]) czy [[CVS]]. Chodzi o coś co się nazy­wa: znacz­ni­ki, gałę­zie, wersje.

Projekt ma tak zwa­ną linie głów­ną (base­li­ne, trunk). Jednak w trak­cie prac nad pro­jek­tem war­to cza­sem stwo­rzyć odno­gę” pro­jek­tu. Pozwala to po pierw­sze wydzie­lić pod­pro­jekt” (gałąź) dla zespo­łu by pano­wać nad zmia­na­mi w taki spo­sób, by jeden zespół na eta­pie pro­jek­to­wa­nia nie zakłó­cał pra­cy dru­gie­go. W dowol­nym momen­cie moż­na porów­nać oba pro­jek­ty i nawet je scalić.

W efek­cie mamy moż­li­wość roz­dzie­le­nia pra­cy dwóch (lub wię­cej) zespo­łów nad jed­nym pro­jek­tem. Po dru­gie nawet, jeże­li ana­li­tyk sam pra­cu­je nad pro­jek­tem, ma moż­li­wość testo­wa­nia swo­ich pomy­słów bez psu­cia” zasad­ni­cze­go pro­jek­tu. Po takich pra­cach moż­na pro­jekt zosta­wić i sca­lić to co wyszło najlepiej.

Jak widać jeden pro­jekt może mieć tak­że znacz­ni­ki (tagi). Załóżmy, że pra­cu­je­my na pro­jek­tem, mają­cym eta­py roz­wo­ju. Wtedy np. odda­je­my doku­men­ta­cję w wer­sji np. 1.0 i pra­cu­je­my dalej. Aby póź­niej moż­li­we było porów­na­nie wer­sji obec­nej z wer­sją wypusz­czo­ną” wcze­śniej, wystar­czy odwo­łać się do ozna­czo­nej takim znacz­ni­kiem wer­sji (zwa­nej w slan­gu Rewizją ;)) i prze­śle­dzić róż­ni­ce jak poniżej:

Na bie­żą­co, może­my śle­dzić kto i kie­dy co zała­do­wał na ser­wer, cof­nąć się do wcze­śniej­szej wer­sji by porów­nać efek­ty pra­cy róż­nych człon­ków zespo­łu, albo pra­cu­jąc same­mu, porów­nać pomy­sły nowe z wcze­śniej­szy­mi i wybrać najlepszy.

Kopia bez­pie­czeń­stwa

Bardzo waż­ne jest to, że nasz kom­pu­ter nie był jedy­nym miej­sce prze­cho­wy­wa­nia pro­jek­tu. Tu uwi­dacz­nia się zyska­na przy oka­zji” cecha pra­cy z ser­we­ra­mi kon­tro­li wer­sji: nie tyl­ko zarzą­dza­ją wer­sja­mi ale tak­że prze­cho­wu­ją kopie naszych pro­jek­tów. Panujemy więc nad wszyst­kim, mamy dodat­ko­wo kopię bezpieczeństwa.

Narzędzia kom­pa­ty­bil­ne z SVN pra­cu­ją w try­bie off-line client-server, wiec są bar­dzo wygod­ne bo nie obcią­ża­ją sie­ci i pozwa­la­ją pra­co­wać bez dostę­pu do niej co nie raz jest wygod­ne. Scalanie wer­sji jest bez­piecz­ne, wszel­kie kon­flik­ty wer­sji (wykry­te zmia­ny po stro­nie ser­we­ra i po naszej) są od razu moni­to­wa­ne, mamy moż­li­wość świa­do­me­go ich rozwiązywania.

Na zakoń­cze­nie

Na koniec dodam, że nie­któ­rzy dostaw­cy posze­rza­ją moż­li­wo­ści swo­ich narzę­dzi (np. moje, tu opi­sy­wa­ne) i pozwa­la­ją na wer­sjo­no­wa­nie nie tyl­ko pli­ku z pro­jek­ta­mi UML czy BPMN (że nie wspo­mnę o kodzie pro­jek­tu), ale tak­że pozwa­la­ją na sko­ja­rze­nie z pro­jek­tem fol­de­ru na dys­ku i wte­dy cała jego zawar­tość, w szcze­gól­no­ści pli­ki pdf od klien­ta, doku­men­ta­cja w pli­kach word, rtf, notat­ki itp. pod­le­ga powyż­szym mecha­ni­zmom zarzą­dza­nia (wer­sjo­no­wa­nie i kopia bezpieczeństwa).

Czemu o tym pisze? Bo mnie pyta­ją klien­ci i nie tyl­ko :). Czy to waż­ne? Tak! Tak pro­wa­dzo­ny pro­jekt jest bar­dzo bez­piecz­ny, szcze­gól­nie gdy ser­wer pro­jek­tu jest hosto­wa­ny w bar­dzo dobrze admi­ni­stro­wa­nej, bez­piecz­nej ser­we­row­ni a pli­ki są szy­fro­wa­ne pod­czas trans­fe­ru. Efektywność pra­cy w takim try­bie jest tak­że dużo większa.

Tak więc gorą­co pole­cam pra­cę z SVN (i inny­mi podob­ny­mi) i narzę­dzia CASE kom­pa­ty­bil­ne z nim. Zainteresowanych powy­żej opi­sa­nym narzę­dziem TWS zapra­szam tu: http://​www​.visu​al​-para​digm​.com/​p​r​o​d​u​c​t​/​v​p​t​s​/​p​r​o​v​i​d​e​s​/​m​a​n​a​g​e​m​e​n​t​.​jsp

Hurtownie danych czyli Systemy od historii”

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.

Czas nie jest aktorem dla Systemu c.d. czyli projekt

i uda­ło się. Ciąg dal­szy tek­stu Czas nie jest akto­rem dla Systemu, zapra­szam do lektury.

Prosty przy­kład (na opi­sa­nie bom­by w sie­ci inter­net się nie odwa­ży­łem ;)). Produkt jaki ma powstać to syre­na sygna­ło­wa. Wymaganie funk­cjo­nal­ne: sys­tem powi­nien pozwa­lać na zapro­gra­mo­wa­nie godzi­ny i cza­su trwa­nia sygna­łu. Wymaganie poza-funk­cjo­nal­ne: dokład­ność zega­ra pro­gra­ma­to­ra ma być nie gor­sza niż błąd rzę­du sekun­dy w ska­li roku (:)).

Wersja pierwsza

Diagram pro­sty (wprost mode­lo­wa­ne wyma­ga­nia zama­wia­ją­ce­go) za to imple­men­ta­cja już nie. Diagram przy­pad­ków uży­cia, jego celem jest opi­sa­nie wyma­gań funk­cjo­nal­nych, czy­li tego jakie sys­tem ma ofe­ro­wać usłu­gi albo jak kto woli serwisy:

Diagram enig­ma­tycz­ny ale do tego słu­ży ten typ dia­gra­mu: akto­rzy i usłu­gi dla nich (tak zwa­ny korzeń pro­jek­tu). W tej posta­ci (pierw­sza ite­ra­cja ana­li­zy i pro­jek­to­wa­nia) otrzy­ma­my np. taki pro­jekt archi­tek­tu­ry (logi­ki) systemu:

Jak widać sys­tem skła­da się z dwóch pod­sta­wo­wych kom­po­nen­tów: Sterownika i Generatora Dźwięku czy­li syre­ny wła­ści­wej ;). Sterownik jest imple­men­to­wa­ny (znak Realizacji) z pomo­cą gene­ra­to­ra sygna­łu cza­su i pro­gra­ma­to­ra. Programator ma inter­fejs użyt­kow­ni­ka (GUI), zapro­gra­mo­wa­ny wysy­ła do Syreny sygna­ły Start i Stop zgod­nie z usta­wio­nym (zapro­gra­mo­wa­nym) cza­sem (har­mo­no­gra­mem).

Generator sygna­łu cza­su ma wyśru­bo­wa­ne wyma­ga­nia, więc jego wyko­na­nie będzie raczej kosztowne.

Wersja dru­ga

Jak widać pro­gra­mo­wa­nia dużo, koszt cało­ści poten­cjal­nie wyso­ki, więc kom­bi­nu­je­my dalej. Czy aby na pew­no wszyst­ko trze­ba robić same­mu? Pierwsza rzecz po wstęp­nym pro­jek­cie to upew­nie­nie się, czy nie ma cze­goś goto­we­go na ryn­ku. Jak nie trud­no (chy­ba) się domy­śleć, zegar­ków na ryn­ku dosta­tek, więc chy­ba nie trze­ba go na nowo odkry­wać. Mamy coś takie­go jak COTS ([[Commercial off the shelf]]) czy­li ogól­nie dostęp­ne na ryn­ku kom­po­nen­ty lub usłu­gi. No to zmia­na projektu:

Zegarek mam goto­wy, kupu­je­my Zegar lub, tu, uży­je­my wzor­co­we­go sygna­łu cza­su, np. takie­go jakie­go uży­wa typo­wa domo­wa pogo­dyn­ka z radio­wo ste­ro­wa­nym zega­rem (to dar­mo­wa usłu­ga). Teraz nasz dia­gram UC wyglą­da tak:

Tu akto­rem abso­lut­nie nie jest Czas, akto­rem jest inny sys­tem, tu źró­dło sygna­łu cza­su. Diagram UC jest zgod­ny ze stan­dar­dem a my zro­zu­mie­li­śmy isto­tę rze­czy”. Stosowanie w ana­li­zie stan­dar­dów pro­wa­dzi do rozu­mie­nia i ma taką wła­śnie zale­tę: ana­li­za i mode­lo­wa­nie pro­wa­dzi do zro­zu­mie­nia pro­ble­mu, łama­nie zasad nota­cji ukry­wa nie­zro­zu­mie­nie pro­ble­mu (o co cho­dzi z tym ocze­ki­wa­nym przez klien­ta czasem).

Wprowadziłem dwa ste­reo­ty­py: czło­wieksys­tem, cel chy­ba jest oczy­wi­sty (czło­wiek ma ekra­ny GUI, sys­tem jakiś inter­fejs” wymia­ny danych).

Rolą ana­li­ty­ka biz­ne­so­we­go jest zro­zu­mie­nie celu zama­wia­ją­ce­go ale też opra­co­wa­nie naj­ko­rzyst­niej­sze­go roz­wią­za­nia. Nie jest to wyrę­cza­nie pro­gra­mi­stów, a ana­li­za i pro­jek­to­wa­nie. Programiści (dostaw­ca opro­gra­mo­wa­nia) imple­men­tu­ją, roz­wią­zu­ją pro­ble­my techniczne.

Tak więc jedy­nym tak na praw­dę ele­men­tem (kom­po­nen­tem) wyma­ga­ją­cym szcze­gó­ło­we­go opra­co­wa­nia i imple­men­ta­cji jest Programator, war­to było pochy­lić się nad ana­li­zą i pro­jek­to­wa­niem, testy pomy­słu wyko­nać na mode­lach… bo taniej.

Pokazałem przy oka­zji tak zwa­ne zstę­pu­ją­ce podej­ście do ana­li­zy i pro­jek­to­wa­nia: od ogó­łu do szcze­gó­łu. Zanim zacznie­my pro­jek­to­wać model dzie­dzi­ny sys­te­mu war­to ogra­ni­czyć zakres pro­jek­tu do nie­zbęd­ne­go mini­mum (naro­bić to się każ­dy potra­fi .)). W sty­lu opar­tym na [[Domain Driven Design]] (DDD) nazy­wa się „[[core doma­in]]” i „[[boun­ded con­text]]” (o DDD innym razem).

Zapytany zosta­łem tak­że o testy akcen­ta­cyj­ne. Proste: nasta­wiam jakąś godzi­nę i czas wycia” i cze­kam :), żeby dłu­go nie cze­kać nasta­wiam taką by cze­kać kil­ka minut a nie godzin … upły­wu cza­su się nie testu­je (ten pły­nie i bez nas) , testu­je­my pro­gra­ma­tor… Owszem moż­na się umó­wić, że testu­je­my sygna­ły Start Stop inter­fej­su a nie syre­nę (będzie ciszej).

Podsumowanie

Jak widać trosz­kę się, mam nadzie­ję, upo­rząd­ko­wa­ło i mamy nastę­pu­ją­ce wnioski:

  1. czas nie jest żad­nym akto­rem, akto­rem jest bene­fi­cjent sys­te­mu, ktoś kto z nie­go korzy­sta lub z nim współ­pra­cu­je, para­me­try takie jak godzi­na alar­mu i czas jego trwa­nia, to nie aktor czas, a treść danych wpro­wa­dza­nych do sys­te­mu (np. for­mu­larz kon­fi­gu­ra­cji alarmu),
  2. opra­co­wa­nie samej spe­cy­fi­ka­cji wyma­gań funk­cjo­nal­nych abso­lut­nie nie deter­mi­nu­je pro­jek­tu, czy­li tego co nam pro­gra­mi­ści dostar­czą (a może to być kosz­tow­ne lub nie, ale to wyni­ka z pro­jek­tu a nie dia­gra­mu UC),
  3. jedy­nym spo­so­bem dokład­ne­go posta­wie­nia zada­nia pro­gra­mi­stom (deve­lo­pe­ro­wi) jest opra­co­wa­nie pro­jek­tu tego co ma powstać (jego logi­ki), jest to już nie spe­cy­fi­ka­cja wyma­gań funk­cjo­nal­nych a spe­cy­fi­ka­cja sys­te­mu (albo jak kto woli, wyma­ga­nie jest projektem),
  4. nie licz­cie na to, że dostaw­ca zawsze zro­bi wszyst­ko by to kosz­to­wa­ło jak naj­mniej… (patrz dru­ga wer­sja pro­jek­tu, jest tań­szy w wyko­na­niu – ryzyko),
  5. jeże­li ktoś umiesz­cza na dia­gra­mie UC akto­ra Czas, to naj­praw­do­po­dob­niej nie rozu­mie imple­men­ta­cji albo ukry­wa ją, lub odkła­da imple­men­ta­cję, to zna­czy, że odsu­wa jed­ną z naj­waż­niej­szych decy­zji pro­jek­to­wych (kosz­ty!) na później,
  6. zale­tą takie­go pro­jek­to­wa­nia (obiek­to­we ukie­run­ko­wa­ne na kom­po­nen­ty) jest moż­li­wość szyb­kie­go osią­ga­nia celu rela­tyw­nie niskim kosz­tem, w tym pro­jek­cie tak na praw­dę do napi­sa­nia jest sam pro­gra­ma­tor, resz­tę jako COTS kupu­je­my: goto­wą syre­nę, sygnał cza­su wyko­rzy­stu­je­my cudzy” (w tym przy­pad­ku to przy oka­zji kla­sycz­ny clo­ud computing).

Tak więc war­to na eta­pie ana­li­zy biz­ne­so­wej wyko­nać nie ste­no­gram z życzeń zama­wia­ją­ce­go (potra­fi sobie nawet sam zro­bić krzyw­dę) i nagi­nać zasa­dy (czas to nie aktor!), ale wyko­nać pro­jekt logi­ki sys­te­mu by zro­zu­mieć pro­blem do roz­wią­za­nia i spraw­dzić jak go roz­wią­zać naj­efek­tyw­niej. Wybór wyko­naw­cy powi­nien być ostat­nim krokiem.

Poniżej ana­li­za (dia­gram poka­zu­ją­cy powyż­sze niu­an­se ana­li­zy i mode­lo­wa­nia czy­li zro­zu­mie­nia co tak na praw­dę jest isto­ta problemu):

Wyobraźmy się, że wie­lu poten­cjal­nych deve­lo­pe­rów dosta­ło wyma­ga­nie: dostar­czyć pro­gra­mo­wa­na syre­nę (lub pierw­szy dia­gram UC) jako zapy­ta­nie ofer­to­we, jaki będzie roz­rzut ofert?

Do zama­wia­ją­cych opro­gra­mo­wa­nie: oddzie­laj­cie ana­li­zę i pro­jek­to­wa­nie od wyko­na­nia :), to ma same zale­ty. Zastanów się teraz Czytelniku, jakie roz­wią­za­nie zapro­po­nu­je więk­szość firm programistycznych…

Na koniec pyta­nie z gatun­ku iro­nii: jak na tym tle wyglą­da­ją zwin­ne meto­dy­ki wytwa­rza­nia oprogramowania?

P.S.

Polecam dia­gram przy­pad­ków uży­cia z innej stro­ny: Udziałowcy pro­jek­tu czy­li któ­ry dia­gram UML …,

oraz ten sam pro­blem, opi­sa­ny z innej per­spek­ty­wy na stro­nach IBM.

Cloud Computing to architektura systemu

Wczoraj mia­ła miej­sce, zapo­wia­da­na na blo­gu, kon­fe­ren­cja na temat Cloud Computing (CC). Nie będę tu powta­rzał całe­go refe­ra­tu, więc zyska­li Ci któ­rzy byli na kon­fe­ren­cji :). Tu napi­sze kil­ka słów o CC w kon­tek­ście tego co było głów­nym prze­sła­niem moje­go referatu:

Cloud Computing to prak­ty­ka reali­za­cji kom­po­nen­to­wej archi­tek­tu­ry sys­te­mu a nie kolej­na odsło­na dzier­ża­wy oprogramowania

O CC czę­sto mówi się jako o cudzych apli­ka­cjach dostęp­nych w sie­ci. Mówi się o Saleforce, Zoho i innych podob­nych, ale to są sys­te­my dostęp­ne zdal­nie i licen­cjo­no­wa­ne (nie ma tu zna­cze­nia to, czy licen­cje są płat­ne czy nie). To jest sta­re i zna­ne [[ASP]] czy [[SaaS]].

Od lat mówi się o SOA, jako o meto­dzie budo­wy i inte­gra­cji sys­te­mów (tu już mamy inte­gra­cję a nie tyl­ko zdal­ne uży­cie). Jednak poja­wia się tu potrze­ba two­rze­nia pośred­ni­czą­ce­go, kosz­tow­ne­go, ele­men­tu archi­tek­tu­ry ([[ESB]]) co sku­tecz­nie ogra­ni­czy­ło zasto­so­wa­nie tej meto­dy (a raczej tech­no­lo­gii) inte­gra­cji sys­te­mów. Czytaj dalej… Cloud Computing to archi­tek­tu­ra sys­te­mu”

IBM CIO Study: 60% w chmurze za 5 lat

Z bada­nia prze­pro­wa­dzo­ne­go przez IBM na gru­pie ponad 3000 dyrek­to­rów dzia­łów IT wyni­ka, że w cią­gu naj­bliż­szych pię­ciu lat, 60% orga­ni­za­cji zamie­rza wpro­wa­dzić roz­wią­za­nia opar­tych na chmu­rze. W opi­nii respon­den­tów dopro­wa­dzi to do dal­sze­go roz­wo­ju ich firm i pozwa­li osią­gnąć prze­wa­gę kon­ku­ren­cyj­ną. W sto­sun­ku do bada­nia prze­pro­wa­dzo­ne­go w 2009 roku podwo­iła się licz­ba CIO, któ­rzy chcą wpro­wa­dzić roz­wią­za­nia clo­ud com­pu­ting, co świad­czy o tym, że spraw­dza­ją się one w wie­lu fir­mach na całym świe­cie. (źr. Chmura wg bada­nia IBM CIO Study).

Prognoza wyda­je się real­na. Odreagowanie kło­po­tli­wych, kosz­tow­nych i mało prze­wi­dy­wal­nych wdro­żeń sys­te­mów ERP, CRM powo­du­je odcho­dze­nie od twar­dej” inte­gra­cji (nie­po­dziel­ne zin­te­gro­wa­ne sys­te­my ERP) na rzecz [[archi­tek­tu­ry sys­te­mów fede­ra­cyj­nych]] takich jak wła­śnie [[Cloud Computing]].

Przyszłościowa architektura aplikacji internetowych
Przyszłościowa archi­tek­tu­ra apli­ka­cji inter­ne­to­wych (Copyrights ? 2006 PJWSTK)

Wygląda na to, że przy­szłość to opi­sa­na powy­żej archi­tek­tu­ra fede­ra­cji quasi­nie­za­leż­nych sys­te­mów świad­czą­cych usłu­gi. Zależność mię­dzy nimi będzie pole­ga­ła na stan­da­ry­za­cji słow­ni­ków pojęć dzie­dzi­no­wych (co już się dzieje).

W tej posta­ci np. nazwa: sys­tem ERP czy CRM, tra­ci sens jako mono­li­tycz­ny pakiet a sta­no­wi sobą pakiet usług z jakie­go korzy­sta dane orga­ni­za­cja. dru­go­rzęd­ne zna­cze­nie ma to czy użyt­kow­nik jest ich wła­ści­cie­lem, dzier­żaw­ca czy chwi­lo­wym użyt­kow­ni­kiem. Analiza Biznesowa tu pole­ga na ana­li­zie i stwo­rze­niu mode­lu orga­ni­za­cji, wska­za­niu gdzie jakich usług wspie­ra­ją­cych dzia­ła­nia się w niej ocze­ku­je, wyszu­ka­niu dostaw­ców usług lub ich stwo­rze­niu, integracji.

Osobiście uwa­żam, że koń­czą się cza­sy gdy sprze­daw­cy ata­ku­ją” rynek, wybie­ra­ją sobie klien­tów i sprze­da­ją im opro­gra­mo­wa­nie. Zaczyna się era gdy to klient wybie­ra usłu­gę i jej dostaw­cę. Sprzedaż opro­gra­mo­wa­nia będzie wyglą­da­ła podob­nie jak sprze­daż w pasa­żu buti­ków: dostaw­cy usług wysta­wią swo­je usłu­gi, a klient (pro­jek­tant sys­te­mu) będzie się prze­cha­dzał i wybie­rał naj­le­piej mu pasu­ją­ce. Podobnie jak teraz: budu­jąc dom, remon­tu­jąc miesz­ka­nie zapra­sza­my pro­jek­tan­ta wnętrz, ten zna­jąc ofer­ty mar­ke­tów budow­la­nych dobie­rze naj­lep­sze wypo­sa­że­nie, mate­ria­ły i kolo­ry­sty­kę i kupi. Nadchodzi powo­li koniec ery napa­stli­wych sprze­daw­ców i ich firm, koniec dyk­ta­tu­ry deve­lo­pe­rów. Nadchodzi, powo­li, era ryn­ku usług.