Denne klumme er et debatindlæg og er alene udtryk for forfatterens synspunkter.
Min sommerferie blev afbrudt af en workshop i London i de dage, hvor englænderne stønnede under Saharalignende temperaturer.
Jeg var afsted med en stor kunde, hvis enterprise-arkitekter – ligesom langt de fleste andre medlemmer af dette sympatiske folkefærd – er optaget af tanken om composable architecture.
Brandvarmt buzzword
Den komponerbare arkitektur er et næsten lige så varmt buzzword som en londonsk varmerekord omkring de 40 grader. Og det er med meget god grund.
Virksomheder skal håndtere forandringer i et opskruet tempo, og når software er en vital del af næsten enhver forretning, så skal vi undgå låsninger og forsinkelser.
Det fører til den API-forbundne funktionalitet i et cloud-first miljø, som er et par af hjørnestenene i den komponerbare arkitektur.
Stacken bliver et økosystem
Paradigmet er delvis i modsætning til fortidens tanke om én monolitisk løsning til det hele.
Og det er endnu mere i modsætning til at bygge alt fra bunden og køre det hjemme i eget serverrum.
Den komponerbare arkitektur peger mod, at stacken i stedet bliver et økosystem af individuelle systemer, der deler data via API’er, og hvor dekoblede services kommunikerer med hinanden.
I London erfarede jeg, at mange stadig lægger fokus på den nye app – den nye funktionalitet. Hvordan kommer vi hurtigst frem til at kunne levere noget til forretningen?
Det falder godt i tråd med en nylig Nordic IDC rapport, der dokumenterer at app-udvikling og deployment ligger nummer to på CIO’ernes radar.
Her er det den sidste del, deployment, der er væsentlig at holde sig for øje. Det er jo ofte her, problemerne opstår.
Det, at man blot efterspørger en ny app, rummer et oplagt problem, for der følger en lang hale af problemstillinger, når app’en skal være sikker, fitte i forretningsmæssig kontekst, og når data skal uniformeres, valideres og kontrolleres.
Fokus på forretningsproces
Jeg vil i stedet foreslå, at man komponerer med strikt fokus på forretningsprocesser.
Hvis den nye service eller app indgår i virksomhedens samlede order-to-cash eller procure-to-pay proces, da vil denne nye service være underlagt en række krav og præmisser. Og disse krav bliver før eller siden nødvendige at tænke ind.
Alle services skal i sidste ende hænge sammen, og data skal have konsistens. Derfor er der brug for en samlet procesmotor.
Mange af de store ERP-leverandører har netop ”byggeklodser” af funktionalitet liggende klar på hylden, fordi de også selv er blevet langt mere ”komponerbare” på indersiden.
Det er oplagt for den komponerende it-arkitekt at trække på et eller flere af disse præ-pakkede proces-tilpassede systemer, fordi de er født med dataintegritet og sikkerhed i procesmæssig kontekst.
Set fra forretningens side er de modnet til ”plug-and-play”.
Selv med mobiliseringen af al min kreative fantasi efter en god lang sommer kan jeg for øvrigt ikke se, at man kan opbygge sit eget fulde ERP-miljø med isolerede microservices.
Klummer er læsernes platform på Computerworld til at fortælle de bedste historier, og samtidig er det vores meget populære og meget læste forum for videndeling.
Har du en god historie, eller har du specialviden, som du synes trænger til at blive delt?
Læs vores klumme-guidelines og send os din tekst, så kontakter vi dig - måske bliver du en del af vores hurtigt voksende korps af klummeskribenter.