Den eksponentielle utviklingen vi ser i dag, som en revolusjon(!), påvirkes av og påvirker mye – men sentralt er modenhet og spesielt tjenesteorientering og smidig metodikk. Benyttet innenfor integrasjon gir det vår plattform for digital forretning. Tiden for lange og store prosjekter er forbi – nå snakker vi om kontinuerlig forbedring gjennom korte iterasjoner, «fail fast» og «minimum viable product».
Communicate har jobbet med fagområdet integrasjon så lenge mellomvareteknologi har eksistert på det norske markedet. Integrasjon er, og har alltid vært, vårt kjerneområde. Når det nå er i ferd med å bli alles kjerneområde, benytter vi anledningen til å belyse denne reisen, og vår posisjon i et spennende marked.
Reisen begynte med tradisjonelle «broker» systemer for «Electronic Data Interchange». «EDI or die!» som det stolt ble sagt blant våre fagfolk. Teknisk sett dreide det allerede den gangen om å utveksle data elektronisk; data transport fra A til B. Mye av utviklerens jobb lå i dataformatet, som typisk ikke var felles for avsender og mottaker.
Et tidlig forsøk på standardisering i bransjen, resulterte i EDIFACT formatet. Dette dekket bl.a. vanlige «Enterprise Resource Planning» (ERP) integrasjonsmeldinger, så som priskatalog, ordre, ordrebekreftelse, faktura osv. Både internt i den enkelte bedrift, i form av «Application to Application» (A2A), men også mellom selskaper «Business to business» (B2B). Det var en kompleks materie på tvers av bransjer, forretningsprosesser, data og teknologi. Standarden ble etter hvert så omfattende, at det ble skrevet implementasjonsveiledninger (IG) for hvert format innen standarden, i et forsøk på å få aktørene til å bruke standarden på standard vis. Den gangen jobbet vi med Axway Amtrix og etter hvert XiB.
Selv om løsningene vi leverte til våre kunder var av teknisk karakter, så har problemstillingen vi har løst for våre kunder alltid vært rotfestet i forretningsmessige behov. Verdikjeden og de underliggende forretningsprosessene utfordret de tradisjonelle forretningsdomene silo’ene, og involverte fler enn et IT system. For å kunne understøtte verdiskapning i utvikling av forretningsprosessene, måtte vi forstå prosessene og legge til rette for at systemer som ikke var laget for å samarbeide, allikevel kunne understøtte en felles prosess – også i den utvidede virksomhet, med kunder, leverandører og partnere.
Så kom BizTalk fra Microsoft, og Java verktøy fra det som den gang var Sun (før det ble kjøpt opp av Oracle). Vi jobbet fortsatt med meldingsorienterte løsninger, datakommunikasjon og format transformasjon, men med de nye mellomvareplattformene kom også prosess støtte, regelmotor, «Business Activity Monitoring». Vi fikk fokus på tjenester, og de første kommunikasjonsprotokollene som understøttet den nye retningen av standardisering; web-tjenester og «SOAP».
Arkitekturutviklingen innenfor integrasjon fulgte i takt med utvikling for applikasjonsutvikling. Fra monolitter til lagdeling, objektorientering, løsere koblede funksjoner, separat data lag, lag for «business logic/prosess», og «Application Programming Interface» som eksponerte funksjonalitet og data mot brukergrensesnittet. Innen applikasjonsutvikling vokste teorien om tjenesteorientert arkitektur frem. Løse koblinger mellom veldefinerte tjenester som har en og kun en funksjon, og som på denne måten kan gjenbrukes og vedlikeholdes uten konsekvenser for den øvrige applikasjon den er del av.
Formålet var ikke lenger primært å få noe til å fungere, men det skulle også kunne videreutvikles og forvaltes over tid. Et behov som i større grad gjør seg gjeldende i takt med omfang og kompleksitet i IT porteføljen. Communicate sin tilnærming til integrasjon, har alltid vært ved bruk av mellomvare, som i praksis vil si det motsatte av «punkt til punkt». «Punkt til punkt» er der man lager hver enkelt integrasjon med isolert fokus på funksjon, uten noen helhetlig arkitektur eller kontroll på tvers av integrasjonene. Dette er mulig, og fungerer innenfor et begrenset antall applikasjoner, men blir fort uhåndterlig fra et forvaltningsperspektiv når omfanget vokser med tid. Mellomvareløsningen gir administrativ oversikt, kontroll, begrenser risiko ved endringshåndtering og øker således oppetid, kvalitet og stabilitet. Det tilfører felles funksjonalitet for overvåkning, logging, feilsøking og sikkerhet – samt felles beste praksis i implementasjon av integrasjonsløsninger.
LES OGSÅ: 5 Byggestener i en digital tjenesteplattform
Vi tok med oss teorien bak tjenesteorientert arkitektur (SOA) over til integrasjon, og det var mye fokus på å implementere «Enterprise Service Bus». Selv om teorien var god, klarte ikke bransjen å hente ut den forventede effekt. SOA var på toppen av «hype-cycle» og falt til jorden da omfanget av implementasjon ikke ble helhetlig nok til å hente ut forventet effekt. Bransjen manglet også den smidige metodikken, og omfanget før resultat ble for stort. Vi beholdt likevel troen på teorien, tok med oss prinsippene den bygger på videre i vårt arbeide, og bygget for våre kunder et fundament for fremtiden gjennom integrasjonsløsninger for datidens utfordringer.
I takt med denne utviklingen, så vi parallelt en utvikling på forvaltningssiden. Servere og kjøremiljøer ble virtualisert, som i prinsipp vil si automatisert og derigjennom effektivisert. Standardisering medførte at man ikke lenger trengte fokus på hardware som løsningsutvikler. Vi fikk VMware og HyperV, og serverne våre ble erstattet av image på felles jern. Deretter tok de store internasjonale leverandørene standardiseringen til neste nivå, og skalerte opp til det som i dag er kjent som skyen «Cloud». Felles jern for «alle» levert som «selfservice» gjennom «as a service» plattform. Denne utviklingen tok tid, og det som skjedde i kulissene var at de aktørene som hadde muskler til å gjennomføre tjenesteorientert arkitektur fullt ut, nå har bevist at teorien også holder vann i praksis.
Parallelt kom de første smarte telefonene med «touch-skjerm», som brakte med seg muligheten til å gjøre oppgaver som så langt begrenset til «desktop» verden, på et «device» man kan ha med seg i lommen. Men noen begrensninger var det selvsagt, og protokollen for web-tjenester (SOAP/XML) ble for tung, så man tok frem igjen den eldre «REST» protokollen, og erstattet XML med JSON.
Kombinasjonen av disse to teknologiske fremskrittene har resultert i at tjenesteorientert arkitektur nå er modent. Man går fra en tilnærming der et mellomvare-produkt ligger som nav i integrasjoner gjemt bak kjernesystemenes brukerflate mot forretning. Til en mellomvarearkitektur der man ved integrasjonsløsninger tilbyr en tjenesteplattform, hvor forretning nå kan implementere sine prosesser uavhengig av de enkelte kjernesystemer og datakilder i IT porteføljen. IT kan tilby forretning sin funksjonalitet og sine data «as a service», selv om de eksisterende kjernesystemene ikke ble designet med dette som formål. Gjennom denne arkitekturen og tjenesteplattformen, kan forretningen digitaliseres allerede i dag, og IT kan abstrahere sin tekniske gjeld fra forretningsbrukerne, og bygge fremtidsrettede løsninger fremfor å holde det gamle flytende.
Effekten dette gir er fleksibilitet til å endre raskt, samtidig som man bevarer kontroll, kvalitet og stabilitet. Dette løfter også opp smidig metodikk til integrasjon og forretningsutvikling, og åpner for vesentlig høyere grad av automatisering, både av forretningsprosesser, men også av utviklingsprosessen mot det vi kjenner som «Continous Integration».
