Visual Paradigm v.17

Właśnie skoń­czył się mi insta­lo­wać upgra­de Visual Paradigm v.17. To narzę­dzie towa­rzy­szy mi od 2005 roku, ale po kolei. 

W zasa­dzie od począt­ku swo­jej karie­ry w bran­ży IT mode­le two­rzy­łem wyłącz­nie z uży­ciem sfor­ma­li­zo­wa­nych nota­cji. Kluczowym powo­dem zawsze były: kon­tro­lo­wal­na popraw­ność i logi­ka tych mode­li oraz stan­da­ry­za­cja. To trosz­kę jak z mate­ma­ty­ką: wie­my, że dwa i dwa to zawsze czte­ry a do zako­mu­ni­ko­wa­nia tego innym uży­wa­my stan­dar­do­wej for­my zapi­su: 2+2=4. W zasa­dzie z mate­ma­ty­ką nie mamy pro­ble­mu, pro­ble­mem są sche­ma­ty blo­ko­we: wie­lu ludzi uwa­ża, że to tyl­ko obraz­ki, któ­re moż­na sobie ryso­wać po swo­je­mu a ikon­ki nota­cji to tyl­ko biblio­te­ka faj­nych sym­bo­li. Niestety nic bar­dziej myl­ne­go: sfor­ma­li­zo­wa­na nota­cja to język z jego regu­ła­mi i mają­cy­mi okre­ślo­ne zna­cze­nie zna­ka­mi. Nie będę tu tego wąt­ku kon­ty­nu­ował, na moim blo­gu jest wie­le arty­ku­łów na ten temat, dzi­siaj o narzędziach.

Moja przy­go­da z mode­la­mi zaczę­ła w latach 90-tych gdy jako ana­li­tyk pro­jek­tant musia­łem zacząć porząd­nie doku­men­to­wać wyni­ki ana­liz i pro­jek­to­wa­ne sys­te­my. Bardzo szyb­ko sie nauczy­łem, że wszel­kie zanie­dba­nia z mojej stro­ny, szcze­gól­nie brak pre­cy­zji w opi­sy­wa­niu firm klien­tów czy pro­jek­to­wa­nych roz­wią­zań, to po pro­stu brak sza­cun­ku dla cza­su moich kole­ża­nek i kole­gów z dzia­łu developmentu. 

Pierwsze mode­le jakie robi­łem to były mode­le pro­ce­sów i prze­pły­wy danych robio­ne z uży­ciem nota­cji DFD (nadal zda­rza się, że jej uży­wam) oraz IDEF0. W dru­giej poło­wie lat 90-tych poja­wia się nota­cja UML, któ­ra w moich pro­jek­tach (sys­te­my kom­po­nen­to­we zorien­to­wa­ne obiek­to­wo) zaczę­ła zaj­mo­wać miej­sce DFD. Podstawowym narzę­dziem począt­ko­wo był Staffware (obec­nie TIBCO), ale z uwa­gi na jego cięż­kość” i kosz­ty, prze­nio­słem sie na Visio Sampler” (po prze­ję­ciu przez Microsoft obec­nie MS Visio). 

I tak to trwa­ło do 2005 roku, gdy w dużym pro­jek­cie dla Echo Investment SA, oka­za­ło, że pra­co­chłon­ność zwią­za­na z aktu­ali­za­cją mode­li i całę­go rapor­tu z ana­li­zy, czy­li doku­men­tu Analiza Biznesowa i Projekt Systemu, z uży­ciem MS Visio, sta­je się ogrom­nych poże­ra­czem cza­su, a ja mam kon­trakt fixed-pri­ce”. Tak więc pew­ne­go razu, w hote­lu Łysogóry” w Kielcach, po pół­no­cy, z wizją nie­do­trzy­ma­nia ter­mi­nów, usia­dłem do kom­pu­te­ra i zaczą­łem szu­kać w Internecie zba­wie­nia”, porów­na­nie kil­ku pro­duk­tów zaowo­co­wa­ło wybo­rem Visual Paradigm. Głównym kon­ku­ren­tem wte­dy był EA SPARX, jed­nak fakt, że goły EA bez plu­gi­nów nie nada­je się do zbyt wie­lu rze­czy, ma nie­zgod­no­ści ze spe­cy­fi­ka­cja­mi BPMN i UML (export XMI, nie pozwa­la na wie­lo­krot­ne umiesz­cza­nie tych samych ele­men­tów na jed­nym dia­gra­mie itp.), sama insta­la­cja i kon­fi­gu­ra­cja wer­sji demo zaj­mo­wa­ła ponad godzi­nę, brak (wte­dy) moż­li­wo­ści natych­mia­sto­wej akty­wa­cji po opła­cie kar­tą kre­dy­to­wą (następ­ne­go dnia rano musia­łem coś poka­zać i nie mogła to być wer­sja ewa­lu­acyj­na i jej zna­ki wod­ne), spo­wo­do­wa­ły, że na pla­cu boju został VP, któ­re­go insta­la­cja i akty­wa­cja zaj­mu­je kil­ka minut, po któ­rych nada­je się natych­miast do pracy.

