CRC sessies zijn een perfecte tool voor het maken van bedrijfsmodellen maar zijn tot mijn verbazing nog steeds relatief onbekend.
Daarom een korte introductie: waarom zijn CRC sessies zinvol? hoe doe je dat dan? wat leveren ze op?
Waarom zijn CRC sessies zinvol?
Om een goed model te krijgen van het business domein is het nodig dit model tot stand te laten komen met zoveel mogelijk input, maar belangrijker nog: met zoveel mogelijk betrokkenheid van de business deskundigen. Niet alleen omdat op die manier de betrokkenheid (buy-in) van de business groter is (zeker niet onbelangrijk en vaak onvoldoende of zelfs helemaal niet meegenomen) maar ook om de kwaliteit van de modellen zo goed mogelijk te krijgen.
Software engineers hebben vaak geen hoge pet op van de vaardigheid van business domein kenners om dat domein uit te leggen. Ze denken al snel dat een interview en een rapportje voldoende zijn om hun bovenmenselijke vermogen tot begrip te voeden en daar een compleet domein model uit te destilleren. Per slot van rekening is het begrijpen en in kaart brengen van veel verschillende domeinen hun vak!
Aan die houding klopt heel veel niet. Ook iets wél trouwens! In de software engineering is de noodzaak om zaken expliciet te krijgen natuurlijk altijd nijpend geweest. Daarom is het eigenlijk vooral in de software-engineering dat modelleertechnieken zijn ontwikkeld. Maar daarmee moeten we nog niet de vergissing maken dat we beter in staat zijn de business te begrijpen dan de business zélf. Zoals we zouden moeten weten is het voor experts helemaal niet makkelijk om hun kennis expliciet te verwoorden (expert kennis is “tacit knowledge”). Maar maak niet de fout te concluderen dat ze er dus eigenlijk weinig van begrijpen!
Zie hiervoor ook mijn artikel over intelligentie: Business Intelligence: een andere definitie.
Ons probleem (mij even verplaatsend in de software engineer) is dat wij onvoldoende in staat zijn geweest, al decennia lang, de manier waarop een business persoon de wereld bekijkt, te faciliteren. Wij (architecten) leven in een wereld waarin alles expliciet is, tot op de punten en komma’s, maar dat is voor “gewone” mensen heel anders. Wij hebben als het ware een disfunctioneel wereldbeeld gekregen, en het ergste is dat we er ons niet eens van bewust zijn! Het zijn “zij” die niet weten wat ze willen, die niet snappen wat echt belangrijk is, die voortdurend zwalken. “Zij” zijn lastig!
Er is grote behoefte aan technieken die zowel “ons” als “hun” helpen met elkaar te praten. Elkaars taal spreken. Een hulpmiddel voor verbinding.
En dat is nu precies waar we CRC sessies voor kunnen gebruiken. De speelse werkvorm helpt om het ijs te breken, en is zo ingericht dat geen van de partijen in een oneerlijk voordelige (of nadelige) positie zit. De vorm daagt op een neutrale manier experts uit hun kennis vorm te geven, door die kennis tot leven te laten komen. En de vorm waarin die kennis tot leven komt is een verhaal.
Hoe doe je CRC sessies?
Het is belangrijk dat we ons realiseren dat CRC sessies in principe door en met business domein experts gedaan worden. De resultaten worden opgepakt door software engineers of business analisten, maar het is niet nodig dat deze bij de sessies zélf aanwezig zijn. Het kán echter wel, en het kan ook wel degelijk zinvol zijn om dat wel te doen om het wederzijdse begrip te voeden. Maar de sessie zou ook gedaan kunnen worden door een ervaren CRC sessie-facilitator (ervaring is echter wel van groot belang, juist omdat deze techniek nog relatief onbekend is en zeker in het begin een aantal valkuilen vermeden dienen te worden) en verder alleen maar mensen uit de business.
Er is een maximale groepsgrootte. In de praktijk varieert dit maar ik hou een maximale grootte van 8 man aan. Iedereen krijgt een stapeltje papier of karton dat er als volgt uit ziet:
Aan de linkerzijde is een lijst van Responsibilities (de “R” in CRC).
Aan de rechterzijde is een lijst van Collaborators (de laatste “C” van CRC).
Bovenin komt de naam van het concept/object te staan, zijn Class (de eerste “C” van CRC).
Vaak maak ik ook nog gebruik van een balletje (jongleerballen zijn heel geschikt!), of van een “talking stick”; eigenlijk een hulpmiddel om structuur aan te brengen: alleen de persoon met een balletje of the “talking stick” mag praten. Maar ik geef aan het begin van de sessie het balletje ook een lading: het is belangrijk om dat balletje zo snel mogelijk weer kwijt te raken! Het is als het ware een hete aardappel waar je je aan brandt als je het te lang in je mond (handen) houdt.
Het uitvoeren gaat door een stukje bedrijfsproces of gebeurtenissen in de werkelijke wereld op te pakken en dit na te spelen. Iedereen zit met zijn stapeltje (nog blanco) kaarten, en het spelen van het stukje bedrijfsproces is nu als het ware de hete aardappel: wie denkt een object te kunnen bedenken dat hier iets in kan betekenen?
In het begin is het een beetje aftasten, maar dat is niet erg: de structuur van de oplossing komt gaandeweg tot stand. Daarvoor is de ervaring van de facilitator nodig: die weet dat een exploratieve wijze van stukjes bedrijfsproces uitspelen het beste resultaat oplevert.
Wat leveren CRC sessies op?
Het resultaat van één of meerdere CRC sessies is een bedrijfsmodel, ook wel domeinmodel genoemd. Maar dan wel eentje waar meer in zit dan alleen maar de structuur van het business domein. Doordat we namelijk de verantwoordelijkheden van de deelnemende objecten expliciet hebben benoemd hebben we ook de dynamiek, het gedrag, van het systeem beschreven. En wel zodanig dat we al een heel eind zijn gekomen in de richting van een implementatiemodel, geschikt om uit te werken in een programmeertaal als Java of C#.
De kaarten kunnen rechtstreeks vertaald worden naar zogenaamde “class stubs” van zogenaamde POJO’s (Java) of POCO’s (C#). Dat zijn de classes, en members van die classes. De lijst van verantwoordelijkheden komt terug in de interface van de class als methodes. De lijst met collaborators komt terug als associations, waarschijnlijk member variabelen die als “slots” dienen om de association in te implementeren.
De uitgespeelde CRC sessies kunnen nog eens opnieuw gespeeld worden ter validatie. Een nuttige aanpak is de sessies in unit tests op te schrijven (met de verwachte uitkomsten).
Er is een gedeeltelijke overlap met de technieken zoals ik die beschreven heb over exploratory modelling.
