Bardzo czę­sto spo­ty­kam się w fir­mach z wyma­ga­niem by ana­li­za zawie­ra­ła ​„opis inte­gra­cji”. Brzmi ład­nie jed­nak ​„pod maską” czai się ​„dia­beł”:

Obraz gęstej i coraz bar­dziej sie­ci apli­ka­cji wyła­nia się z bada­nia ponad tysią­ca dyrek­to­rów dzia­łów IT przez fir­mę Capgemini. Taki stan rze­czy obcią­ża depar­ta­men­ty IT i hamu­je trans­for­ma­cję cyfro­wą. (źr. Skomplikowana sieć apli­ka­cji to kula u nogi dzia­łów IT. wnp​.pl | Informatyka. Informatyka dla prze­my­słu.).

Opisze to krót­ko i od końca.

W ofer­tach i pre­zen­ta­cjach dostaw­ców tech­no­lo­gii inte­gra­cyj­nych nie raz zoba­czy­my pięk­ny obra­zek poka­zu­ją­cy jakie to zba­wie­nie nas cze­ka po wdro­że­niu magicz­nie brzmią­ce­go ESB ([[Enterprise Service Bus]]). Z regu­ły ma to taką lub podob­ną postać:

Na dia­gra­mie tym jed­nak ​„spryt­nie” poka­za­łem wyłącz­nie odwo­ła­nia pomię­dzy kom­po­nen­ta­mi uło­żo­ny­mi w ​„gwiaz­dę”, któ­rej cen­trum sta­no­wi ESB, a nie fak­tycz­ny prze­pływ danych. Diagram taki jest ład­ny bo pro­sty a do tego ​„nie kła­mie”. Na czym pole­ga pod­stęp? Na tym, że ESB to wyłącz­nie ​„pośred­nik” w mode­lu komu­ni­ka­cji [[publish-sub­scri­be]].

Tak na praw­dę inte­gra­cja taka pole­ga nie na samym zain­sta­lo­wa­niu ESB i ​„pod­łą­cze­niu” kom­po­nen­tów, to samo z sie­bie nic nie wno­si i nie jest łatwe. Integracja z uży­ciem ESB, to po pierw­sze stwo­rze­nie (lub uży­cie jeże­li ist­nie­je) dla każ­de­go kom­po­nen­tu odpo­wied­nie­go adap­te­ra i API, po dru­gie zapro­jek­to­wa­nie sche­ma­tu (sce­na­riu­szy) komu­ni­ka­cji. Na tym eta­pie jesz­cze nie widać pod­stę­pu. Widać go dopie­ro po odkry­ciu (udo­ku­men­to­wa­niu), z regu­ły, bała­ga­nu archi­tek­to­nicz­ne­go. Bardzo czę­sto komu­ni­ka­cja w takich sie­ciach ma taką postać (poka­za­no tak­że użytkowników):

Tu bar­dzo deli­kat­nie chcia­łem poka­zać coś w rodza­ju ​„nie­mal­że każ­dy z każ­dym”, a mamy tu tyl­ko pięć kom­po­nen­tów (apli­ka­cji). A jak jest ich wię­cej? Bardzo czę­sto kolej­ne nowe apli­ka­cje w fir­mach są kupo­wa­ne i inte­gro­wa­ne cha­otycz­nie, bez prze­my­śla­nej wizji cało­ści archi­tek­tu­ry. Mści się to w póź­niej­szym okre­sie, przy każ­dej pró­bie inge­ren­cji w taką struk­tu­rę (znam przy­pad­ki gdy tak bano się takiej inge­ren­cji, że zanie­cha­no roz­wo­ju IT). To powód, dla któ­re­go wie­le takich wdro­żeń koń­czy się prze­rwa­niem ich (czy­li poraż­ką). Jest to – poraż­ka – pra­wie pew­ne, gdy jako meto­dy inte­gra­cji uży­to współ­dzie­le­nia danych (opi­sa­łem to tu).

W takich pro­jek­tach pierw­szą rze­czą jaką nale­ży zro­bić, to wyko­nać ana­li­zę i opra­co­wać model infor­ma­cyj­ny fir­my, czy­li model tego jakie infor­ma­cje są two­rzo­ne, po co i jak są ze sobą sko­ja­rzo­ne, prze­twa­rza­ne i prze­ka­zy­wa­ne. W dru­gim kro­ku nale­ży usta­lić gdzie są ich wer­sje pier­wot­ne (źró­dło­we, refe­ren­cyj­ne) a gdzie wtór­ne (np. kopie wyko­rzy­sty­wa­ne). Kolejny krok to upo­rząd­ko­wa­nie wymia­ny danych, dopro­wa­dze­nie struk­tu­ry sie­ci do posta­ci hie­rar­chicz­nej (źró­dło refe­ren­cyj­ne i użyt­kow­ni­cy), któ­ra bar­dzo upro­ści powyż­szy model, z regu­ły do postaci:

Taka ana­li­za i opty­ma­li­za­cja pozwo­li po pierw­sze w ogó­le opa­no­wać nara­sta­ją­cy lata­mi cha­os, a po dru­gie nie raz odkry­wa się sta­re i nie­uży­wa­ne apli­ka­cje czy dublu­ją­ce się co do ich funk­cjo­nal­no­ści, któ­re po pro­tu wyłą­cza się. Po takich porząd­kach wdro­że­nie ESB owszem wyglą­da jak na pierw­szym dia­gra­mie, jed­nak pro­jekt ma duże szan­se powo­dze­nia, znacz­nie więk­sze w porów­na­niu z inte­gra­cją ​„cha­osu”. Podejście takie nazy­wa­ne jest [[Enterprise appli­ca­tion integration]].

Co cie­ka­we, po takim pro­jek­cie pozo­sta­nie nam doku­men­ta­cja sys­te­mu, któ­rą wystar­czy kon­ser­wo­wać (to nie jest aż tak kosz­tow­ne ale zawsze znacz­nie tań­sze niż kolej­na ana­li­za od zera przy kolej­nym wdro­że­niu). Z taką doku­men­ta­cją już tyl­ko krok do SOA i archi­tek­tu­ry korporacyjnej :).

Bardzo cie­ka­wy arty­kuł doty­czą­cy utrzy­ma­nia lub rezy­gna­cji ze ​„sta­rych apli­ka­cji” zawie­ra COMPUTERWORLD nr 9/2014