Okazało się, że pra­ca z VP nie wyma­ga nicze­go poza zna­jo­mo­ścią spe­cy­fi­ka­cji nota­cji: jak coś jest w spe­cy­fi­ka­cji to jest tak­że w VP. Do tego suport VP dzia­ła natych­miast (odpi­su­ją na maile, w skraj­nym przy­pad­ku wcho­dzą” zdal­nie na kom­pu­ter). Z EA mie­wa­łem kil­ka przy­gód jako pod­wy­ko­naw­ca w pro­jek­tach, i za każ­dym razem wnio­sek był ten sam: nie rezy­gnu­ję z VP.

Jak się z tym narzę­dziem pra­cu­je? Swego cza­su na żywo pokazywałem: 

Obecnie mamy wer­sje 17. Kolejna doj­rzal­sza wer­sja, bogat­sza o kil­ka nowi­nek w sto­sun­ku do poprzed­niej 16.3.: https://​www​.visu​al​-para​digm​.com/​w​h​a​t​s​-​n​ew/

Kluczowe moim zda­niem cechy tego narzę­dzia to:

  1. prak­tycz­nie peł­na zgod­ność wspie­ra­nych nota­cji z ich spe­cy­fi­ka­cja­mi na OMG​.org,
  2. potęż­ny gene­ra­tor rapor­tów (nie uży­wam do tego celu MS Office od 2007 roku), pra­co­chłon­ność opra­co­wy­wa­nia i aktu­ali­za­cji doku­men­tów wyni­ko­wych (PDF/docx) spa­dła nie­mal­że do zera,
  3. ser­wer pra­cy gru­po­wej (Teamwork Server) w chmu­rze to:
    1. peł­ne wer­sjo­no­wa­nie (iden­tycz­nie jak wer­sjo­no­wa­nie kodu na ser­we­rach Subversion i podob­nych), moż­li­wość budo­wa­nia gałę­zi pro­jek­tu, powro­tu do dowol­nej wcze­śniej­szej revi­zji”, itp. 
    2. pra­ca gru­po­wa na hie­rar­chicz­nym repo­zy­to­rium (nie jest to baza SQL, pra­ca off-line gwa­ran­tu­je peł­ne bezpieczeństwo),
    3. kon­tro­lo­wa­ny dostęp do wglą­du (rola recen­zen­ta doku­men­ta­cji) oby­wa się bez dodat­ko­wych opłat (moduł Postmania),
    4. syn­chro­ni­za­cja sko­ja­rzo­ne­go z pro­jek­tem fide­ru pli­ków (wszel­kie załącz­ni­ki, np. doku­men­ty źródłowe),
  4. moż­li­wość two­rze­nia dia­gra­mów on-line.

To tyl­ko wybra­ne cechy, w obec­nej wer­sji 17. mię­dzy inny­mi doda­no nowe funk­cjo­nal­no­ści do gene­ra­to­ra doku­men­ta­cji i ele­men­tów zarza­dza­nia pro­jek­tem. Tak! VP ma potęż­ne narzę­dzie do zarzą­dza­nia pro­jek­tem na eta­pie nad­zo­ru nad imple­men­ta­cję: nie­za­leż­ne wer­sjo­no­wa­nie wszyst­kich ele­men­tów mode­li i gene­ro­wa­nie rapor­tów róż­nic mię­dzy com­mi­ta­mi”. Dokumentowanie przy­pad­ków uży­cia zgod­ne z Use Case 2.0, zgod­ność ze SCRUM i wspar­cie dla zwin­nych metod pra­cy (pra­ca z user sto­ry, kan­ban, i wie­le innych). 

