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”:
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.