Temat inte­gra­cji prze­wi­ja się nie­mal­że w każ­dym wdro­że­niu. W wyma­ga­niach naj­czę­ściej widu­ję opis tego, jakie dane są wymie­nia­ne, bar­dzo rzad­ko widu­ję dodat­ko­we ogra­ni­cze­nia, w szcze­gól­no­ści chro­nią­ce kupu­ją­ce­go przez duży­mi kosz­ta­mi utrzy­ma­nia. Kupujący jako laik”, szcze­gól­nie sam piszą­cy wyma­ga­nia, prak­tycz­nie nie jest w sta­nie się obro­nić przed taki­mi kosz­ta­mi, a kry­te­rium niskiej ceny przy wybo­rze, prak­tycz­nie zawsze dopro­wa­dzi do przy­szłych kło­po­tów. Dlatego po raz kolej­ny piszę: spe­cy­fi­ka­cja wyma­gań powin­na zawie­rać pro­jekt roz­wią­za­nia, wte­dy nie­ja­ko zabro­ni­my” sto­so­wa­nia szko­dli­wych” roz­wią­zań przez dostaw­cę opro­gra­mo­wa­nia. Większość dostaw­ców opro­gra­mo­wa­nia zawsze będzie szła na skróty.

W poprzed­nim arty­ku­le pisa­łem o wyma­ga­niach poza­funk­cjo­nal­nych, doty­czą­cych kupo­wa­ne­go opro­gra­mo­wa­nia (Wymagania poza­func­kjo­nal­ne czy­li jaka archi­tek­tu­ra), dzi­siaj o inte­gra­cji z innymi.

Niestety sta­le obser­wu­ję podej­ście dostaw­ców opro­gra­mo­wa­nia (tak­że wewnętrz­ne dzia­ły IT!), bazu­ją­ce na moż­li­wie niskim kosz­cie i cza­sie wyko­na­nia inte­gra­cji (budo­wa­nie mar­ży, oszczęd­no­ści cza­su, nie raz nie­wie­dza) przy kom­plet­nym igno­ro­wa­niu tego, że przy­szłe kosz­ty utrzy­ma­nia są wie­lo­krot­nie więk­sze niż te oszczęd­no­ści, a nie raz tra­ci się nawet pano­wa­nie nad zło­żo­no­ścią posia­da­ne­go sys­te­mu (z per­spek­ty­wy dostaw­cy jest to zwy­kłe uza­leż­nia­nie klien­ta i gene­ro­wa­niu mu kosz­tów). Znam przy­pad­ki, w któ­rych źle (czy­taj złą meto­dą, bo trans­fer danych dzia­łał) wyko­na­ne kolej­ne inte­gra­cje nowych apli­ka­cji, dopro­wa­dzi­ły do sytu­acji, w któ­rej prak­tycz­nie nie był moż­li­wy, bez bar­dzo duże­go ryzy­ka kra­chu cało­ści, upgra­de żad­ne­go z pod­sys­te­mów! (w jed­nym z przy­pad­ków to nie była mała fir­ma, to był jeden z więk­szych ope­ra­to­rów sie­ci CATV).

Ale po kolei…

Wzorzec architektoniczny integracji – fasada/adapter

Architektura opro­gra­mo­wa­nia sto­su­ją­ce­go wzo­rzec fasa­dy (tu API) do inte­gra­cji wyglą­da tak:

Architektura integracji