Od same­go począt­ku VP to tak­że wspar­cie dla naj­waż­niej­szych obiek­to­wych wzor­ców pro­jek­to­wych (Rebeka Wirfbrock i jej książ­ka Wirfs-Brock, R., & McKean, A. (2009). Object design: Roles, respon­si­bi­li­ties, and col­la­bo­ra­tions. Addison-Wesley) i mode­lo­wa­nia struk­tur XML, SOA, RESTfull API, itp. 

I na koniec mój dru­gi wewnętrz­ny idol” to cała sek­cja UX Design and Wireframe Tools czy­li two­rze­nie makiet ekra­nów Low Fidelity oraz High Fidelity, a tak­że map i ani­mo­wa­nych mode­li ich prze­pły­wu. Więcej tu: Makiety.

Tak więc mając Visual Paradigm, nicze­go wię­cej nie potrze­bu­ję i z przy­jem­no­ścią powi­ta­łem na moim kom­pu­te­rze wer­sję 17.0 do cze­go zachę­cam innych użyt­kow­ni­ków VP. Pozostałych zaś infor­mu­ję, że jest takie narzędzie ;). 

wielka ryba kto kogo zjadł wędkarz łowi złowiony

Strategia, model biznesowy, architektura korporacyjna ? jak to powiązać?

Na blo­gu moje­go kole­gi poja­wił się bar­dzo inspi­ru­ją­cy wpis, zakoń­czo­ny prowokacją :):

Oczywiście ? jest to moja pro­po­zy­cja podej­ścia do tema­tu. Będę wdzięcz­ny za Państwa opi­nie. (Strategia, model biz­ne­so­wy, archi­tek­tu­ra kor­po­ra­cyj­na ? jak to powią­zać? | Architektura Korporacyjna).

Charakter mam taki, że na nie­któ­re pro­wo­ka­cje odpo­wia­dam :). Odpowiadam na swo­im blo­gu, a nie bez­po­śred­nio kole­dze na stro­nie jego blo­ga, gdyż zbyt duży tekst mi się zro­bił” :).

W pro­jek­tach patrzę na poję­cia omó­wio­ne w arty­ku­le chy­ba nie­co (ale nie wie­le) ina­czej. Najpierw, zamiast cyta­tów z lite­ra­tu­ry, defi­ni­cje słownikowe:

wizja: czy­jeś wyobra­że­nie jakichś zda­rzeń mają­cych zajść w przy­szło­ści, zwy­kle przed­sta­wia­ne w książ­ce lub w filmie,

misja: posłan­nic­two, waż­ne odpo­wie­dzial­ne zada­nie do spełnienia

stra­te­gia: prze­my­śla­ny plan dzia­łań w jakiejś dziedzinie,

tak­ty­ka: spo­sób postę­po­wa­nia mają­cy dopro­wa­dzić do osią­gnię­cia celu,

Z per­spek­ty­wy defi­ni­cji przy­ta­cza­nych w wyżej cyto­wa­nym arty­ku­le, nie widzę tu koli­zji. Nadając kon­tekst biz­ne­so­wy tym poję­ciom, wizja to wyobra­że­nie pew­nej hipo­te­tycz­nej posta­ci świa­ta (np. ryn­ku). Misja to nasze zada­nie”, to cze­go się podej­mu­je­my by tę Wizję urze­czy­wist­nić. Strategia biz­ne­so­wa to nic inne­go jak plan dzia­łań, przy­ję­ty jako spo­sób reali­za­cji wizji. Taktyka to spo­sób reali­za­cji tego pla­nu czy­li imple­men­ta­cja strategii.

Gdybym miał w ten spo­sób opi­sać swo­ją dzia­łal­ność to napi­sał bym:

Moja wizją są pro­jek­ty, reali­zo­wa­ne w spo­sób spro­wa­dza­ją­cy ich ryzy­ko do zera. Misją moją jest zdo­by­wa­nie i krze­wie­nie wie­dzy pozwa­la­ją­cej reali­zo­wać pro­jek­ty ide­al­ne. Strategia jaka przy­ją­łem, to samo­dziel­ne stu­dia, wyko­ny­wa­nie zawo­du ana­li­ty­ka i dzie­le­nie się zdo­by­tą wie­dzą. Taktyka dzie­le­nia się wie­dzą to pro­wa­dze­nie szko­leń, wygła­sza­nie refe­ra­tów na kon­fe­ren­cjach i pro­wa­dze­nie bloga.

Ponad sześc lat temu pisa­łem o mode­lu biznesowym:

Poprawnie wyko­na­ny model biz­ne­so­wy opi­su­je i defi­niu­je zarazem:

