Kill your managers

In de software architectuur laait van tijd tot tijd het debat op over de wenselijkheid van gecentraliseerde sturing van processen en het gevaar van “control objects” en “managing services”. De kracht van oplossingen als DNS en UDDI ligt juist in het ontbreken van een centrale regelmeester. De laatste tijd lijkt in enterprise architecturen de balans juist weer wat door te slaan naar meer en strakkere controle op de uitvoering van processen. De op allerlei terreinen aangescherpte regelgeving zal daar mede debet aan zijn. Meer controle wordt door architecten haast vanzelfsprekend vertaald in centrale componenten in de architectuur die als een spin in het web alles monitoren en niet zelden ook ongewenst gedrag uitfilteren. Service georiënteerde architecturen zijn in zeker zin een moderne poging om op enterprise niveau meer grip te krijgen op proces- en informatieflow.

De controleparadox

In het verleden zijn er verschillende technieken ingezet om een controlefunctie in de enterprise architectuur te engineeren. Een “integration broker” is feitelijk een centrale hub die het mogelijk maakt om controle uit te oefenen op het verloop van het berichtenverkeer tussen applicaties. Een workflow managementsysteem is een toepassing die een complex werkproces opdeelt in een stroom van taken die aan medewerkers worden toebedeeld. Het is niet zo moeilijk in te zien dat workflow management vereist dat er ook een informatiestroom tussen de medewerkers is. Binnen een systeem is dit geen al te prangend issue, maar zodra medewerkers verschillende systemen gebruiken om hun taken uit te voeren – en in het bijzonder als de medewerkers voor verschillende organisaties werken – is dit niet per definitie triviaal. De ervaringen met technieken als integration brokers en workflow management systemen zijn opmerkelijk gelijksoortig: het werkt heel aardig voor de eenvoudige, voorspelbare, sterk gestandaardiseerde processen; maar zodra het wat minder eenvoudig wordt, dan worden de beperkingen al heel snel tamelijk knellend. Er is een single point of control – met alle nadelen vandien – dat zich doorgaans uiterst rigide gedraagt. De gebruikers zien zich dan al gauw gedwongen om buiten het systeem om wegen te vinden om gewoon hun werk te doen. En met het oprukken van informatietechnologie in steeds complexere processen vraagt dit om een slimmere benadering.

Sommige organisaties realiseren zich dit terdege. Er is nog geen consensus over de vraag hoe dit probleem te tackelen. Industrialisten zijn geneigd om de producten en de processen zo te ontwerpen dan de variatie minimaal is en de verwerking mede daardoor tot in de kleinste details voorspelbaar wordt. De huidige six sigma golf zal niet vreemd zijn aan de populariteit van deze benadering. Anderen stellen juist dat je je met je procesmodel zou moeten richten op die 80% van de gevallen die je gemakkelijk kunt “vangen”. De uitzonderingen zouden dan gewoon moeten “uitvallen” en als handwerk afgehandeld moeten blijven worden.

Het grappige is dat het juist voor die zaken die niet zijn voorzien, of in elk geval niet passen in een standaard verwerking, controle op de uitvoering op z'n plaats is. Ga maar na. Vanuit het oogpunt van risico management moeten er controlemechanismen worden ontwikkeld die waarborgen dat er altijd inzicht is in de huidige staat van de risico's en die het verhinderen dat er onbezonnen risico's worden genomen. “Societé Generale” en “Barclays” dienen als afschrikwekkend voorbeeld van wat er mis kan gaan als deze mechanismen falen. Vanuit het oogpunt van compliancy moeten er corporate governance mechanismen ontwikkeld worden die de betrouwbaarheid van de informatievoorziening van het bedrijf moeten garanderen. De namen “Enron”, “Worldcom” en “US Food Service” zijn onlosmakelijk verbonden met even zovele boekhoudschandalen. In alle gevallen waren de betrokkenen betrekkelijk eenvoudig in staat om de bekende procedures te omzeilen. Je zou je kunnen afvragen of de wedloop tussen de controleurs en de overtreders met gecentraliseerde controlemechanismes wel te winnen valt. Is het in de praktijk niet zo dat met name goedwillenden er last van hebben en kwaadwillenden er vaak al te gemakkelijk omheen blijken te kunnen? En wie controleert eigenlijk de controleurs?

De uitweg uit de paradox

“Kill your Managers” is een bekend architectuurpatroon dat mogelijk kan helpen bij het vinden van een uitweg uit het dilemma. Het is onder de naam “Blackboard pattern” al 1996 beschreven door Frank Buschmann et al in “A System of Patterns”. Het komt er in de kern op neer dat je ervoor moet zorgen dat relevante informatie die in het proces ontstaat altijd op een geeigende plek wordt gepubliceerd. Vervolgens moet je erover nadenken wie er op welk moment toegang behoort te hebben tot die informatie. Tenslotte kun je in een apart proces deze informatie verwerken. Die verwerking kan een mix van geautomatiseerde en handmatige controles zijn. Daarbij is het goed voorstelbaar dat de controles niet altijd voorspelbaar hoeven te zijn. Het onvoorspelbare karakter van controles maakt het voor kwaadwillenden immers een stuk lastiger om ze te omzeilen. Inderdaad: het inbouwen van een zekere mate van onzekerheid in het proces maakt de effectiviteit van de controle sterker en juist niet zwakker. En voor het hoofdproces is het een verademing dat goedwillende medewerkers niet meer te pas en te onpas lastig gevallen worden door managers die zich zonder al te veel kennis van zaken met de uitvoering willen bemoeien.

“Kill your Managers” is een architectuurpatroon dat nog niet zo vaak wordt toegepast bij het ontwerpen van complexe processen. Dat is jammer. Het is een effectieve manier om de concerns “uitvoering” en “controle op de uitvoering” te scheiden. Het is bovendien uitermate schaalbaar en flexibel. Misschien wordt het alleen nog niet altijd goed begrepen wat de kracht van dit patroon is. Zie het als “op het proces zitten” in plaats van “in het proces”. Een goede manager zit niet “ín”, maar “óp” het proces. Dat kan iedereen toch begrijpen?

Het is niet altijd helemaal te voorkomen om een manager in enigerlei vorm in een architectuur op te nemen. Er kunnen hele goede redenen zijn om bepaalde zekerheden af te dwingen. Een access control manager is een typisch voorbeeld. In die gevallen werkt een asynchrone controle nou eenmaal niet. Het principe “kill your managers” moet dus niet al te dogmatisch toegepast worden. Maar onthoud dat als je architectuur echt niet zonder een manager kan, dat dan het tweede deel van de hoofdregel in werking gaat, namelijk: “if you definitely need your manager, be sure to keep him as stupid as possible”. Want niets is zo vervelend als een manager die slimmer probeert te zijn dan zijn medewerkers.

In deze paradox wordt algemeen aanvaarde best practices ter discussie gesteld. Het is de 4^de in een reeks 'uncommon sense' die op dit weblog gepubliceerd zal worden.