Domene API-er i Møller Digital

Domene API-er i Møller Digital

For en tid tilbake satt vi ned en arbeidsgruppe for å få bedre kontroll på integrasjonsarkitekturen i Møller Digital. Når antall systemer, integrasjoner og avhengigheter vokser, blir det fort krevende å bevare oversikt, eierskap og enhetlige prinsipper. Viktige forslag fra arbeidsgruppen var å introdusere domene-API-er samt å etablere et team for å forvalte dem.

Domene betyr her først og fremst informasjonsdomener — altså hvordan vi organiserer data i bolker — mer enn rene forretningsdomener (selv om de ofte henger tett sammen). Poenget er å samle operasjoner og endepunkter rundt informasjonen de handler om, slik at API-ene gjenspeiler et tydelig “hjem” for hvert informasjonsområde (domene).

I Møller Mobility Group, MMG, jobber vi med mange slike domener: ordre (både mot fabrikk og internt mellom importør, forhandler og kunde), kunder, leverandører, forhandlere, kjøretøy, leads, salgsmuligheter, tilbud og kontrakter, produkter (internt og fra fabrikk), transport — og forretningsdokumenter som skal arkiveres. Med domene-API-er får hvert av disse områdene egne, tydelige endepunkter, og vi får en mer ryddig og intuitiv struktur å integrere mot.

Domene-API-ene leveres etter et «contract first»-prinsipp. Det betyr at vi definerer OpenAPI-spesifikasjonen før vi starter implementeringen (kodeskriving og etablering av ressurser i tjenesteplattformen). På den måten får vi en tydelig og stabil kontrakt tidlig, som sendes til godkjenning hos integrasjonsteamet (som har ansvar for forvaltning og drift av kjerneintegrasjoner). Det gjør at konsumenter kan starte utvikling og testing før alt er ferdig i backend — for eksempel mot en enkel mock-implementasjon — og vi kan jobbe mer parallelt uten å blokkere hverandre.

Hvert domene-API leveres som en egen eller som en del av en cloud app. En cloud app er Møller Digital sin måte å levere digitale tjenester på: den pakker alt som trengs for å tilby en tjeneste — kode, konfigurasjon, drift og overvåkning — i én håndterbar enhet. Dette gjør det enklere for team å levere forbedringer oftere, skalere effektivt og tilpasse seg endrede behov uten å måtte “rive” i resten av landskapet.

Domene-API-ene skjuler også ende og kilde-applikasjon ved at konsumenten ikke skal trenge å vite om dataene kommer fra kjernesystemet (DMS/IMS/CRM), et OEM-system, et hyllevaresystem, en mellomlagring eller om flere applikasjoner er koblet sammen i en API-kontrakt — den skal bare forholde seg til en stabil kontrakt og et logisk domene. I praksis fungerer dette ofte som et “gateway”-endepunkt foran underliggende systemer: vi abstraherer bort systemspesifikk kompleksitet (som versjonsendringer i ERP, skriver om SOAP til REST, rare feltnavn eller tekniske begrensninger), og tilbyr et ryddigere API. Et enkelt eksempel er at konsumenten kan få feltet delaer_ID med en tilhørende MMG-spesifikk beskrivelse, selv om feltet i endesystemet egentlig heter noe kryptisk som dataAreaID og tilbyr en generisk beskrivelse av feltet.

Dette er og har vært en stor investering, men gir oss flere gevinster:

• Frikobler konsumenter fra ERP-kompleksitet og versjonsendringer: Om DMS/ERP endrer datastruktur som følge av en oppgradering, kan API-et håndtere tilpasningen uten at alle integrasjoner må bygges om.
• Dokumenterer informasjonsarkitektur på attributtnivå gjennom OpenAPI-spesifikasjoner
• Lik autentisering på tvers av systemer, like krav til logging i monitoreringsapplikasjonen samt feilhåndtering: Samme innlogging og samme type feilmeldinger uansett hvilket system som ligger bak (f.eks. alltid en tydelig “valideringsfeil” i stedet for en DMS/ERP-spesifikk eller IMS-spesifikk stack trace).
• Ett sted for forretningsregler og berikelse: API-et kan legge på informasjon som konsumenten trenger (f.eks. regne ut en status “ReadyForDelivery” basert på flere felter).
• Bytte backend uten å påvirke konsumenter: Man kan flytte “kilde” for et domene fra system A til system B uten at konsumenten endrer integrasjonen, så lenge kontrakten er den samme.
• Reduserer belastning og risiko på kjernesystemer: Trafikk kan avlastes ved at man ikke eksponerer kjernesystemer direkte til alle konsumenter.
• Caching og throttling for ytelse og stabilitet: API-et kan cache hyppige oppslag hvor data ikke endres ofte (f.eks. forhandlerdata) og begrense trafikk ved topper, så ikke underliggende system overbelastes.
• Én API-kontrakt på tvers av flere backend-systemer: Konsumenten ser “Order”-objektet, selv om deler av dataene kommer fra DMS/ERP og deler fra IMS. F.eks kan Vendor API samle informasjon fra leverandører i DMS/ERP, Innkjøpsportal (SaaS-leverandører) og eventuelle leverandører som bor i ITSM-løsningen.
• Enklere integrasjon for eksterne partnere: Partnere får et stabilt og dokumentert grensesnitt, uten å måtte forstå intern systemarkitektur.
• Orkestrering i ett kall: Ett API-kall kan hente og sette sammen data fra flere systemer, i stedet for at konsumenten må gjøre tre–fire separate kall og håndtere rekkefølge selv.