Als architect bij Be Informed ben ik vooral betrokken bij de ontwerpfase van implementatie projecten. Eén van de grootste voordelen van het Be Informed Platform in die fase is dat het een modelgedreven platform is. Met als resultaat dat je vrijwel onmiddellijk dat wat je vastlegt in de modellen ook kan tonen in een webapplicatie en bijbehorend documentatie portaal en ter plekke met je klant kan verifiëren.
Tweerichtingsverkeer
In plaats van eerst langdurig met de klant te praten over hun doelen, behoeften, eisen en wensen en het daarna pas vast te leggen in het Be Informed Platform, zitten wij dus vaak al tijdens dergelijke gesprekken te modelleren. Gewoon waar de klant bij zit. Dit leidt dan bijna vanzelfsprekend tot tweerichtingsverkeer. De klant vertelt ons niet alleen wat zij graag zouden willen zien, maar verwacht ook van ons dat we uitleggen hoe wij wat we horen vertalen in een ontwerp, hoe we rekening houden met toekomstige uitbreidingen, hoe we zorgen dat delen van de applicatie ook door andere systemen gebruikt kunnen worden, et cetera. Dat juichen wij alleen maar toe, want door dat tweerichtingsverkeer voelt de klant zich meer betrokken en dus eigenaar van de applicatie, wordt het beeld van de uiteindelijke applicatie alleen maar beter en kom je ook nog eens tot nieuwe inzichten.
Nou kan ik prima uitleggen wat de rationale achter een ontwerp is. Decompositie in business componenten; componenten hebben verantwoordelijkheid en eigenaarschap over eigen functionaliteit; ze zijn intern coherent en extern onafhankelijk; loosely coupled architectuur; dialoog tussen componenten alleen op de interface. Logisch, toch?
Voor architecten inderdaad waarschijnlijk niet meer dan logisch. Echter, wij zitten meestal met domein experts te ontwerpen. Domein experts die alles weten over hoe zij hun werk doen, wat daar allemaal bij komt kijken, waar de knelpunten zitten. Meestal hebben zij geen technische achtergrond. Als ik aan zou komen met bovenstaande uitleg en zou verwachten dat de domein experts er maar voor zorgen dat ze begrijpen waar ik het over heb, zou ik een aardige flater slaan.
De koffie metafoor
Dus: mijn taak als architect is niet alleen het opzetten van een goed ontwerp, maar ook zorgen dat mensen met een compleet andere achtergrond begrijpen wat ik doe en zich op die wijze betrokken laten voelen. Dat vergt een, soms flinke, vertaalslag. Ervaring leert mij dat het helpt om met metaforen te werken. Metaforen die dezelfde principes uitleggen, maar in een volstrekt andere context.
En ja, hoe leg je dan uit waarom je een decompositie in business componenten maakt? Aan de hand van koffie natuurlijk!
Stel je voor: bij een organisatie is iemand, laten we hem Bob noemen, in dienst wiens verantwoordelijkheid is zorgen dat bezoekers een kopje koffie krijgen wanneer zij dit willen. Bob kent alle regels met betrekking tot koffie geven aan bezoekers. Als het een eerste bezoek is, mogen ze koffie uit de dure bonenautomaat en hebben ze keuze uit alle mogelijkheden. Bij een tweede bezoek, mogen ze koffie uit de bonenautomaat, maar hebben ze een beperkte keuze. De derde keer mogen ze alleen nog koffie uit de goedkope automaat. En na de derde keer moeten de bezoekers zelf maar koffie halen.
Dan vraagt een bezoeker aan Bob om een kopje koffie. Bob weet dan welke koffie hij mag aanbieden of dat hij de bezoeker vriendelijk moet vertellen dat hij inmiddels zijn eigen koffie wel een keer mag gaan halen. En dit weet Bob voor iedere bezoeker die binnenkomt. De bezoekers hoeven zelf niet te weten wat de regels zijn, die vragen gewoon om koffie en Bob zorgt wel dat hij de juiste vragen stelt en dingen doet. En als de regels veranderen en ook de eerste keer slechts een beperkte selectie uit de dure automaat aangeboden mag worden, hoeft alleen Bob dit verteld te worden.
Als ik begin met dit verhaal zitten mensen me soms aan te kijken met een blik van “waar ga jij het in vredesnaam over hebben?”. Maar gaandeweg zie ik kwartjes vallen. Snappen ze de vergelijking met hun business componenten die net als Bob verantwoordelijk zijn voor hun eigen dienstverlening aan andere componenten (de bezoekers).
Omvat bovenstaande vergelijking alle aspecten van het ontwerp? Zeker niet. Maar het omvat wel voldoende aspecten om mensen met een compleet andere achtergrond mee te nemen in het ontwerp. Om elkaar te begrijpen. En om dat wederzijds begrip te gebruiken om tot betere ontwerpen te komen die uiteindelijk uitmonden in applicaties die voorzien in de huidige behoeften van de klant en ook nog eens uitbreidbaar, robuust en flexibel zijn.
Tags:
informatie