Løst koblede systemer og skjult koblede systemer

Løst koblede systemer og skjult koblede systemer

Afkobling af systemer er et både sundt og udbredt princip i integrationsløsninger.

Kort sagt er princippet, at hver komponent passer sit uden at kende til den sammenhæng, den indgår i. Ofte er virkeligheden dog den, at komponenten netop indgår i en sammenhæng – og prisen for den løse kobling kan blive, at sammenhængen fortoner sig.

I et forsøg på at være original vil jeg give et eksempel, der ikke er et ordrehåndteringssystem: Lad os i stedet kigge på et (fortænkt…) eksempel fra hverdagen for de hårdt prøvede frivillige i foreningslivet:

 

Træner Jürgen vil gerne arrangere en kamp. Lad os antage, at han har en modstander og en dato og nu bare mangler en bane, en dommer og at give spillerne besked. Jürgen er i øvrigt så helt utrolig heldig, at idrætsforeningen har systemer til disse tre ting.

Sagen er klar. Vi laver følgende flow:

Alt er godt, vi har tre systemer, der intet kender til hinanden.

Problemet er bare, at kaldene mellem systemerne følger et helt bestemt mønster – systemerne er reelt koblede i dette flow, men forbindelserne er gemt af vejen.

Et godt argument for løst koblede systemer er ”single responsibility”-princippet, der kort fortalt siger, at hvert system har sit eget ansvar og kun har én grund til at blive ændret – fx skal dommer-påsætter-systemet kun ændres, hvis måden at sætte dommere på ændres.

Men hvilken komponent har egentlig ansvaret for processen? Hvilken komponent skal ændres, hvis vi vil sætte en dommer på samtidig med, vi reserverer banen? Og hvordan håndterer vi, at der først må sættes spillere på, når både dommer og bane er klar?

Som det ser ud nu, har vi ikke løst koblede systemer – vi har skjult koblede systemer.

Her er Openminds’ anbefaling at gøre processen til ”first class citizen”:

I stedet for at gemme rækkefølgen af handlinger af vejen, kan vi håndtere processen i et BPM-system, ”Business Process Management”.

Her kan vi tegne processen og sætte strøm til den. Vi kan se præcist hvilke kampe, der er ved at blive planlagt, og hvor langt hver af dem er i processen.

BPM-systemets ansvar er altså selve processen. Systemet skal ikke ændres, hvis banen skal reserveres på en ny måde. Det skal det til gengæld, hvis banen først skal reserveres, når dommeren har fået besked.

Ud over at ændre rækkefølgen kan vi køre behandlinger parallelt, lave forskellige ruter baseret på indhold, håndtere fejl og lave statistik over kørte processer, men det er en helt anden historie, som vi gerne fortæller meget mere om, hvis I kan se idéen i at lade en procesmotor orkestrere jeres processer.

Seneste blogindlæg

Mød Openminds #1 – Du får mere end du be’r om

Michael Martinsen er partner hos Openminds. Han har over 15 års erfaring som arkitekt og softwareudvikler inden for alle faser af systemudvikling og er oprindeligt uddannet datamatiker.

Den mindste tid

Time to market. Det er vigtigt, det ved vi alle. Vi skal flytte forretningen, og det kræver, at de systemer, vi omgiver os med, flytter sig med samme hastighed.

Sprint Retrospective – form frem for indhold?

Den agile bevægelse har holdt sit indtog med Scrum som de facto værktøjet til at styre softwareudviklingsprocessen.