Lav en løstkoblet integrationsarkitektur

Yes, ud med de punkt-til-punkt integrationer – du skal afkoble dine systemer. Et opråb til dig med et stigende integrationsbehov.

integrationarchitechture

Dagens integrationsarkitektur i virkligheden

Virksomheder har omsidder fået fuldstændig styr på netværk- og serverinfrastruktur, men nu viser der sig en ny udfordring: Systemkaos – med hårde og skjulte afhængigheder mellem deres IT-systemer.

Mange IT-chefer er frustreret over dårlig performance på deres IT-projekter og omkostningerne ved at supportere de eksisterende løsninger. Dertil er frygten for at nøglemedarbejderen forsvinder en dag eller at det forretningskrav opstår, som får korthuset til at vælte.

Min erfaring siger, at den gennemsnitlige større danske virksomhed, gennem stigende brug af IT, i dag har fået et ”broget” systemlandskab(se tænkt eksempel nedenfor), hvor der er skabt afhængigheder på kryds og tværs mellem de interne systemer.

2013-04-08_1559

Derudover, i takt med at IT-kravene stiger og du indser at din virksomhed nu også indgår i den web-matric-kultur, hvor brugere, kunder, leverandører, medarbejdere forventer informationer og respons med det samme, så er det tilmed ikke kun i ”eget hjem”, at systemerne skal hænge sammen. Derfor har du allerede været nødt til eller du er nu nødt til at integrere dine egne systemer med dine forretningspartnere, myndigheder og lignende, og pludselig er nettet af forbundne systemer langt større end tidligere med afhængigheder på kryds og tværs.

2013-04-08_1600

Jeg kalder denne integrationsarkitektur for spaghetti-integration og jeg gætter på, at næsten alle større danske virksomheder enten har været dér eller stadigvæk er det. Spaghetti-infrastruktur har nogle klare fordele:

  1. Det er hurtigt at starte op.
  2. Det er simpelt og overskueligt med meget få spagetthier.

Men! – (Min pointe er nok gættet), tendensen er, at der sættes mange, mange flere integrationer op, end der forsvinder, og så bliver spagettiarkitekturen et skrøbeligt fundament for din IT-Infrastuktur. Inden længe er din virksomhed er blevet tung og langsom, og det er målbart på følgende:

  • Dårlige performance på udvikling. Forestil dig vore pirreligt det er, blot at ændre et komma i grænsesnittet(f.eks. at ændre et felt) på dine systemer, når der er så mange afhængiheder til mange forskellige systemer. Der er to muligheder. Enten tager det afsindig lang tid og lykkedes, ellers tager det afsindig lang tid og lykkdes ikke. 
  • Vedligehold. Kompleksitet i sig selv giver mere vedligehold, fordi det er svære at gennemskue fejl og rette i det eksisterende.
  •  Nyt IT-system. Det skrækkelige, dyre forløb med at etablere alle de integrationer, der i dag servicerer dine systemer og som din forretning er dybt afhængig af, hvad sker der, når vi introducerer nye systemer og erstatter gamle systemer med nye? Jeps, du bliver nødt til at gennemgå analyse og udvikling for hver eneste integration igen.

Sådan laver man integration

Du skal behandle din integration som dit kæreste eje, så du holder din udviklingsperformance højt, og samtidig forbliver ”kompatibel” og fleksibel i den verden, din virksomhed agerer i. Det gør du ved at implementere en løstkoblet integrationsarkitektur. Du må ikke have direkte afhængigheder mellem systemer – i stedet anvender du interne formater, hvis eneste formål er at beskrive data udfra et forretningsmæssigt synspunkt – også kendt som Canonical Data Model.

Essensen er at definere et format som beskriver et forretningsdokument – eksempelvis en ordre, lagerreservation, faktura, kundeoprettelse, osv. Du skal bruge et internt format(IFormat) for hver forretningsbesked, du udveksler i dag. IFormatet skal så indeholde en fællesmængde af de forretningsinformationer, der giver mening på denne besked for din virksomhed.  Et IFormat har intet med teknik at gøre, det handler blot om at navngive en besked og definere hvilke informationer, der kan være i den.

2013-04-08_1600_001

Med dine IFormater i hånden kan du etablere mapninger i mellem eksterne og interne systemers formater til IFormaterne.

2013-04-09_0812

Systemerne kender altså kun til det interne format, men ved intet om slut-systemet i øvrigt. Hvis der i morgen kommer en ny kunde, som skal udveksle ordrer med din virksomhed, så er det blot et spørgsmål om at mappe denne kunde til dit allerede eksisterende IFormat. Eller hvis du ønsker at flytte ordrer fra dit forretningssystem til dit økonomisystem: Én mapning!

Det har en række fordele:

  • Hvis du ændrer i dit systems grænsesnit, så skal du kun tilpasse én mapning – nemlig den til IFormatet.
  • Hvis du har brug for at et andet system modtager ordrer, så skal du kun oprette en mapning.
  • Hvis du har flere modtagere af et dokument, så vil du få langt færre mapninger, dvs. en kortere udviklingstid.
  • Alle behøver ikke vide alt. Med det mener jeg, at du kan have en medarbejder til at mappe kunder ind til IFormatet for ordrer, uden at denne medarbejder vide noget om den i øvrigt skal vide noget om det komplicerede format ind til mainfraimen eller den typesvage(god forbid) webservice ind til logistiksystemet.

Jeg håber, du nu tænker på løse koblinger, hvis dit integrationsbehov har vokseværk! 🙂

1 kommentar »

  1. Udemærket artikel..

    Dog vil jeg påpege at i større systemer er det ikke altid blot at gøre dette, når mange forskellige typer af teknologi indgår (for slet ikke at tale om “politiske” beslutninger). Det betyder dog ikke at man internt i et system kan integrere med CDM.

Skriv et svar

Udfyld dine oplysninger nedenfor eller klik på et ikon for at logge ind:

WordPress.com Logo

Du kommenterer med din WordPress.com konto. Log Out / Skift )

Twitter picture

Du kommenterer med din Twitter konto. Log Out / Skift )

Facebook photo

Du kommenterer med din Facebook konto. Log Out / Skift )

Google+ photo

Du kommenterer med din Google+ konto. Log Out / Skift )

Connecting to %s