[toc]

Usługi na sztu­ki czy kom­plek­so­we pakiety

SOA moim zda­niem zagro­zi­ło zin­te­gro­wa­nym sys­te­mom np. ERPII i nie tyl­ko. Pojawiło się świa­teł­ko w tune­lu dla szyb­ko wdra­ża­nych apli­ka­cji na życze­nie z jed­no­cze­sną moż­li­wo­ścią oce­ny ich rentowności.

SOA: usługi na miarę, system jak ulał

Service Oriented Architecture (ang. Architektura Zorientowana na Usługi) to idea two­rze­nia sys­te­mów infor­ma­cyj­nych w posta­ci nie­za­leż­nych kom­po­nen­tów. Każdy kom­po­nent to obiekt ze ści­śle zde­fi­nio­wa­ną funk­cjo­nal­no­ścią. Celem każ­de­go kom­po­nen­tu jest wspar­cie kon­kret­ne­go pro­ce­su biznesowego.

O jakie pro­ce­sy cho­dzi? Tu wagi nabie­ra mode­lo­wa­nie pro­ce­sów zorien­to­wa­ne na pro­duk­ty. Projektowanie tego typu roz­wią­zań wyma­ga mode­lo­wa­nia na kil­ku pozio­mach. Należy wyko­nać model pro­ce­sów śred­nie­go pozio­mu. Jest to model nazy­wa­ny cza­sem mapą pro­ce­sów na dru­gim pozio­mie. Ten poziom obra­zu­je pro­duk­ty ale jesz­cze nie doty­ka szcze­gó­łów wyko­ny­wa­nia czyn­no­ści. Model na tym pozio­mie nazy­wa­ny bywa tak­że wewnętrz­nym łań­cu­chem war­to­ści fir­my. Na tym pozio­mie np. fak­tu­ro­wa­nie (wysta­wie­nie fak­tu­ry) jest to jeden pro­ces koń­czą­cy się pro­duk­tem, któ­rym jest tu faktura.

Gdyby teraz wyma­ga­niem było wspar­cie pro­ce­su fak­tu­ro­wa­nia nale­ża­ło by użyć kom­po­nen­tu Fakturowanie, zasi­lić go dany­mi do fak­tu­ry (dane kon­tra­hen­ta i zwią­za­ne z nim upu­sty i ter­mi­ny płat­no­ści, pro­duk­ty lub usłu­gi oraz ich ceny i wolu­me­ny i inne) by uzy­skać pro­dukt pro­ce­su czy­li fakturę.

Ale o tym jak zin­for­ma­ty­zo­wać tak całą fir­mę w dal­szej części.

Usługi: idea stara jak informatyka

Idea budo­wy apli­ka­cji czy całych sys­te­mów przy­sta­ją­cych do poje­dyn­czych potrzeb nie jest nowo­ścią. Modelowanie pro­ce­sów jest zna­ne od cza­sów poja­wie­nie się meto­do­lo­gii zarzą­dza­nia jako­ścią. Dostępne wcze­śniej tech­no­lo­gie oraz nie­mal­że zupeł­ny brak stan­dar­dów sku­tecz­nie jed­nak unie­moż­li­wia­ły imple­men­ta­cje takich pomysłów.

Metody pro­jek­to­wa­nia apli­ka­cji oraz tech­no­lo­gie ich imple­men­ta­cji były bar­dzo her­me­tycz­ne. Programy były zin­te­gro­wa­ny­mi (nie raz są i w obec­nych cza­sach) wiel­ki­mi zbio­ra­mi wywo­łu­ją­cych się pod­pro­gra­mów ope­ru­ją­cy­mi bez­po­śred­nio na zbio­rach danych. Praktycznie unie­moż­li­wia­ło to jakie­kol­wiek powtór­ne uży­cie jakie­go­kol­wiek frag­men­tu kodu.

Przełomem w tej dzie­dzi­nie było poja­wie­nie się obiek­to­wych metod ana­li­zy oraz spo­pu­la­ry­zo­wa­nie obiek­to­wych języ­ków pro­gra­mo­wa­nia takich jak C++, .NET czy Java. Metody te w połą­cze­niu z doj­rza­łą wie­dzą o mode­lo­wa­niu pro­ce­sów i zarzą­dza­niu zorien­to­wa­nym na pro­ce­sy dały dopie­ro moż­li­wość pro­jek­to­wa­nia i two­rze­nia sys­te­mów zorien­to­wa­nych na usługi.

Czym jest SOA

Przede wszyst­kim nie jest to żad­na tech­no­lo­gia a tyl­ko archi­tek­tu­ra. Mimo tego, że czę­sto sły­szy się opi­sy SOA brzmią­ce jak opi­sy tech­no­lo­gii nie jest nią ona. Nazwał bym tę archi­tek­tu­rę raczej zbio­rem zale­ceń, dobrych prak­tyk, wzor­ców oraz wska­zó­wek do pro­jek­to­wa­nia. Jakich? Droga od opi­su orga­ni­za­cji do imple­men­ta­cji ma kil­ka eta­pów. Każdy z nich to ana­li­za i model kolej­nej warstwy.