- źró­dła zaopatrzenia

- kana­ły zbytu

- wpływ konkurencji

- głów­ne źró­dło mar­ży (zysku)

- źró­dła zagrożeń

(uza­sad­nie­nie powyż­sze­go w Model biz­ne­so­wy…).

Wygląda więc na to, że model biz­ne­so­wy to w zasa­dzie tak­ty­ka reali­za­cji (jakiejś usta­lo­nej ) stra­te­gii (ryn­ko­wej).

Połączenie pojęć: misja, wizja, stra­te­gia, tak­ty­ka oraz archi­tek­tu­ra kor­po­ra­cyj­na, jak je wyko­nać? W arty­ku­le Nowa spe­cy­fi­ka­cja Business Motivation Model 1.2 znaj­dzie­my taki oto diagram:

BMMOvierwiev

Przedstawia on mię­dzy inny­mi powyż­sze poję­cia i ich wza­jem­ne powią­za­nia. Jak widać, są to poję­cia zgod­ne z przy­ta­cza­ny­mi defi­ni­cja­mi (pole­cam lek­tu­rę spe­cy­fi­ka­cji mode­lu poję­cio­we­go i nota­cji BMM). Wizja to stan koń­co­wy, misja jest ele­men­tem zbio­ru środ­ków słu­żą­cych do osią­ga­nia wizji”. Mamy tu: misję oraz powią­za­ną z nią stra­te­gię i tak­ty­kę (jako imple­men­ta­cję strategii).

Gdzie tu Architektura Korporacyjna? Andrzej Sobczak (autor cyto­wa­ne­go arty­ku­łu) przy­ta­cza taką definicję:

archi­tek­tu­ra kor­po­ra­cyj­na (w jed­nym z jej ujęć) to for­mal­ny opis struk­tu­ry i funk­cji kom­po­nen­tów kor­po­ra­cji, 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. Przy czym kom­po­nent kor­po­ra­cji defi­nio­wa­ny jest jako dowol­ny ele­ment kor­po­ra­cji, któ­ry słu­ży do jej kon­stru­owa­nia; mogą to być ludzie, pro­ce­sy, fizycz­ne struk­tu­ry jak rów­nież sys­te­my infor­ma­tycz­ne. (Strategia, model biz­ne­so­wy, archi­tek­tu­ra kor­po­ra­cyj­na ? jak to powią­zać? | Architektura Korporacyjna).

I teraz war­to zwró­cić uwa­gę na to, że for­mal­ny opis struk­tu­ry i funk­cji kom­po­nen­tów kor­po­ra­cji, wza­jem­nych powią­zań pomię­dzy tymi kom­po­nen­ta­mi” to struk­tu­ra orga­ni­za­cyj­na. Dalej mamy opis pryn­cy­piów i wytycz­nych zarzą­dza­ją­cych ich two­rze­niem i roz­wo­jem w cza­sie” czy­li wizje, misję, stra­te­gię oraz tak­ty­kę fir­my, decy­zje jej Zarządu. Patrząc na stwier­dze­nie, że kom­po­nent kor­po­ra­cji defi­nio­wa­ny jest jako dowol­ny ele­ment kor­po­ra­cji, któ­ry słu­ży do jej kon­stru­owa­nia; mogą to być ludzie, pro­ce­sy, fizycz­ne struk­tu­ry jak rów­nież sys­te­my infor­ma­tycz­ne” nale­ży uznać, że struk­tu­rę orga­ni­za­cyj­ną nale­ży uzu­peł­nić wie­dzą o narzę­dziach jakie Ci ludzie dosta­ją by poma­ga­ły im reali­zo­wać ich zada­nia, czy­li mię­dzy inny­mi sys­te­my infor­ma­tycz­ne (tak, one są jedy­nie narzędziami).

Pozostał nam fakt, że to powi­nien być for­mal­ny opis”. Zaglądamy do Encyklopedii PWN i czytamy:

język for­mal­ny: (inform.) język zło­żo­ny ze wszyst­kich słów (wyra­żeń) uzy­ski­wa­nych za pomo­cą ści­śle okre­ślo­nych reguł;

