1. Start med forretningshændelsen
Forestil dig, at en kunde afgiver en ordre. E-handels- eller CRM-systemet registrerer kunden og ordren. ERP kan overtage den økonomiske og logistiske behandling. Et lagerstyringssystem kan reservere og plukke varen. Et transportsystem kan planlægge forsendelsen. Dataplatformen modtager senere status til rapportering.
Det afgørende er, at hvert system har et defineret ansvar. Når to systemer begge tror, de er den autoritative kilde til samme felt, opstår konflikter.
2. Fem lag gør landskabet lettere at forstå
3. System of record og datakopier
Et system of record er den autoritative kilde til en bestemt type data. Det betyder ikke nødvendigvis, at data kun findes ét sted. Kundeoplysninger kan eksempelvis kopieres til CRM, ERP, support og analytics, men organisationen bør stadig vide, hvor den autoritative version ændres.
Afledte data – som KPI'er, forecasts og aggregeringer – kan have andre ejere end de oprindelige transaktioner.
4. Integration er en forretningsaftale forklædt som teknik
En integration skal definere mere end endpoint og filformat. Hvem starter overførslen? Hvad betyder “opdateret”? Hvad sker der ved dubletter? Kan en besked behandles to gange? Hvilket system retter fejlen? Hvor kan man se, om data sidder fast?
Disse spørgsmål er grunden til, at integrationsarkitektur også handler om proces- og dataansvar.
5. Fælles tjenester bliver kritiske afhængigheder
Identitet, DNS, netværk, certifikater, integrationsplatforme og cloud-konti bruges ofte af mange applikationer. Når en fælles tjeneste svigter, kan konsekvensen derfor være større end dens egen størrelse antyder.
6. Landskabet ændrer sig hele tiden
Systemer bliver opgraderet, fusioneret, udfaset og erstattet. En god IT-arkitektur er derfor ikke et engangsdiagram. Den er en løbende beskrivelse af ansvar, interfaces, data, risici og planlagte ændringer.