iBridge 4.0

iBridge som lösning har varit i ständig utveckling sedan slutet av 1990-talet. Lösningens namn har ändrats ett par gånger, i takt med att användningsfokus har förändrats – från ERP-styrd dokumentproduktion med eDoc , till bearbetning och konvertering av filer och elektroniska dokument med Xmap , och över till en mer generell ”brygga” mellan system och företag med iBridge .

Vi har dock alltid haft samma underliggande idé: iBridge ska vara ett verktyg som kan användas av konsulter och utvecklare på iSYS – i våra egna projekt – men även av superanvändare och teknisk personal hos våra kunder. Utvecklingen av lösningen kommer därför naturligtvis att vara både kund- och projektdriven – i den meningen att den utökas för att lösa verkliga problem, snarare än att vi bygger in ”bra-att-ha”-funktionalitet som aldrig kommer att användas i praktiken.

Den underliggande tekniska plattformen har också förändrats, men även här i linje med det faktiska behovet – både för vår egen drift av lösningen, och för de krav och behov som rapporterats av våra kunder. I praktiken har detta inneburit att iBridge i sin helhet har körts på Microsoft Windows under hela sin livslängd. Det betyder inte att iBridge har varit statiskt – det har ständigt utvecklats tillsammans med plattformen – från att vara en 32-bitarstjänst på fysiska servrar, till idag – där det till stor del är en eller flera 64-bitarstjänster på virtuella maskiner.

Men utvecklingen stannar förstås inte där, då fokus numera till stor del ligger på molnlösningar och containerapplikationer. Det är i princip fullt möjligt att köra dagens iBridge i sådana miljöer. I praktiken väljer vi dock fortfarande att bryta med den kontinuerliga utvecklingsväg vi har haft de senaste 25 åren, ta några steg tillbaka och tänka nytt – fokusera på enkelhet och flexibilitet, samtidigt som vi uppgraderar och effektiviserar den tekniska plattformen.

De verkligt stora fördelarna med containerapplikationer uppnås när de implementeras så att varje "container" enkelt kan uppgraderas utan att störa verksamheten, och dessutom innehåller så lite statisk information som möjligt över tid – och endast fungerar med tydligt definierade och avgränsade uppgifter. 

En annan viktig faktor, och återigen en som är lättare att utnyttja när man använder containerapplikationer, är manuell och automatisk skalning av en lösning efter behov. iBridge har länge haft stöd för att köra flera uppgifter parallellt, och även för att ha flera separata instanser som har kunnat kommunicera och arbeta tillsammans. En sak har dock hållit oss tillbaka lite här: Beroendet av delade resurser – i praktiken en gemensam databas och delade filer.

Vi överger inte lagring av data i databaser, eftersom detta naturligtvis är en viktig del av ett system som iBridge, men vi planerar för att de enskilda modulerna ska kunna fungera autonomt – utan att direkt dela resurser med de andra, såvida det inte finns ett uttryckligt behov av detta. Ett enkelt exempel är att vi ska kunna importera ett elektroniskt dokument i ett format, och sedan konvertera det till ett annat format – utan mellanlagring. Om det under en sådan process finns ett behov av att även lagra data i en databas, gör vi detta, men då som en separat aktivitet – inte som en integrerad del av hela processen.

I praktiken innebär detta att iBridge som produkt går från att vara en relativt monolitisk tjänst till ett ”moln” av mikrotjänster som kommunicerar med varandra – antingen via ett kösystem eller via definierade API:er. Dessa tjänster kan samlokaliseras, och vi planerar också ett gemensamt system ovanpå – så kallad ”orkestrering” – så att vi kan skapa arbetsflöden likt dagens iBridge. Här tittar vi på Spring Cloud Data Flow som en möjlig lösning för att knyta ihop allt. Arkitekturen med mikrotjänster gör det dock också mycket enklare för både oss själva och för externa integratörer att använda delar av lösningen direkt – till exempel genom att anropa moduler från externa system för att bearbeta filer eller producera dokument.

Den lösa kopplingen mellan de enskilda tjänsterna, och den betydligt mindre delningen av resurser, innebär också att systemet som helhet kan skalas upp under perioder då detta behövs – tänk till exempel på att hantera ordrar på dagar som Black Friday.

Sammantaget ser vi fram emot att erbjuda gamla och nya kunder ett system som är framtidsinriktat, men som också kommer att kännas igen av befintliga användare!