Czyli potrzeb­na jest nota­cja (sys­tem poję­cio­wy: prze­strzeń nazw). Jak widać mamy do dys­po­zy­cji BMM, któ­ry pasu­je” do oma­wia­ne­go pro­ble­mu. Uzupełniona sys­te­ma­mi poję­cio­wy­mi dzie­dzi­no­wy­mi” czy­li BPMN (pro­ce­sy biz­ne­so­we powią­za­ne z zaso­ba­mi) oraz UML (struk­tu­ry i sys­te­my) mam kom­plet­ny i spój­ny poję­cio­wo (dba o to orga­ni­za­cja OMG) zestaw narzę­dzi sta­no­wią­cy w moich oczach odpo­wiedź na tytu­ło­we pytanie.

I teraz moja kon­klu­zja: bazu­jąc na brzy­twie Ockhama” pod­ją­łem pró­bę spraw­dze­nia czy przy­pad­kiem odpo­wiedź na tytu­ło­we pyta­nie sfor­mu­ło­wa­ne przez Andrzeja, już nie ist­nie­je… Odnoszę wra­że­nie, że wła­śnie pra­ce OMG, ich wynik, są chy­ba odpo­wie­dzią na to pyta­nie. Faktem jest, że nie wprost, ale chy­ba ana­li­zu­jąc te sys­te­my poję­cio­we, archi­tek­tu­rę kor­po­ra­cyj­na oraz BMM, moż­na uznać, że tytu­ło­we powią­za­nie ist­nie­je. Opisałem to z nie­co innej stro­ny w arty­ku­le Architektura Korporacyjna z OMG.

złożoność złożony system skomplikowany http://hikingartist.files.wordpress.com/

Nowy paradygmat systemowy

Na stro­nach www​.moder​na​na​lyst​.com poja­wił się kolej­ny cie­ka­wy arty­kuł, klu­czo­we tezy to:

The two major are­as for chan­ge dri­ving the new IS shift are the desi­re or need to:

(1) mana­ge busi­ness pro­cess and busi­ness rules as sepa­ra­te but clo­se­ly rela­ted and con­nec­ted reso­ur­ces and

(2) decom­po­se softwa­re or pro­gram­ming code into reu­sa­ble modu­les, cal­led servi­ces, mana­ged by a servi­ce orien­ted archi­tec­tu­re (SOA) infra­struc­tu­re. The SOA infra­struc­tu­re mana­ges and media­tes servi­ces used in a busi­ness process.

(A New Information Systems Paradigm: What does a Business Analyst Needs to Know?).

To kolej­ne źró­dło, któ­re publi­ku­je prze­po­wied­nię” mówią­cą, że klu­czo­wy wpływ na roz­wój i pro­jek­to­wa­nie sys­te­mów infor­ma­tycz­nych będą mia­ły dwie klu­czo­we kom­pe­ten­cje i ana­li­ty­ków i pro­jek­tan­tów: zarzą­dza­nie pro­ce­sa­mi biz­ne­so­wy­mi i regu­ła­mi biz­ne­so­wy­mi jako odręb­ny­mi, powią­za­ny­mi obsza­ra­mi, opi­su­ją­cy­mi orga­ni­za­cje oraz umie­jęt­ność dekom­po­zy­cji opro­gra­mo­wa­nia na samo­dziel­ne odręb­ne modu­ły-usłu­gi, któ­rych moż­na nie­za­leż­nie uży­wać np. w archi­tek­tu­rze SOA. Architektura SOA daje moż­li­wość nie­za­leż­ne­go przy­po­rząd­ko­wa­nia potrzeb­nych usług do kon­kret­nych pro­ce­sów biznesowych.

W 2007 roku pisa­łem, że prze­wi­du­ję 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. Technologia obiek­to­wa bar­dzo ten pro­ces uła­twi­ła. 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. (Czy to już nad­cho­dzą­cy koniec zin­te­gro­wa­nych ERP?).

W roku 2011, rok temu moż­na było zauwa­żyć, że 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, nawę 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 kom­po­nen­ty? (Biznes wycho­dzi z objęć sys­te­mu ? mono­li­tycz­ne­go ERP).

W ubie­głym roku na kon­fe­ren­cji SOA Executive Forum mia­łem refe­rat Jak rozu­mia­ne SOA odej­dzie do lamu­sa? Co nastą­pi po SOA?. Poruszyłem kil­ka spraw:

  1. SOA jako Service Oriented Architectute, czym było jako technologia?
  2. SOA jako Service Oriented Analysis a cóż to takiego?
  3. SOA jako nowo­cze­sna archi­tek­tu­ra sys­te­mów wspo­ma­ga­ją­cych zarządzanie
  4. Nowe cza­sy: archi­tek­tu­ra opar­ta na kom­po­nen­tach ryn­ko­wych czy­li SaaS, Clod Computing i inne

