Przewiduję powol­ne odcho­dze­nie od idei sys­te­mów zin­te­gro­wa­nych na jed­nym mode­lu danych. Dotychczasowa ich zale­ta czy­li peł­na (i zara­zem trwa­ła) 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 kom­po­nen­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. Z tego też powo­du rośnie zain­te­re­so­wa­nie sys­te­ma­mi typu mid­dle­wa­re (szy­ny ESB). Do tej pory były wyko­rzy­sty­wa­ne rzad­ko i dużych fir­mach, głów­nie w sek­to­rze finan­so­wym i głow­nie z uwa­gi na ich koszt. Obecnie roz­wią­za­nie to sta­je się coraz popu­lar­niej­sze. Dlatego?

Pojawienie się stan­dar­dów w mode­lo­wa­niu, usta­no­wie­nie mode­lo­wa­nia peł­no­war­to­ścio­wym eta­pem pro­jek­tu (a nie eks­tra­wa­gan­cją), otwie­ra­nie się tech­no­lo­gii, poja­wia­nie się stan­dar­dów wymia­ny meta­da­nych i mode­li, toru­ją dro­gę do znacz­ne­go obni­że­nia kosz­tów i uspraw­nie­nia two­rze­nia sys­te­mów opar­tych o kom­po­nen­ty. To wszyst­ko powo­du­je, że nie trze­ba jed­ne­go wiel­kie­go sys­te­mu zin­te­gro­wa­ne­go. Wystarczy tak zwa­ny motor pro­ce­sów biz­ne­so­wych i spe­cja­li­zo­wa­ne sys­te­my, mogą one pocho­dzić od róż­nych pro­du­cen­tów i pra­co­wać na róż­nych platformach.

Jedyne cze­go trze­ba prze­strze­gać to pra­ca od samej góry: model biz­ne­so­wy orga­ni­za­cji, model pro­ce­sów biz­ne­so­wych, struk­tu­ra work­flow (sce­na­riu­sze dzia­łań czy­li wewnętrz­ny opis pro­ce­sów), lista ocze­ki­wa­nych usług sys­te­mu IT i sam sys­tem skła­da­ny z kom­po­nen­tów. Te trzy ele­men­ty: model biz­ne­so­wy, model pro­ce­sów, usłu­gi IT sta­no­wią pew­ną całość. Ubranie opi­su usług w cia­ło to wła­śnie obiektowe/komponentowe tech­no­lo­gie w IT, archi­tek­tu­ra SOA i MDA, języ­ki i nota­cje BPMN, UML oraz for­mat danych XML, obiek­to­we języ­ki programowania.

Koniec quasimonopolu dostawców systemów

No i oka­za­ło sie, że stan­dar­dy spraw­dzo­ne same się bro­nią. Microsoft w BizTalk Server będzie wspie­rał BPEL (Business Proces Execution Language, opar­ty na XML język skryp­to­wy opi­su pro­ce­sów mię­dzy inny­mi w sys­te­mach BPM i work­flow mana­ge­ment uży­wa­ny już mię­dzy inny­mi w nie­któ­rych sys­te­mach CASE). Oracle tak­że rozu­mie” BPEL. Modelowanie sta­je się nor­mą a otwar­tość stan­dar­dem. Notacje UML i BPMN sta­ją się stan­dar­dem modelowania.

Co to zna­czy? Moim zda­niem to, że powo­li sta­je się coś o czym pisa­łem swe­go cza­su na stro­nach IT-Consulting. Monopolistę zaczę­li doga­niać kon­ku­ren­ci. Monopolista zaczy­na czuć poko­rę: już nie wyzna­cza sam stan­dar­dów de’fac­to (np. for­ma­ty pli­ków doku­men­tów, narzę­dzia pro­gra­mi­stycz­ne, inter­fej­sy komu­ni­ka­cyj­ne). Tracąc powo­li rynek na rzecz roz­wią­zań kon­ku­ren­cji dostrzegł, że to co było prze­wa­gą ryn­ko­wą (zamknię­te roz­wią­za­nia) sta­ło się w dal­szej per­spek­ty­wie hamul­cem. Przyszła pora na otwar­tość i kon­ku­ro­wa­nie jako­ścią a nie szan­taż ponad 80% udzia­łem w ryn­ku (vide współ­pra­ca Microsoft i Novell).