Proces two­rze­nia sys­te­mu w archi­tek­tu­rze SOA zaczy­na się od wdro­że­nia w orga­ni­za­cji metod zarzą­dza­nia zorien­to­wa­nych na pro­ce­sy. Podstawą jest zbu­do­wa­nie popraw­ne­go mode­lu pro­ce­sów i zop­ty­ma­li­zo­wa­nie go.

Kolejnym eta­pem jest okre­śle­nie, któ­re pro­ce­sy jaki­mi usłu­ga­mi chce­my wspie­rać. Ten etap powią­za­ny jest z ana­li­zą ren­tow­no­ści pro­jek­tu. Każdy wybór pro­ce­su powi­nien się wią­zać z oce­ną war­to­ści jaką pro­ces wno­si do całe­go łań­cu­cha war­to­ści orga­ni­za­cji, war­tość ta decy­du­je o dopusz­czal­nym kosz­cie imple­men­ta­cji usłu­gi wspie­ra­ją­cej ten proces.

Po doko­na­niu wybo­ru pro­ce­sów, któ­re będzie­my wspie­rać zaso­ba­mi IT przy­stę­pu­je­my do ana­li­zy wyma­gań i pro­jek­to­wa­nia. Ten etap koń­czy się pro­jek­tem archi­tek­tu­ry obiek­to­wej komponentu.

Rysunek 1: Model imple­men­ta­cji archi­tek­tu­ry SOA

Kolejny krok to imple­men­ta­cja. Tu z pomo­cą może przyjść MDA czy­li archi­tek­tu­ra ste­ro­wa­na mode­lem (ang. Model Driven Architecture). MDA to ścież­ka od mode­lu obiek­to­we­go do kodu wyko­ny­wal­ne­go aplikacji.

Opis tego pro­ce­su pozwa­la przy­pusz­czać, że czas od pro­jek­tu do wdro­że­nia może trwać nawet kwar­tał. Jak to się dzieje??

Projektowanie i wdrażanie nowych systemów w standardach

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ę. 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 i reali­zu­je­my już obiektowo.

Jak już wspo­mnia­no histo­rycz­nie namiast­ką 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 firmy.

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.

Jak widać archi­tek­tu­ra zorien­to­wa­nia na pro­ce­sy to wydaj­na i sku­tecz­na meto­do­lo­gia pro­jek­to­wa­nia, mody­fi­ko­wa­nia i wdra­ża­nia funk­cjo­nal­no­ści w sys­te­mach IT. 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. Tak to widzę.

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 obiek­to­we tech­no­lo­gie w IT, archi­tek­tu­ra SOA i MDA, języ­ki i nota­cje i stan­dar­dy XML, BPEL, BPMN, UML, XMI, obiek­to­we języ­ki programowania.

Co po systemach zintegrowanych

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 będzie moż­na ?skle­ić? z kom­po­nen­tów róż­nych pro­du­cen­tów. Technologia obiek­to­wa bar­dzo ten pro­ces ułatwiła.

Drugim powo­dem prze­wi­dy­wa­ne­go prze­ze mnie odej­ścia od idei typo­wych sys­te­mów zin­te­gro­wa­nych 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 biz­ne­so­we­go. Z tego też powo­du rośnie zain­te­re­so­wa­nie sys­te­ma­mi typu mid­dle­wa­re. Do tej pory były one wyko­rzy­sty­wa­ne rzad­ko i raczej w dużych fir­mach, głów­nie w sek­to­rze finan­so­wym 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ą więc 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.

Czyż 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 sup­por­to­wał 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 w jed­nym z moich wcze­śniej­szych arty­ku­łów. 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).

Dostawcy sys­te­mów MRPII/ERP są obec­nie quasi mono­po­li­sta­mi u swo­ich obec­nych klien­tów: jaka­kol­wiek zmia­na funk­cjo­nal­no­ści wyma­ga kon­tak­tu z dostaw­ca sys­te­mu prak­tycz­nie bez moż­li­wo­ści zmia­ny tego sta­nu rze­czy, zakła­da­jąc że nie rezy­gnu­je­my cał­ko­wi­cie z posia­da­ne­go sys­te­mu na korzyść inne­go. System kom­po­nen­to­wy pozba­wi ich tego mono­po­lu. Będzie moż­li­we zaku­pie­nie modu­ły lub poje­dyn­cze­go kom­po­nen­tu i inne­go dostawcy.

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

? Jarosław Żeliński 2007

https://​it​-con​sul​ting​.pl

j.zelinski@it-consulting.pl

Tel.: 608 05 90 20

A016_Pakiety_zintegrowane_ERP_i_SOA