Af Søren Helsted, Principal Consultant, Architecture and Cloud
Hvordan leverer man på både robusthed og agilitet? Dette dilemma står mange it-afdelinger over for i dag, når organisationen digitaliserer. Devoteam giver sit bud på best practice integrationsarkitektur i en tid med uoverskuelige systemlandskaber.
Alle digitaliserer disse dage. Der innoveres på livet løs med digitale brugergrænseflader, apps og andet for at imødekomme krav fra kunder og borgere. Det stiller nye krav til systemlandskabet, der nu står over for et voldsomt teknologisk dilemma. På den ene side forventer forretningen agilitet for at kunne digitalisere sine ydelser. På den anden side er det også forretningskritisk, at back-end systemer kører så effektivt, robust og billigt som muligt – og med maksimal sikkerhed for at undgå tyveri og fejl.
Dilemmaet er tydeligt, når vi kigger på resultater fra Devoteams cloud-analyse 2020. Som det fremgår af nedenstående figur, består den væsentligste udfordring for danske it-afdelinger i, at integrere cloud-systemer med øvrige systemer – det være sig andre cloud-systemer eller on-premise legacy-systemer. Først længere nede på listen finder vi udfordringer som sikkerhed og stabilitet.
Undersøgelsen viser imidlertid også, at den vigtigste målsætning for it-afdelingen er at understøtte udvikling af kundevendte digitale løsninger, dvs. agilitet.
Integrationer er dét, som giver flest hovedbrud for deltagerne i Devoteams cloud-analyse.
Figur 1: De sværeste krav til sourcing og cloud.
Uoverskueligt og svært at kontrollere
Problemet er, at systemlandskabet i de fleste organisationer ikke er gearet til at imødekomme disse modstridende krav om agilitet og robusthed. Devoteams cloud-analyse viser, at den altoverskyggende sourcing-strategi er Hybrid IT og multi-cloud. I praksis er situationen som oftest den, at systemlandskabet ofte ligner nedenstående figur – et miskmask af løsninger.
Figur 2: Landskab med både on-premise og cloud-baserede systemer.
Sådanne landskaber er resultatet af udvikling over tid. Cloud er en besnærende, men også kompliceret teknologi, og mange virksomheder har givet sig i kast med cloud uden at have en egentlig strategi. I praksis vil det ofte være sådan, da der hverken er tid eller penge til at lave hele systemlandskabet om på én gang, og resultatet er ofte som vist på figuren ovenfor.
Derfor er flertallet af organisationer i dag tvunget til at operere med et systemlandskab, der ikke kun er uoverskueligt, men også svært at kontrollere, vedligeholde og videreudvikle. Når der i systemlandskabet indgår både on-premise og cloud-baserede systemer, mangedobles kompleksiteten, idet flere protokoller og adgange skal styres på forskellige platforme og hos forskellige cloud-leverandører. Ovenikøbet er disse protokoller og adgange ikke veldokumenterede, hvorfor det kræver mange ressourcer at vedligeholde og videreudvikle et sådant systemlandskab. Organisationen står således med et systemlandskab, der er uforholdsmæssigt dyrt at styre, og som samtidig er ude af stand til at levere den ønskede kombination af robusthed og agilitet.
Lagdelt med API’er: Kommunikation og konfiguration ét sted
Hvordan knækker it-afdelingen så denne kode? Hvordan moderniserer man integrationsarkitekturen, når flere cloud-baserede systemer bliver en del af it-miljøet? Målsætningen er ensartede processeser, og løsningen må være en arkitektur, hvor koblingen mellem systemer og komponenter er både løs og kontrollerbar. Baseret på Devoteams erfaringer er best practice en 3-lags deling af API’er som vist nedenfor.
Figur 3: Integrationsarkitektur med 3-lag API’er
Arkitekturen kan bruges universelt, men er især effektiv i hybride multi-cloud miljøer, hvor systemer og komponenter er spredt over datacentre og forskellige cloud-leverandører. Konfigurationen er overskuelig, fordi der kun er ét sted, al kommunikation mødes, takket være den løse kobling og den centrale API-funktion. Flytning og opgradering af systemer samt funktionalitet er nemt, da der kun skal konfigureres ét sted. Alle systemer, der bruger en funktion, tilgår funktionen via API-laget, og det er ligegyldigt, hvor og hvordan funktionaliteten er implementeret – så længe den indgåede API-kontrakt overholdes.
Modellen forklaret og Netflix som eksempel
De tre lag har selvfølgelig hver deres funktion. Det nederste lag, System, giver adgang til organisationens data. Disse systemer kan være alt fra ældre legacy-systemer til moderne SaaS-systemer, hvilket er problematisk i en traditionel arkitektur. De ældre systemer har, som regel, ikke-standardiserede grænseflader eller følger gamle standarder, hvilket gør det besværligt for de nyere systemer at integrere eller opdatere data. Men ved at benytte en integrationsplatform, der netop har som speciale at tilgå forskellige, ofte kringlede, grænseflader og udstille tilgang som et moderne standard-API, virker det. De gamle systemer fungerer i en moderne arkitektur og kan benyttes af moderne systemer uden at skulle tage specielle hensyn. Du har API-enablet dine legacy-systemer. Når de gamle systemer bliver moderniseret, ændrer du blot API-implementeringen i integrationsplatformen, og de andre systemer kan fortsætte som hidtil.
Det midterste lag er Process, som implementerer organisationens processer og arbejdsgange, oftest i en integrationsplatform, der er stærk i proces-flows. Laget benytter sig af de system-API’er, som er implementeret for at tilgå back-end-systemerne og er typisk ejet af den del af organisationen, der er ansvarlig for forretningsgange. Opdatering i dette lag sker, når processerne ændres, eller der kommer nye til. Ændringer i dette lag er som regel hyppigere end i det lavere systemlag.
Det øverste lag, Experience, har langt de fleste ændringer, fordi det er her, vi er i kontakt med brugerne. Derfor vil der ofte være versioner for hver type brugergrænseflade, f.eks. mobile apps, webklienter, IoT-enheder, etc. Laget understøtter agil udvikling af brugervendte systemer og nye digitale produkter. Når den del af organisationen, der udvikler digitale produkter, kommer med nye krav, vil det typisk betyde nye experience-API’er. Disse API’er mapper til næste lag, Process, og er i figuren implementeret via en API-management-platform. Med hensyn til sikkerhed kan gængse principper implementeres, da adgangen til API’er normalt er sikkerhedsbeskyttet og datakrypteret.
Netflix er et godt eksempel på en 3-lags deling af API’er i praksis. Du logger ind via web, eller en app, og vælger en film, hvilket foregår via Experience-laget. Informationen bliver sendt videre til Process-laget, som vil få System-laget til at hente den rette film, i den rette opløsning, og sende til Experience-laget til visning på brugerens enhed.
Løsningen skal passe til din situation
Modellen kan som nævnt bruges universelt, men der er stadig nogle forhold, kunden skal være opmærksom på. Det er f.eks. ikke alle leverandørers løsninger, der er lige egnede – det afhænger af de specifikke krav til lagene. Nogle integrationsplatforme bruger standardkomponenter til at integrere systemer med grænseflader som ftp og flade filer. Disse standardkomponenter styres ved hjælp af en konfiguration, hvor andre platforme tilbyder programmering til at integrere med mere hardcore back-end systemer. Det kommer altså an på den konkrete situation.
På samme måde er der forskel på de forskellige platformes tilgange til procesmotoren i Process-laget. Nogle har grafiske grænseflader, der gør det nemt at lave de mest almindelige processer, mens andre platforme tilbyder muligheden for at lave yderst komplicerede procesforløb med programmering.
Endelig skal du som kunde også være opmærksom på et af grundvilkårene i it-branchen, at kært – eller nyt – barn har mange navne. Leverandørerne benytter forskellige navne til deres API-komponenter, og betegnelser som API gateway, API management og integrationsplatform (iPaaS) bruges derfor lidt i flæng, men som regel omfatter de alle 3-lags deling af API’er i et eller andet omfang.
Det var vores bud på en løsning til de modstridende krav om robusthed og agilitet, som mange it-afdelinger kæmper med i disse år. En 3-lags deling af API’er giver den fornødne fleksibilitet til effektivt at kunne udvikle nye digitale produkter, uden at give køb på den underliggende driftsikkerhed. Devoteam har omfattende erfaring i at udvælge API management- og integrationsplatforme, som passer bedst til en given organisation, inklusive implementering af de tilhørende integrationer og API’er.
Hvis du er interesseret i at høre mere om vores erfaringer og forslag til best practice, er du velkommen til at kontakte Søren.