Duże zain­te­re­so­wa­nie wzbu­dzi­ło wte­dy roz­wi­nię­cie skró­tu: [[Service Oriented Analysis]]. Otóż ana­li­za pro­ce­sów biz­ne­so­wych i nastę­pu­ją­ca po niej ana­li­za wyma­gań, a być może dalej obiek­to­we pro­jek­to­wa­nie, pro­wa­dzi wła­śnie do orien­ta­cji na usłu­gi”. Przypadek uży­cia w UML (i jako wyma­ga­nie w obiek­to­wym para­dyg­ma­cie) to nic inne­go jak usłu­ga sys­te­mu. Nic nie stoi na prze­szko­dzie, by je – te usłu­gi – imple­men­to­wać oddziel­nie i nie­za­leż­nie. Otrzymamy wte­dy zna­ne od lat COTS. Powyższy dia­gram jasno poka­zu­je, że sys­tem” wspo­ma­ga­ją­cy zarzą­dza­nie to pakiet usług wspo­ma­ga­ją­cych kon­kret­ne pro­ce­sy biz­ne­so­we i nie koniecz­nie będą­cy jed­nym zin­te­gro­wa­nym pakie­tem opro­gra­mo­wa­nia ERP II.

Podejście takie jest wygod­ne gdyż pozwa­la pro­jek­to­wać i wdra­żać nawet bar­dzo zło­żo­ne sys­te­my meto­dą kolej­nych kro­ków-kom­po­nen­tów, spo­koj­nie moż­na je nazwać eta­pa­mi a całość, zwin­nym pro­jek­tem. Jednak z dru­giej stro­ny ta zwin­ność, to nie może być rzut na taśmę bez ana­li­zy i projektowania”.

Podstawową wyż­szo­ścią, dają­cą prze­wa­gę na ryn­ku, jest zwin­ność orga­ni­za­cji. SOA to nic inne­go jak taka wła­śnie struk­tu­ra sys­te­mu infor­ma­tycz­ne­go: spe­cja­li­zo­wa­ne apli­ka­cje, kom­po­nen­ty, insta­lo­wa­ne (wdra­ża­ne) do reali­za­cji kon­kret­nych potrzeb zaso­bów takich jak pra­cow­ni­cy księ­go­wo­ści, pra­cow­ni­cy sprze­da­ży, pra­cow­ni­cy pro­duk­cyj­ni, itp.. Co więc robić?

  1. Opisać stra­te­gie ryn­ko­wą firmy,
  2. Przeanalizować i opi­sać model biz­ne­so­wy (spo­sób powsta­wa­nia i źró­dło głów­nych dochodów),
  3. Uszczegółowić model biz­ne­so­wy do opi­su pro­ce­sów klu­czo­wych biz­ne­so­wych i reguł biznesowych,
  4. Wskazać pro­ce­sy, któ­rych wspar­cie meto­da­mi infor­ma­tycz­ny­mi przy­nie­sie mie­rzal­ne korzyści,
  5. Zaprojektować (udo­ku­men­to­wać) archi­tek­tu­rą sys­te­mu infor­ma­tycz­ne­go ukie­run­ko­wa­na na zaso­by i usługi.

Jeżeli pogo­dzi­my się z fak­tem, że SOA to usłu­go­wa archi­tek­tu­ra sys­te­mu infor­ma­tycz­ne­go fir­my, zaś wszel­kie webser­wi­sy, szy­ny itp. to tyl­ko moż­li­wa imple­men­ta­cji (ale nie jedy­na!) tej archi­tek­tu­ry to już będzie z gór­ki. (W co inwe­sto­wać w kry­zy­sie c.d. – SOA) 

Tak więc, jak mawia mój zna­jo­my pro­fe­sor filo­zo­fii: gdy dwóch mówi to samo to nie jest to samo. Tu, o SOA, kom­po­nen­tach, ana­li­zie i pro­jek­to­wa­niu zorien­to­wa­nym na usłu­gi mówi wie­lu. Dostawcy sys­te­mów ERP o zwar­tej, zin­te­gro­wa­nej archi­tek­tu­rze będą tu z natu­ry zacho­wy­wa­li bez­wład­ność: SOA powo­du­je, że żaden ERP (sys­tem i jego dostaw­ca) nie będzie miał mono­po­lu u raz pozy­ska­ne­go klienta.