Blijf op de hoogte!
Bart den Dulk
Een veel gehoord adagium daarbij is dat er een scheiding is van de ‘Know’ en de ‘Flow’. Met andere woorden, de logistiek van de bedrijfsactiviteiten leg je vast in processchema’s en de kennis van de bedrijfsactiviteiten leg je vast in bedrijfsregels. Echter, als je kijkt wat organiseren in essentie betekent dan kun je stellen dat elke vorm van organisatie begint met het maken van een afspraak tussen 2 mensen en vervolgens handelen conform die afspraak of handelen zodra de afspraak wordt geschonden. Met andere woorden, het meest elementaire onderdeel van een organisatie is de afspraak tussen 2 actoren.
Daarnaast hebben wij binnen ArchiXL de overtuiging dat architectuur vooral betekent dat je kennis over de inrichting van de organisatie en de bijbehorende informatievoorziening vastlegt en toepast bij besluitvorming. Als je die twee uitgangspunten combineert, dan kan het niet anders dat bedrijfsregels de basis vormen voor de architectuur. Een wijziging in bedrijfsregels betekent daarmee ook een wijziging in de architectuur. Ik wil dit graag met een klein experiment aantonen.
Als je de volgende bedrijfsregel neemt, dan kun je daar een aantal architectuur concepten uit destilleren. Ik maak hierbij gebruik van een bedrijfsregel die is opgesteld op basis van Rulespeak. Dat is een natuurlijke taal die kan worden gebruikt voor het vastleggen van bedrijfsregels.
“Een geldopvraging voor een rekening door een klant mag alleen uitgevoerd worden als de rekening actief is”
Allereerst kun je hieruit een aantal objecten destilleren: geldopvraging, rekening, klant. Daarnaast is er sprake van een status van de rekening (actief of niet actief). Ook kun je al snel de objecten classificeren:
Direct wordt duidelijk dat er een relatie is tussen de taak of handeling en de processen binnen een organisatie. Deze regel is zeer waarschijnlijk onderdeel van een (eenvoudig) klantproces waarbij er sprake is van het opnemen van geld door een klant. Hierbij zullen een aantal taken/handelingen worden verricht en beslissingen worden genomen. Ook is er sprake van een gegeven namelijk de status van de rekening. Eigenlijk is dit een attribuut van het gegevensobject rekening. De bedrijfsregel die wordt toegepast op de taak en een resultaat oplevert in relatie tot de klant en zijn rekening (de context) is feitelijk een beperking die op de taak wordt gelegd.
Een mogelijke visualisatie is dan:
Een tweede bedrijfsregel kan zijn:
“een geldafgifte door de bank is alleen mogelijk als het saldo op rekening toereikend is opgevraagd bedrag”
In dit geval zijn de objecten als volgt te classificeren:
De combinatie van beide regels laat meteen zien dat er sprake is van een proces met meerdere stappen. De verleiding is groot om meteen een doorvertaling te maken naar de applicatielaag en mogelijk zelfs de technologische laag maar dat gaat voor nu te ver.
Bij het implementeren van bedrijfsregels kan er gekozen worden voor de wijze waarop ze geïmplementeerd worden. Dit kan in een systeem waarbij in toenemende mate gebruik wordt gemaakt van rule engines. Dit is echter niet noodzakelijk en soms ook gewoonweg niet mogelijk. Op het moment dat er sprake is van een criteria die door een systeem niet zijn af te leiden, dan zal een mens deze regel moeten toepassen.
Het doorvertalen van bedrijfsregels naar geïmplementeerde regels in bijvoorbeeld een rule engine is een vak apart en daar ga ik hier niet verder op in.
Voor mij is de belangrijkste conclusie dat het beschrijven van een bedrijfsarchitectuur begint met het in kaart brengen van de belangrijkste bedrijfsregels. Dit levert waardevolle informatie op voor het verder uitwerken van de architectuur. Omgekeerd zal een wijziging in de bedrijfsregels ook leiden tot een goede impact analyse.
Neem contact op met ons, we vertellen er graag meer over!
Blijf op de hoogte!
Arnhemse Bovenweg 140
3708 AH Zeist
Nederland
© ArchiXL | KvK 05084421