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.

Słowa kluczowe: , , , , , , , , , , , , , , , , , ,

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 11 komentarzy

  1. jacek2v 1 grudnia 2012 Odpowiedz

    Co do zało­żeń to zgo­da, ale prak­ty­ka czę­sto wery­fi­ku­je stwier­dze­nie „… zwin­ność orga­ni­za­cji. SOA to nic inne­go jak taka wła­śnie struk­tu­ra sys­te­mu informatycznego.”
    Obecnie SOA w wymia­rze kon­kret­nych reali­za­cji, to wiel­ka i skom­pli­ko­wa­na ​„biurokratyczno/technologiczna maszy­na” w żaden spo­sób nie nawią­zu­ją­ca do chwa­leb­nej idei zwinności 🙁
    Ale nadal mam nadzie­ję na prze­łom w tym względzie 🙂

    1. Jarek Żeliński 1 grudnia 2012

      hm… trud­no wska­zać gra­ni­ce pomię­dzy biu­ro­kra­cja a tech­no­lo­gią, oso­bi­ście trak­tu­ję SOA jako ​„wzo­rzec archi­tek­to­nicz­ny”, a nie pro­dukt tej czy innej fir­my, nie raz za pie­nią­dze mają­ce się nijak do korzy­ści z posiadania…

  2. jacek2v 2 grudnia 2012 Odpowiedz

    @Jarek Żeliński
    Nie cho­dzi mi o kon­kret­ny pro­dukt, ale same podej­ście w reali­za­cji, któ­re w przy­pad­ku SOA ozna­cza wypro­du­ko­wa­nie sto­su skom­pli­ko­wa­nych pro­ce­dur, listy inter­fej­sów do zre­ali­zo­wa­nia, aby przy­łą­czyć sys­tem. Duża nad­mia­ro­wość i skom­pli­ko­wa­nie, któ­re mają niby przy­nieść ela­stycz­ność, powo­du­ją, że nikt tego nie ogar­nia, a pro­ste ope­ra­cje dołą­cze­nia nowe­go sys­te­mu lub zmia­ny, albo powo­du­ją para­liż orga­ni­za­cyj­ny, albo też zabie­ra­ją znacz­nie wię­cej cza­su niż­by okre­śle­nie ​„zwin­ność” sugerowało.
    Właściwie od same­go począt­ku okre­śle­nie SOA, było dla mnie podej­rza­ne:) Pracując wie­le lat w róż­nych rolach (admi­ni­stra­tor, pro­gra­mi­sta, ana­li­tyk, szef pro­jek­tu) zawsze uwa­ża­łem infor­ma­ty­kę jako ​„Service”. A tu nagle: zło­ta myśl, eure­ka, oświe­ce­nie: ​„zrób­my opro­gra­mo­wa­nie tak by świad­czy­ło usługi” 🙂

    BTW: Czy może sły­szał Pan o jakimś peł­nym wdro­że­niu SOA? W Polsce. Gdzieś na świe­cie? Przyznam się, że zasta­na­wia­łem się ostat­nio nad tym i nie­ste­ty nie byłem w sta­nie zna­leźć takie­go przykładu 🙂

    1. Jarek Żeliński 2 grudnia 2012

      To wszyst­ko zale­ży od tego jak zde­fi­niu­je­my SOA. Jeżeli lite­ral­nie, czy­li Architektura Zorientowana na Usługi, to w zasa­dzie mamy kom­po­nen­to­we sys­te­my obiek­to­we sza­nu­ją­ce zasa­dę, wg. któ­rej każ­dy kom­po­nent – podob­nie jak kla­sy – ma ści­śle okre­ślo­na odpo­wie­dzial­ność. Takie widywałem…

  3. jacek2v 2 grudnia 2012 Odpowiedz

    @Jarek Żeliński
    ​„wg. któ­rej każ­dy kom­po­nent ? podob­nie jak kla­sy ? ma ści­śle okre­ślo­na odpowiedzialność. ”
    Wydaje mi się, że to nie wystar­czy by coś mogło zostać nazwa­ne SOA. Obecnie wie­le sys­te­mów nieSOA, moż­na tak opi­sać i nie ​„powsta­nie” SOA :). Np. ERP – odpo­wia­da za wysta­wia­nie fak­tur:) W dużym skró­cie, w moim rozu­mie­niu reali­za­cja SOA to przej­rzy­ste, pro­ste i expli­ci­te okre­ślo­ne inter­fej­sy. Tak i pro­gra­mo­we, jak i takie, za któ­re odpo­wie­dzial­ny jest człowiek.

    1. Jarek Żeliński 3 grudnia 2012

      Ale jeże­li uznać, że każ­dy kom­po­nent jest widzia­ny poprzez (i tyl­ko) swój inter­fejs to mamy kon­sen­sus :), SOA to poję­cie ​„worek” dla­te­go napi­sa­łem, że to jedy­nie ​„archi­tek­tu­ra” a nie tech­no­lo­gia czy nawet pro­dukt (co sta­ra­ją się wma­wiać dostaw­cy pro­duk­tów z akro­ni­mem SOA w nazwie). W kwe­stii inter­fej­sów, GUI (gra­ficz­ny inter­fejs użyt­kow­ni­ka) to tyl­ko wierz­cho­łek góry lodo­wej, sys­te­my skła­da­ją się z wie­lu kom­po­nen­tów, wie­le z nich nie ma bez­po­śred­nie­go kon­tak­tu z ludz­kim użyt­kow­ni­kiem, obec­nie naj­bli­żej do SOA ma chy­ba to co nazy­wa­my clo­ud computing.

  4. jacek2v 3 grudnia 2012 Odpowiedz

    Could Computing to dobry przy­kład uda­ne­go SOA np. Google App Engine.
    A co do narzę­dzi to powin­ny one wspie­rać mak­sy­mal­nie archi­tek­tu­rę na jak naj­niż­szym pozio­mie imple­men­ta­cji – języ­ki pro­gra­mo­wa­nia, CSV, GUI desi­gners itp. Nie da się zre­ali­zo­wać zało­żeń kon­kret­nej archi­tek­tu­ry dowol­nym narzę­dziem IT. Stary, dobry i eks­tre­mal­ny przy­kład do pisa­nie ERP w assem­ble­rze 🙂 Technicznie moż­li­we, ale sił, moty­wa­cji, cza­su i pie­nię­dzy nie starczy.

    1. Jarek Żeliński 3 grudnia 2012

      Hm… jeśli dobrze rozu­miem to inter­fej­sy świad­czą­ce usłu­gi powin­ny być chy­ba na ​„wyso­kim” pozio­mie np. Webservice, REST, JASON…???

  5. jacek2v 3 grudnia 2012 Odpowiedz

    @Jarek Żeliński
    Tak, zga­dza się. Tylko zawsze trze­ba czymś je ​„skle­jać”: mapo­wać infor­ma­cję prze­sy­ła­ną przez nie; oraz zmie­niać same inter­fej­sy: popra­wiać i rozbudowywać.
    WebService napi­sa­ny w assem­ble­rze sła­bo się kon­ser­wu­je (main­te­nan­ce) 🙂
    Mapowanie w języ­kach niskie­go pozio­mu też nie­zbyt spraw­nie się robi i przej­rzy­ście wygląda 🙂

    1. Jarek Żeliński 3 grudnia 2012

      fak­tem jest, że ​„for­mat danych” jest waż­ny, tu kła­nia się brak stan­dar­dów ale ich raczej nie będzie dla­te­go jestem zda­nia, że w API powin­ny być udo­stęp­nia­ne tyl­ko całe obiek­ty a nie poszcze­gól­ne pola bo to łatwiej­sze (jed­no zapy­ta­nie i mapo­wa­nia i odsiew po stro­nie pytającego).

  6. jacek2v 3 grudnia 2012 Odpowiedz

    Tak, for­mat dany jest istot­ny – cały czas zadzi­wia mnie, ze do tej pory rzad­ko uży­wa­ne są stan­dar­do­we for­ma­ty np. do faktury 🙂
    Mapowanie obiek­tu to nie jest dobre roz­wią­za­nie i nie zawsze możliwe.
    Integrowane sys­te­my czę­sto są ​„zasta­ne” i nie mody­fi­ko­wal­ne. Przy nowych sys­te­mach nie ma sen­su two­rzyć dodat­ko­wych inter­fej­sów tłu­ma­czą­cych, a lepiej zacho­wać natyw­ny i naj­le­piej zin­te­gro­wa­ny tech­no­lo­gicz­nie inter­fejs API. A inte­gra­cję prze­pro­wa­dzić za pomo­cą dodat­ko­wej apli­ka­cji inte­gra­cyj­nej. Dzięki temu uzy­sku­je­my wyso­ki poziom apli­ka­cji: żad­na nic nie wie o pozo­sta­łych – oczy­wi­ście poza apli­ka­cją integrującą :).
    Co praw­da powsta­je wte­dy SPOF (Single Point Of Failure), ale jest kil­ka spo­so­bów na zabez­pie­cze­nie się przed awa­ria­mi lub roz­pro­sze­nie SPOF.

Dodaj komentarz

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