Bardzo czę­sto spo­ty­kam arty­ku­ły o SOA pisa­ne w kon­tek­ście imple­men­ta­cji. Daleki jestem od kry­ty­ki tech­no­lo­gii i tech­no­lo­gicz­nych ofert róż­nych inte­gra­to­rów IT, raczej postrze­gam takie tech­no­lo­gicz­ne ofer­ty jako pró­bę opi­su sys­te­mu za pomo­cą przy­pad­ków uży­cia a wg. mnie przy­pad­ki uży­cia są dopie­ro kon­se­kwen­cją łań­cu­cha pro­ce­sów w fir­mie i decy­zji o zakre­sie pro­jek­tu a nie ?narzu­co­ną lista funkcjonalności?.

Otóż sys­tem (każ­dy) to zespół powią­za­nych i wza­jem­nie oddzia­ły­wu­ją­cych ele­men­tów sta­no­wią­cych pew­ną logicz­ną całość. Paradoksalnie w defi­ni­cji sys­te­mu zna­nej z ogól­nej teo­rii sys­te­mów nie ma mowy o celu sys­te­mu jako takim, ist­nie­je jed­nak dar­wi­now­skie poję­cia prze­trwa­nia (tu np. fir­my na ryn­ku). Takie spoj­rze­nie tłu­ma­czy nie raz wie­le, mie­dzy inny­mi nie­uda­ne wdro­że­nia cze­go­kol­wiek z powo­du dąże­nia sil­nych jed­no­stek do zacho­wa­nia swo­je­go sta­tus quo a nie do ?chwa­ły i zysków pracodawcy?.

Ale gdzie tu SOA? Po kolei.
Organizacja, każ­da, ma jasno okre­ślo­ny cel, ten wyma­ga zaso­bów a te wyma­ga­ją ich dostar­cze­nia i zarzą­dza­nia nimi. To naj­prost­szy moim zda­niem i naj­lep­szy meta­mo­del orga­ni­za­cji a opro­gra­mo­wa­nie to jeden z takich zaso­bów. Tak więc w więk­szo­ści przy­pad­ków fir­my, nie­za­leż­nie co jest ich głów­nym przed­mio­tem dzia­łal­no­ści, wyma­ga­ją: pra­cow­ni­ków, finan­so­wa­nia, sprzą­ta­nia i wie­lu pew­nie innych, rów­nie war­to­ścio­wych i potrzeb­nych dzia­łań. Rzecz w tym, że np. fir­my cel ryn­ko­wy mają jeden, każ­da nie­mal­że inny a zapew­nia­nie zaso­bów i zarzą­dza­nie nimi nie raz sta­no­wi tajem­ni­ce han­dlo­wą itp. (mode­li biz­ne­so­wych jest chy­ba tyle ile firm a to mode­le biz­ne­so­we two­rzą war­tość na ryn­ku i prze­wa­gę nad kon­ku­ren­cją) nie ist­nie­je więc, mio­im zda­niem, jeden model ?dobre­go i spraw­dzo­ne­go sys­te­mu? (choć dostaw­cy sys­te­mów ERPII są inne­go zdania).

Problem więc, jaki ma do roz­wią­za­nia wie­le firm, to dopa­so­wa­nie do swo­ich potrzeb, innych niż maja wszyst­kie inne fir­my w tym kon­ku­ren­ci, narzę­dzi poma­ga­ją­cych w zarzą­dza­niu takim sys­te­mem. I tu poja­wia się wyż­szość SOA jako meto­dy budo­wy sys­te­mu infor­ma­tycz­ne­go nad sys­te­ma­mi ERP, któ­re są jed­nak dość sztyw­ny­mi kon­struk­cja­mi opar­ty­mi na jakiś wybra­nym, ale jed­nym, mode­lu funk­cjo­no­wa­nia. Konfigurowalność tych sys­te­mów jest dale­ka od ideału.

Podstawową więc wyż­szo­ścią, dają­cą prze­wa­gę na ryn­ku, jest zwin­ność orga­ni­za­cji mają­cej luź­no powią­za­ne ele­men­ty (zaso­by, w tym infor­ma­tycz­ne) współ­pra­cu­ją­ce ze sobą na bazie ?kon­trak­tów?. 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.. W tym kon­tek­ście moż­li­we jest osza­co­wa­nie zwro­tu z inwe­sty­cji w SOA jako wdro­że­nie spo­so­bu reali­za­cji stra­te­gii infor­ma­ty­za­cji fir­my. SOA jako pro­jekt tech­no­lo­gicz­ny bez pod­bu­do­wy zarząd­czej moim zda­niem nie ma żad­ne­go sen­su gdyż to stra­te­gia zarzą­dza­nia jest w sta­nie poka­zać jakim kosz­tem jest sens tą stra­te­gie wdra­żać. Pytanie o zwrot z inwe­sty­cji w SOA bez tej wie­dzy moim zda­niem pozo­sta­nie bez odpo­wie­dzi z powo­du bra­ku danych.

Co więc robić?
Skoro mamy meta­mo­del ?Organizacja, każ­da, ma jasno okre­ślo­ny cel, ten wyma­ga zaso­bów a te wyma­ga­ją ich dostar­cze­nia i zarzą­dza­nia nimi.? To war­to sobie powie­dzieć, że wła­ści­wa (naj­sku­tecz­niej­sza) kolej­ność to taka:
1. Opisać stra­te­gie ryn­ko­wą fir­my
2. Przeanalizować i opi­sać model biz­ne­so­wy (spo­sób powsta­wa­nia i źró­dło głów­nych docho­dów)
3. Uszczegółowić model biz­ne­so­wy do opi­su pro­ce­sów klu­czo­wych biz­ne­so­wych
4. wska­zać (zde­fi­nio­wać) zaso­by, tak­że infor­ma­cyj­ne, dla tych pro­ce­sów
5. wska­zać pro­ce­sy, któ­rych wspar­cie meto­da­mi infor­ma­tycz­ny­mi przy­nie­sie mie­rzal­ne korzy­ści
6. zapro­jek­to­wać (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łu­gi
7. opra­co­wać stra­te­gię zapew­nie­nia tych zaso­bów
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órki.