Kierunki rozwoju systemów IT

Albo ana­li­za pro­ce­so­wa i obiek­to­wa albo na mar­gi­nes życia. Coraz powszech­niej­sze zro­zu­mie­nie idei zorien­to­wa­nia na pro­ce­sy, inte­ro­pe­ra­cyj­no­ści (w tym zarzą­dza­nie łań­cu­cha­mi dostaw), archi­tek­tu­ry SOA (któ­ra moim zda­niem dosko­na­le się wpa­so­wu­je w meto­dy zarzą­dza­nia zorien­to­wa­ne­go na pro­ce­sy i reor­ga­ni­za­cję w fir­mach) powo­du­je sta­wia­nie takich wyma­gań tak­że dostaw­com roz­wią­zań IT. Te któ­re się do tego nie dosto­su­ją, moim zda­niem odej­dą z rynku.

Model biz­ne­so­wy fir­my, infor­ma­cje i dane jakich fir­ma wyma­ga do spraw­ne­go funk­cjo­no­wa­nia to już jeden orga­nizm. Stało się fak­tem, że żad­na fir­ma na ryn­ku już nie będzie w sta­nie kon­ku­ro­wać bez spraw­ne­go zarzą­dza­nia infor­ma­cją. Do zarzą­dza­nia infor­ma­cją i prze­twa­rza­nia danych zaś potrzeb­ne są spraw­nie dzia­ła­ją­ce i przede wszyst­kim łatwe w ich roz­wi­ja­niu sys­te­my. Warunek taki speł­nia­ją obec­nie zorien­to­wa­ne na pro­ce­sy sys­te­my two­rzo­ne w tech­no­lo­giach obiektowych.

Drugi waru­nek spraw­no­ści orga­ni­za­cji to opty­ma­li­za­cja jej wewnętrz­nej wydaj­no­ści. Tu wkra­cza­my dla odmia­ny w zarzą­dza­nie i jego pro­ce­so­wą natu­rę. Jak to pogo­dzić? Postrzegam tu wła­śnie miej­sce dla archi­tek­tu­ry SOA. Firmę i jej miej­sce w ryn­ko­wym łań­cu­chu war­to­ści moż­na, moim zda­niem, jed­no­znacz­nie opi­sać tyl­ko za pomo­cą mode­lu pro­ce­so­we­go zorien­to­wa­ne­go na pro­duk­ty. Zasoby (tu sys­tem IT) potrzeb­ne do reali­za­cji tej stra­te­gii ana­li­zu­je­my już obiektowo.

Namiastką takich opi­sów i ana­liz były pro­ce­du­ry w księ­gach jako­ści ISO. Do peł­nej ana­li­zy wyma­ga­ny jest jed­nak opis (mapa pro­ce­sów) uwzględ­nia­ją­cy cały obraz fir­my. SOA to archi­tek­tu­ra wska­zu­ją­ca natu­ral­ny pro­ces pro­jek­to­wa­nia sys­te­mów IT: model pro­ce­so­wy fir­my (orga­ni­za­cji), ana­li­za pro­ce­sów z per­spek­ty­wy zaso­bów IT jaki­mi mogą być wspie­ra­ne, na bazie tej ana­li­zy powsta­je lista usług na rzecz pro­ce­sów biz­ne­so­wych jakich ocze­ku­je­my od nowe­go systemu.

Następnie w pro­ce­sie ana­li­zy obiek­to­wej usłu­gi te trans­po­no­wa­ne są na model obiek­to­wy przy­szłe­go sys­te­mu IT. Analiza obiek­to­wa powin­na dać jako pro­dukt tak­że opis dzie­dzi­ny sys­te­mu czy­li repre­zen­ta­cję rze­czy­wi­stych obiek­tów w sys­te­mie. Jest to pod­sta­wa mode­lu danych dla powsta­ją­ce­go sys­te­mu. Kolejne eta­py to już pro­jekt obiek­to­we­go pro­gra­mu (apli­ka­cji) i jego implementacja.

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).

Dodaj komentarz

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