Denne klumme er et debatindlæg og er alene udtryk for forfatterens synspunkter.
For nylig optrådte jeg for en international kunde om emnet integration. Det skete som led i en udbudsrunde.
Kundens arkitekter lyste helt op, da jeg fortalte, at vi bruger GraphQL som API-arkitektur. Det fortæller noget om, hvor vigtig integrationen er blevet.
Hos en anden international kunde med en igangværende udbudsproces vægter integrationen 40 procent i kriterierne for valg af ERP-arkitektur.
Det er voldsomt, og billedet var anderledes for få år siden, hvor funktionalitet, brugervenlighed og mange andre facetter fyldte det meste.
Årsagen er klart nok, at verden er ved at lande på, at komponerbarhed, manøvredygtighed og fleksibilitet er nødvendig.
Både internt i en koncerns datalandskab men også længere ud i værdikæden.
Bæredygtighed rimer på API
Ingen tror, vi kan lægge alle æg i én kurv og så én gang for alle snøre sækken på integrations-problemstillingen.
Nej, det bliver ved. Bump i sourcing-strategier, global uro og selvfølgelig hurtig teknologisk udvikling bringer API’er og integration i fokus.
De forretningsmæssige krav til navnlig forsyningskæden flugter med voksende fokus på bæredygtighed, for vi skal hurtigt og nemt kunne sammenstykke en datastrøm til klimaregnskabet.
Transparensen skal gælde både upstream og downstream og i scope 1, 2 og 3.
Data-globaliseringen er nøglen til mere bæredygtig produktion og distribution. Også her peger pilen på API’erne.
Vækst i API-community
Sjældent har en relativt teknisk disciplin som håndtering af API’er så direkte en betydning for værdiskabelsen.
Og det kan aflæses i eksempelvis Postman-rapporten (State of the API report), som tegner et klart billede af vækst i antal, udbredelse og betydning af API’erne.
Postman baserer sig på svar fra 40.000 udviklere og kommer frem til at investeringen i API’er steg 89 procent fra 2022 til 2023, og at væksten vil fortsætte i fremtiden.
Et voksende globalt community omkring API’er bruger i stigende grad AI til udvikling og test, og stadig flere ikke-professionelle udviklere er involveret i at skabe API’er.
GraphQL på vej frem
Postman placerer i øvrigt GraphQL som den tredje mest brugte API-arkitektur. Den har overhalet SOAP og har langt op til REST. Og det er ikke irrelevant, når vi taler ERP.
ERP-systemer består pr definition af flere sammenhængende funktionalitetsområder. Lagerstyring, økonomi, HR, produktion og distribution skal udveksle data effektivt.
Traditionelt set bruger disse systemer REST-API'er eller andre dataudvekslingsprotokoller, der kan kræve flere endepunkter og resultere i over-hentning eller under-hentning af data.
GraphQL giver en mere effektiv måde at forespørge data på, så klienter kan specificere præcis, hvilke data de har brug for.
Dette er særligt nyttigt i en ERP-kontekst, hvor forskellige moduler kan have behov for tilpassede dataforespørgsler til særlige behov.
API-supermarkedet
ERP skal jo også snakke med eksempelvis CRM, e-handelsplatforme, tredjeparts analytiske værktøjer og meget mere.
Hver af disse integrationer har typisk sin egen API, hvilket fører til en ganske kompleks integration af et netværk af API’er.
Her er det en stor fordel at have et samlet forespørgselssprog, der konsoliderer flere forskellige datakilder samme sted.
Det forenkler nemlig integrationslandskabet omkring et ERP-system, at man kan handle sine API’er i et supermarked i stedet for at skulle både til bageren, slagteren og ostehandleren.
Og jeg synes altså, at det er helt relevant at tage springet fra det tekniske til det globale.
Jo bedre, hurtigere og sikrere vi integrerer, jo bedre kan vi drive forretning og skabe en bæredygtig økonomi. Jeg tror på data-globalisering!
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.