Mamy tu dwie apli­ka­cje: Aplikacja 1 i Aplikacja 2. Każda ma jakąś logi­kę i jakiś skład danych (sys­tem utrwa­la­nia, celo­wo nie piszę baza danych, bo może to być tak­że sys­tem pli­ków). Tak zwa­ne [[API]] to kom­po­nent zapew­nia­ją­cy sepa­ra­cję wnę­trza apli­ka­cji od jej oto­cze­nia i bez­piecz­ne udo­stęp­nie­nie okre­ślo­nych ope­ra­cji (z regu­ły para­me­try­zo­wal­nych), któ­re moż­na z zewnątrz wywo­ły­wać, żąda­jąc pobra­nia lub zacho­wa­nia jakichś infor­ma­cji. Na zewnątrz API udo­stęp­nia Interfejs Oferowany (lizak w nota­cji UML powy­żej). Interfejs Wymagany (kie­li­szek w nota­cji UML powy­żej) to spe­cy­fi­ka­cja tego, cze­go potrze­bu­je apli­ka­cja. Innymi sło­wy Interfejs ofe­ro­wa­ny to funk­cjo­nal­no­ści (usłu­gi) jakie ofe­ru­je apli­ka­cja, inter­fejs wyma­ga­ny to nasze wyma­ga­nia wobec apli­ka­cji (nale­ży je zde­fi­nio­wać w toku ana­li­zy wymagań).

Na dia­gra­mie przy­pad­ków uży­cia inter­fejs ofe­ro­wa­ny to przy­pad­ki uży­cia a inter­fejs wyma­ga­ny to aktor i jego ocze­ki­wa­nia (dia­gram kom­po­nen­tów i odpo­wia­da­ją­cy mu dia­gram przy­pad­ków użycia):

Model komponenrtów - integracja
Model przypadków użycia - integracja

(wię­cej na temat sto­so­wa­nia dia­gra­mów przy­pad­ków uży­cia w kon­tek­ście inte­gra­cji w arty­ku­le o przy­pad­kach uży­cia i gra­ni­cy sys­te­mu)

Jak dopro­wa­dzić do przy­szłe­go kra­chu systemu

Otóż, jak wspo­mnia­łem, czę­stą prak­ty­ka jest dro­ga na skró­ty”, przez nie­któ­rych nazy­wa­na spa­wa­niem apli­ka­cji”. Wygląda to tak:

Częste praktyki

W Aplikacji 1 doda­je się kil­ka bez­po­śred­nich odwo­łań do bazy danych Aplikacji 2, by pobrać dane, któ­re są potrzeb­ne. Efekt tego podej­ścia to cał­ko­wi­te uza­leż­nie­nie dzia­ła­nia Aplikacji 1 od jakich­kol­wiek zmian w struk­tu­rze danych Aplikacji 2. Każda taka zmia­na w Aplikacji 2 (np. jej upda­te czy upgra­de) rodzi ryzy­ko błę­dów w tej wymia­nie danych (inte­gra­cja prze­sta­nie dzia­łać). Stosowanie tablic pośred­nich chro­ni wyłącz­nie przed nie­umyśl­nym naru­sze­niem inte­gral­no­ści danych. Kolejna poważ­na wada tej meto­dy to wymóg, by obie apli­ka­cje pra­co­wa­ły na jed­nym ser­we­rze lub w jed­nej sie­ci lokal­nej. Tak więc każ­da przy­szła ini­cja­ty­wa zwią­za­na np. z pra­cą w sie­ci roz­le­głej (prze­nie­sie­nie z jed­ne­go do inne­go oddzia­łu, przej­ście do chmu­ry itp.) nie ma tu racji bytu (sto­so­wa­nie sie­ci VPN w sie­ciach roz­le­głych to bar­dzo zawod­ny pomysł, wyma­ga­ją­cy bar­dzo kosz­tow­nych łączy).

Ta meto­da ma jesz­cze inną poważ­ną i bar­dziej ukry­tą” wadę. Logika biz­ne­so­wa (regu­ły biz­ne­so­we) raczej tkwi” poza bazą danych (tu Logika apli­ka­cji 2), w efek­cie pobie­ra­nie infor­ma­cji bez­po­śred­nio z bazy danych (System utrwa­la­nia 2) rodzi powa­ża­ne ryzy­ko, że pobra­ne dane będą szko­dli­we”, gdyż pobie­ra­nie ich z pomi­nię­ciem reguł biz­ne­so­wych, powo­du­je, że sens i cel imple­men­ta­cji tych reguł zosta­je zaprzepaszczony.

