iBridge 4.0

iBridge som løsning har vært i konstant utvikling siden slutten av 1990-tallet. Navnet på løsningen har blitt endret ved ett par tilfeller, i tråd med at fokus for bruk har endret seg - fra ERP-styrt dokumentproduksjon med eDoc, til prosessering og konvertering av filer og elektroniske dokumenter med Xmap, og over til en mer generell “bro” mellom systemer og bedrifter med iBridge.

Men, vi har hele tiden hatt den samme underliggende tanken: iBridge skal være et verktøy som skal kunne brukes av konsulenter og utviklere hos iSYS - i våre egne prosjekter - men også av superbrukere og teknisk personell hos våre kunder. Utvikling av løsningen vil dermed naturlig være både kunde- og prosjektstyrt - i den forstand at den utvides til å løse reelle problemstillinger, fremfor at vi bygger inn “kjekt-å-ha”-funksjonalitet som i praksis aldri vil bli benyttet.

Den underliggende tekniske plattformen har også endret seg, men også her i tråd med det faktiske behovet - både til egen drifting av løsningen, og til de krav og behov som meldes inn fra våre kunder. I praksis har dette betydd at iBridge i sin helhet har kjørt på Microsoft Windows gjennom hele sin levetid. Det betyr ikke at iBridge har vært statisk - den har hele tiden utviklet seg sammen med plattformen - fra å være en 32-bits-tjeneste på fysiske servere, frem til i dag - hvor det i stor grad er snakk om en eller flere 64-bits-tjenester på virtuelle maskiner.

Men, utviklingen stopper selvfølgelig ikke der, da fokus i våre dager i stor grad er på skyløsninger og container-applikasjoner. Det er i prinsippet fullt mulig å kjøre dagens iBridge i slike miljøer. Men, i praksis velger vi likevel å bryte med den kontinuerlige utviklingsbanen vi har hatt de siste 25 årene, ta noen skritt tilbake, og tenke nytt - fokusere på enkelhet og fleksibilitet, samtidig som vi oppgraderer og strømlinjer den tekniske plattformen.

De virkelig store gevinstene med container-applikasjoner oppnås når disse implementeres slik at hver “container” enkelt kan oppgraderes uten at driften forstyrres, og også i så liten grad som mulig innehar statisk informasjon over tid - og kun arbeider med klart definerte og avgrensede oppgaver. 

En annen viktig faktor, og igjen en som er enklere å utnytte ved bruk av container-applikasjoner, er manuell og automatisk skalering av en løsning i takt med behov. iBridge har lenge hatt støtte for å kjøre både flere oppgaver i parallell, og også ha flere separate instanser som har kunne kommunisere og jobbe sammen. Men, én ting har holdt oss litt tilbake her: Avhengighet av delte ressurser - i praksis en felles database og delte filer.

Vi går ikke bort fra lagring av data i databaser, da dette selvfølgelig er en viktig del av et system som iBridge, men vi legger opp til at de enkelte modulene skal kunne fungere autonomt - uten å direkte dele ressurser med de andre, såfremt det ikke er eksplisitt behov for dette. Et enkelt eksempel er at vi skal kunne importere et elektronisk dokument på ett format, og så konvertere det til et annet format - uten mellomlagring. Hvis det i løpet av en slik prosess blir behov for å lagre dataene også i en database, så gjør vi dette, men da som en separat aktivitet - ikke som en integrert del av hele prosessen.

I praksis betyr dette at iBridge som produkt går fra å være en forholdsvis monolittisk tjeneste, til en “sky” av mikrotjenester som snakker sammen - enten via et køsystem, eller via definerte APIer. Disse tjenestene kan samlokaliseres, og vi legger også opp til et felles system på toppen - såkalt “orchestration” - slik at vi kan lage arbeidsflyter som i dagens iBridge. Vi ser her på Spring Cloud Data Flow som én mulig løsning for å binde det hele sammen. Men, arkitekturen med mikrotjenester gjør det også langt enklere både for oss selv, og for eksterne integratorer, å bruke deler av løsningen direkte - f.eks ved å kalle moduler fra eksterne systemer for å prosessere filer eller produsere dokumenter.

Den løse knytningen mellom enkelttjenestene, og langt mindre deling av ressurser, gjør også at systemet som hele kan skaleres i perioder hvor det er behov for dette - tenk f.eks prosessering av ordre på dager som Black Friday.

Alt i alt ser vi frem til å tilby gamle og nye kunder et system rettet mot fremtiden, men som også vil være gjenkjennelig for eksisterende brukere!