Integrasjon - må det være så vanskelig?

Integrasjonsprodukter ser gjerne imponerende ut på papiret. I praksis har mange erfart at det kan være både dyrt og tidkrevende å utvikle tjenester på dem. Verktøyene oppleves som komplekse og det er lite tilgjengelig kompetanse i markedet. Ofte resulterer dette i at forretningssiden må vente i lang tid på å få nye tjenester utviklet. Kjenner du deg igjen? Har du lurt på hvorfor det ble slik? La oss ta en titt på noen faktorer vi mener har formet fagområdet de siste 15 årene:

"SOA på boks"

Da konseptet «tjenesteorientert arkitektur» (SOA) begynte å bli populært utover 2000-tallet, stilte mange organisasjoner seg spørsmålet "Hvordan kan vi bli tjenesteorientert?". 

SOA var et nytt begrep for de fleste, og som med mange andre "buzz words" kunne det være vanskelig å forstå hva begrepet egentlig handlet om. Dette åpnet et marked som de store teknologileverandørene kastet seg over. 

Enterprise Service Bus gikk fra å være et konsept på et abstrakt, logisk nivå, til å være en konkret fysisk boks man kunne kjøpe og installere i sitt datasenter.  SOA var noe man «måtte ha», hvis man ønsket å ha en relevant og tidsriktig arkitektur i sin organisasjon. 

Innkjøpet av selve plattformen ble imidlertid tillagt for mye vekt. Produktleverandørene konkurrerte seg i mellom om å levere mest mulig funksjonalitet. De faktiske behovene organisasjonen hadde, fikk dermed for lite oppmerksomhet. 

Boka "Enterprise Integration Patterns" implementert som produkter 

Integrasjon har aldri vært spesielt vakkert. Fagområdet handler om å få ulike systemer til å fungere i en helhet, selv når systemene i utgangspunktet aldri var laget for å jobbe sammen. Se for deg et puslespill der ingen av brikkene passer helt sammen. Du må tøye, bøye og bruke tape for at resultatet skal bli bra.  

Boka "Enterprise Integration Patterns" (Hohpe, Wolff) fikk enorm innflytelse i fagmiljøet da den kom i 2003. Den definerte 63 «design patterns» for meldingsorientert integrasjon, samt et grafisk språk som beskriver disse på en ryddig måte. 

Ideene fra boka ble raskt implementert som produkter. Kunne dette være redningen som ryddet opp i integrasjonspuslespillet? Vi er ikke så sikker på det. 

Meldingsproduktene som implementerte ideene i boka tar ikke tilstrekkelig hensyn til at langt fra alle integrasjoner lar seg uttrykke effektivt som meldingsflyter. Utviklere må derfor "tilpasse" problemet slik at det passer inn i produktleverandørens språk for meldingsflyter. Koden blir derfor vanskelig å utvikle, forstå og vedlikeholde.  

Undervurdering av generelle programmeringsspråk 

Det var knyttet stor optimisme til mulighetene i den nye teknologien som beskrevet over. Ofte kunne man få inntrykk av at det ikke lenger ville være behov for programmerere for løse integrasjonsprosjekter. Med grafiske pek-og-klikk-verktøy kunne nå "hvem som helst" gjøre integrasjon uten å kode. 

Leverandørene unnlot imidlertid å fortelle at pek og klikk også er en form for programmering. Det er bare uttrykt på en mindre effektiv og presis måte.  

I praksis medførte dette en undervurdering av generelle programmeringsspråk og den medfølgende verktøykassen som språk som Java tilbyr. 

Dette medførte en rekke negative og fordyrende konsekvenser: 

Så hvordan bør så en integrasjonsplattform se ut i 2016? 

Som nevnt har vi i Kantega gjennom årene prøvd ut ulike tilnærminger til integrasjon. 

I den ene enden av spekteret har vi levert tjenester basert på store kommersielle integrasjonsplattformer. Som du har lest over er våre erfaringer med slike ikke utelukkende positive. 

I den andre enden har vi levert applikasjoner som løser integrasjon uten bruk av noen spesiell plattform. Her har vi i stedet tatt i bruk de rammeverk og biblioteker som vi har hatt behov for.  

Denne tilnærmingen har imidlertid medført sine egne sett med utfordringer: Skillet mellom applikasjon og generell infrastruktur blir utydelig, og det blir vanskelig å gjenbruke infrastruktur på tvers av prosjekter og tjenester.  

Så hvordan bør da en integrasjonsplattform se ut i 2016? La oss framheve noen arkitekturprinsipper som har vært viktige for løsningene Kantega har levert i de siste årene: 

Vi trenger en arkitektur som er enkel å tilpasse våre kunders faktiske behov. Det er viktig for oss å kunne håndplukke de beste løsningene for hvert konkrete problem og å sette de sammen til en fornuftig helhet. 

Dette mener vi er lettest å få til med en arkitektur som legger godt til rette for at de fleste problemer kan løses i et utbredt generelt programmeringsspråk, som for eksempel Java.  

Det ville for eksempel være uhensiktsmessig om hver enkelt tjeneste selv skulle måle transaksjonstid, logge tekniske feil eller håndheve autentisering og autorisasjon. Det vil alltid finnes behov for funksjonalitet på tvers av tjenester og integrasjoner. Slik kryssfunksjonell infrastruktur bør vedlikeholdes for seg, uavhengig av konkrete tjenester.  

Vi har innsett at ingen eksisterende monolittisk plattform løser våre kunders problemer optimalt. I stedet for å lete etter teknologi som løser alle problemer, ønsker vi oss heller å kunne sette sammen nøye utvalgte komponenter til en helhet. Helst ønsker vi å bruke etablert, veltestet teknologi som det finnes mye kompetanse på i markedet.  Vi trenger en plattform som legger til rette for god modularisering.

Oppsummert 

Kantega har de siste årene hjulpet flere kunder med å etablere smidige og framtidsrettede integrasjonsplattformer basert på arkitekturprinsippene beskrevet over. 

Dette har gjort det mulig for dem å gå bort fra dyre og lite fleksible lisensavtaler. Modularisering og gjenbruk sørger for at samme jobb ikke må gjøres mer enn en gang.  

Tjenester kan utvikles av vanlige Java-programmerere, uten at de trenger spesiell verktøykompetanse. Dette gir god tilgang på kompetanse, og stor fleksibilitet i planlegging av integrasjonsprosjekter.  

Dermed frigis midler og energi til det som tross alt er det viktigste: Å lage gode og nyttige tjenester for organisasjoner, brukere og kunder.


Har du lyst å vite mer om hvordan
Kantega løser integrasjon for våre kunder? Vi er glad i å dele våre erfaringer og vi møter deg gjerne for en prat. Kanskje vi kan hjelpe deg også? Ta kontakt i dag

Les også om prosjektet for NTE, hvor vi på tre uker bygget en helt ny integrasjonsplattform basert på nettopp disse tankene.

Litt om forfatteren

Eirik-Bjørsnøs

Eirik Bjørsnøs

Som Chief Scientist i Kantega er Eirik stadig på utkikk etter smartere teknologi og smidigere metoder som kan hjelpe oss å levere verdifull programvare mer effektivt. Eirik eksperimenterer med alt fra bytekodeoptimalisering til firmakultur og presenterer mer enn gjerne det han finner i foredrag på konferanser fjern og nær.
comments powered by Disqus