Jeżeli nasza aplikacja nie ma API

Nie raz mamy do czy­nie­nia ze sta­ry­mi” apli­ka­cja­mi ([[lega­cy sys­tem]]). Wtedy trze­ba API po pro­stu zapro­jek­to­wać i napi­sać. Powinien to zro­bić dostaw­ca apli­ka­cji, z któ­rą się inte­gru­je­my: jemu przed­sta­wia­my spe­cy­fi­ka­cję Interfejsu Wymaganego (I_Żądany1):

Stare aplikacje

Gdyby wymia­na danych odby­wa­ła się w obu kie­run­kach, two­rzo­ny adap­ter dodat­ko­wo pośred­ni­czy w pobie­ra­niu danych z Aplikacji 1.

Na zakończenie

Integracja to jeden z trud­niej­szych pro­ble­mów. Wymaga bowiem nie tyl­ko spe­cy­fi­ko­wa­nia (i potem ich imple­men­to­wa­nia) inter­fej­sów, ale tak­że ana­li­zy i opra­co­wa­nia bez­piecz­nej archi­tek­tu­ry całe­go sys­te­mu (tu zno­wu archi­tek­tu­ra kor­po­ra­cyj­na). Wiele firm ma, nie dwie ale kil­ka, kil­ka­na­ście a nie­któ­re nawet set­ki apli­ka­cji. Jeżeli będę ze sobą pospa­wa­ne” wywo­ła­nia­mi SQL/ODBC, to rusze­nie tego” prak­tycz­nie zawsze koń­czy się kra­chem (czy­taj ogrom­ne kosz­ty przy­wró­ce­nia funk­cjo­no­wa­nia cało­ści). Brak prze­my­śla­nej archi­tek­tu­ry, inte­gra­cja ad-hoc każ­dy z każ­dym”, to pro­sta dro­ga do kło­po­tów i ogrom­nych kosz­tów utrzy­ma­nia cało­ści. Stosowanie API (ich two­rze­nie) nie­co tyl­ko pod­no­si kosz­ty wdro­że­nia, za to chro­ni przed bar­dzo duży­mi, nie­pla­no­wa­ny­mi, wydat­ka­mi w przy­szło­ści. Wielu dostaw­ców opro­gra­mo­wa­nia ofe­ru­je w swo­ich pro­duk­tach API, wystar­czy z nich korzystać.

Dedykowane dzie­dzi­no­we apli­ka­cje coraz czę­ściej są wdra­ża­ne eta­pa­mi zamiast jed­ne­go duże­go ERP, taka inte­gra­cja nie jest wbrew pozo­rom kosz­tow­na, kosz­tow­ny jest brak sto­so­wa­nia dobrych prak­tyk i wzor­ców, któ­re war­to poznać. Zwinność dzia­ła­nia dzi­siej­szych firm na ryn­ku to wymóg a nie opcja. Zwinność taka to nie jeden duży ERP (mono­pol jed­ne­go usłu­go­daw­cy), to kil­ka zin­te­gro­wa­nych, dedy­ko­wa­nych nie­za­leż­nych apli­ka­cji , wdra­ża­nych bez kasto­mi­za­cji (wybie­ra­my naj­lep­szy pro­dukt w danym momen­cie). Ich (apli­ka­cje dzie­dzi­no­we) wymia­na na inne, przy dobrze wyko­na­nej inte­gra­cji, to jest pro­ces, któ­ry nie gene­ru­je mon­stru­al­nych kosz­tów każ­do­ra­zo­wej ana­li­zy i prze­rób­ki cało­ści IT (kolej­nej kasto­mi­za­cji jed­ne­go ERP) w firmie.

P.S.

2014-10-14 Ukazał się cie­ka­wy post na ten temat na blo­gu Trzecia Kawa:

Warto sto­so­wać kon­trakt dla usłu­gi, gdy inte­gru­je­my sys­te­my z mało mody­fi­ko­wal­nym i sła­bo zdo­ku­men­to­wa­nym API; gdy nie mamy moż­li­wo­ści spraw­dze­nia inte­gra­cji usług w trak­cie imple­men­ta­cji oraz gdy dzia­ła­my w śro­do­wi­sku o roz­pro­szo­nej odpo­wie­dzial­no­ści za inte­gra­cję systemów.Stosowanie kon­trak­tu dla usłu­gi pozwa­la unik­nąć dużych pro­ble­mów w trak­cie testów inte­gra­cyj­nych; sta­no­wi frag­ment spe­cy­fi­ka­cji sys­te­mo­wej, a w przy­pad­ku zasto­so­wa­nia mid­dle­wa­re pozwa­la na doku­men­to­wa­nie spe­cy­fi­ka­cji usłu­gi wzglę­dem okre­ślo­ne­go klien­ta. (Kontrakt świad­cze­nia usłu­gi ? Trzecia kawa).

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

  1. Piotr

    Nie napi­sał Pan jaw­nie (celo­wo?) o tym, że do reali­za­cji zada­nia wymia­ny infor­ma­cji mię­dzy róż­ny­mi kom­po­nen­ta­mi potrze­ba pośred­ni­ka zupeł­nie spo­za tych kom­po­nen­tów, czy­li cze­goś co przy­ję­ło nazwę ESB (Enterprise Service Bus). Samo API nie wystar­czy żeby unik­nąć gąsz­czu zależ­no­ści jed­ne­go kom­po­nen­tu od drugiego.

    1. Jaroslaw Zelinski

      Nie pisa­łem celo­wo, ale nie po to by coś ukryć :), a by nie suge­ro­wać, że ESB jest koniecz­ne, bo nie jest. Wspomniałem o dobrze opra­co­wa­nej” archi­tek­tu­rze, co mia­łem na myśli? Warto zwró­cić uwa­gę, że ana­li­zu­jąc sys­te­my dzie­dzi­no­we w jed­nej orga­ni­za­cji moż­na zawsze wska­zać te, któ­re są źró­dłem refe­ren­cyj­nym okre­ślo­nych danych i te, któ­re z nich korzystają. 

      Przemyślana archi­tek­tu­ra to odpo­wied­ni podział odpo­wie­dzial­no­ści pomię­dzy apli­ka­cje, któ­ry mini­ma­li­zu­je licz­bę inter­fej­sów i czy­ni jest pro­sty­mi. Często struk­tu­ra taka przyj­mu­je postać gwiaz­dy lub cze­goś zbli­żo­ne­go. Jeżeli jest jakaś logi­ka mani­pu­lo­wa­nia tą wymia­ną danych, warun­ko­we­go roz­dzie­la­nia itp. to bar­dzo opła­cal­ne jest napi­sa­nie, wdro­że­nie, nie­skom­pli­ko­wa­ne­go bro­ke­ra komu­ni­ka­tów (media­tor) z moto­rem reguł, niż zakup kosz­tow­nych sys­te­mów typu SOA/ESB.

      Bardzo czę­sto role takiej szy­ny inte­gra­cyj­nej peł­ni też (jako rodzaj bro­ke­ra) sys­tem BPM. Problem poja­wia się dopie­ro gdy tych apli­ka­cji jest nie kil­ka a kil­ka­na­ście i wię­cej ale też bał bym się mówić o regu­le. Patrząc na dobrze zapro­jek­to­wa­ne opro­gra­mo­wa­nie obiek­to­we, mamy tam dzie­siąt­ki klas z ich inter­fej­sa­mi i nie mamy żad­nej szy­ny, raczej wzor­ce pro­jek­to­we w rodza­ju obser­wa­tor czy [[publish/subscribe]] (rodzaj bar­dzo pro­stej szy­ny komu­ni­ka­cyj­nej albo po pro­tu cza­sem jed­na cen­tral­na apli­ka­cja), któ­re tak­że moż­na zasto­so­wać na pozio­mie kom­po­nen­tów jaki­mi są aplikacje. 

      Moim zda­niem pro­ble­mem są raczej cha­otycz­ne, ode­rwa­ne od sie­bie zaku­py apli­ka­cji w wie­lu dużych fir­mach, gdzie pro­ble­mem jest zastany/uzyskany” stan inwen­ta­rza”. W wie­lu przy­pad­kach prze­my­śla­na archi­tek­tu­ra cało­ści (zno­wu ta archi­tek­tu­ra kor­po­ra­cyj­na :)) zupeł­nie wystar­czy by model inte­gra­cji nie był węzłem gor­dyj­skim. Niestety kil­ka wdro­żeń ESB, któ­re widy­wa­łem (jed­no nawet w pew­nym ban­ku) upa­dły nie dla­te­go, że roz­wią­za­nie było złe, tyl­ko dla­te­go, że zasta­ne apli­ka­cje było dzie­łem przy­pad­ku i nie było żad­nej logi­ki w ich komu­ni­ka­cji, tego żad­ne ESB nie wyleczy.

      Użycie kosz­tow­nych roz­wią­zań ESB powin­no mieć raczej sens ekonomiczny. 

    2. Piotr

      Czyli jest spo­sób taki, któ­ry nie potrze­bu­je ESB a daje ten sam efekt (czy­li mię­dzy inny­mi luź­ne powią­za­nia mię­dzy kom­po­nen­ta­mi)? Mimo wszyst­ko teraz nie potra­fię go sobie wyobra­zić, ale to raczej wina mojej nie­wie­dzy. Czytałem kie­dyś arty­kuł na stro­nach IBMa o tym, że po ESB trze­ba się­gać ostroż­nie, bo jego wyma­ga­nia (nad zarzą­dza­niem) mogą prze­ro­snąć jego zale­ty. Sądzę jed­nak, że IBM miał na myśli te duże ESB.

      A samo ESB nie musi być ani dro­gie, ani skom­pli­ko­wa­ne. Wystarczy się­gnąć po roz­wią­za­nia spo­za main­stre­amu, np: https://​zato​.io/
      P.

    3. Jaroslaw Zelinski

      Przede wszyst­kim nie łącz­my pojęć pro­dukt cośESB fir­my XXX” i kom­po­nent reali­zu­ją­cy logi­kę wymia­ny danych”. To tak­że powód, dla któ­re­go nigdy w pro­jek­tach inte­gra­cyj­nych nie ope­ru­ję poję­ciem ESB. To dopie­ro z wyma­gań i pro­jek­tu archi­tek­tu­ry może wyni­kać, że taki kom­po­nent jest potrzeb­ny. W prze­ciw­nym wypad­ku moż­na dopro­wa­dzić do sytu­acji, w któ­rej naj­pierw ktoś kupu­je cośESB” a potem na siłę szu­ka mu zasto­so­wa­nia (w kon­tek­ście uwa­gi na stro­nach IBM i kil­ku wiel­kich pora­żek w tym kra­ju). Wybór imple­men­ta­cji ESB” powi­nien być kon­se­kwen­cją wyma­gań i ren­tow­no­ści a nie mody ;), wiem, ze są i dro­gie i nie­dro­gie i open sour­ce i nie… Nie raz oka­zu­je się, że taki kom­po­nent po pro­stu nie jest wymagany.

  2. Jaroslaw Zelinski

    Ciekawe infor­ma­cje o inte­gra­cji i wzor­cach archi­tek­to­nicz­nych moż­na zna­leźć tu: EIP

Dodaj komentarz

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