+31 35 543 1000 info@kza.nl

Denk modulair, denk Lego

Wie kent Lego niet, de blokjes die al decennia lang de speelgoedverkopen domineren en waar vrijwel ieder kind wel mee gespeeld heeft. Lego is fascinerend. Hoe je van een doos met daarin eenvoudige blokjes, alles kan bouwen wat in je fantasie op komt.
De basis, het blokje is sinds 1958 al ongewijzigd in productie. Ondanks dat er wereldwijd fabrieken staan die 20 miljard steentjes per jaar maken passen alle steentjes die sindsdien gemaakt zijn op elkaar. Door de strenge standaarden en bijbehorende kwaliteitseisen die Lego hanteert blijft dit mogelijk omdat die basis goed is. Eigenlijk is alles met elkaar uitwisselbaar, en zijn de mogelijkheden eindeloos. Met 6 bouwsteentjes in verschillende kleuren van de standaard maat (2×4 nopjes) zijn al ruim 915 miljoen combinaties mogelijk. Of zoals Lego zelf zegt: ‘Je verbeelding is de enige beperking’.
En wat is dan de overeenkomst tussen Lego en de IT? Waar vroeger IT landschappen meestal maatwerk waren en veelal niet buiten een bedrijf kwamen, is die wereld behoorlijk aan het veranderen. SOA architecturen worden steeds meer gemeengoed bij bedrijven en innovatieve bedrijven zijn alweer een stap verder. Architecturen die bedrijfsoverstijgend zijn, zoals bij het online afsluiten van een autoverzekering waarbij aan het eind van het proces ook direct via een koppeling de RDW wordt bijgewerkt. En uiteraard recentere ontwikkelingen zoals IoT (Internet Of Things). Om daar goed mee om te gaan moeten je basisfuncties goed werken,  (open) standaarden afgesproken zijn en de kwaliteit daarvan geborgd worden om die producten van meerwaarde te laten zijn voor de gebruikers/klanten. En daarmee gaat IT steeds meer op Lego lijken: Combineer naar hartenlust, verbind blokken met elkaar en laat je verbeelding je enige beperking zijn.

De bouwstenen

Een standaard legoblokje kent bijna iedereen. Rechthoekig, 2×4 nopjes en voorzien van een kleurtje. Je kan er niet direct aan zien wat het uiteindelijke doel is. Je krijgt ze geleverd in een doosje waarmee je volgens de handleiding bijvoorbeeld een brandweerkazerne kan bouwen. Om de kwaliteit van het blokje te onderzoeken is de context waarin hij gebruikt gaat worden nog niet belangrijk. Het is een generiek product wat je op veel manieren kan inzetten. Daar moet je hem ook op beoordelen. Vragen die je als tester bij zo’n blokje zou kunnen stellen:

  • Voldoet het blokje aan de standaard afmetingen die gedefinieerd zijn?
  • Zijn de nopjes bovenop en de ruimte onder aanwezig volgens de gedefinieerde standaard, zodat het blokje een vorm van interactie kan aangaan met andere blokjes?
  • Heeft het blokje de kleur die het moet hebben?
  • Is het blokje van het juiste materiaal gemaakt zodat het voldoet aan de eisen ten aanzien van slijtage?

Omdat iedereen al decennia weet dat legoblokjes aan die standaarden voldoen maakt niemand zich zorgen of die blokjes wel op elkaar passen. Je pakt de gewenste blokjes en je gaat bouwen. Het past en door de juiste blokjes te combineren krijg je uiteindelijk het resultaat wat je voor ogen hebt. Een geheel rood huisje of een rood huisje met groene accenten. Wat jij wil. Denk jij (of je opdrachtgever) tijdens het bouwen dat gele accenten toch mooier is? Dan haal je het groene blokje er weer uit en zet je er een geel blokje voor terug.

 

Dit is vergelijkbaar met een functie binnen een software proces, 1 heldere en concreet gedefinieerde taak. Hooguit enkele taken. De functie “Optellen”: ‘Tel bij de binnengekomen numerieke waarde x variabele y op en geef resultaat z terug’.  De functie “Aftrekken” doet het precies andersom. Om een uitkomst te valideren heb je wellicht een functie “Vergelijking”. ‘Indien waarde x = parameter y set variabele z to true’. Niet veel groter en complexer, want dan beperk je de herbruikbaarheid al behoorlijk en maak je het ook complexer om de basis goed te standaardiseren en te onderhouden. En te testen uiteraard.

Echter, omdat stukjes code (of functies/modules) niet zo eenvoudig herkenbaar zijn als een ‘standaard rood legoblokje’ is een slimme naamgeving belangrijk. Zodat als je er achter komt dat je eigenlijk wil aftrekken in plaats van optellen je alleen maar die andere functie hoeft aan te roepen in plaats van eerst in de code te kijken wat hij ook nog maar weer deed. Net als het omwisselen van een groen legoblokje voor een gele.

Vindbaarheid van die bouwstenen is natuurlijk wel belangrijk, zorg naast een duidelijke naamgeving ook voor een sortering of groepering. Want anders loop je net als met Lego lange tijd in een grote bak met bouwsteentjes te zoeken naar dat ene blokje.

 

Functionaliteit samenstellen volgens plan?

Als je lego koopt, dan is dat een doosje met een bepaald eindbeeld. Een brandweerkazerne, een politiebureau of een tankstation. In het doosje vind je simpele bouwsteentjes en een handleiding hoe je dat eindbeeld stap voor stap in elkaar kan zetten. Lego biedt je de vrijheid om dingen anders te doen. Groter, kleiner, compleet anders? Volg je deels de handleiding en maak je het laatste stuk af volgens eigen inzicht? Of bouw je het helemaal vanaf de basis compleet anders op? Aan jou de keus. Omdat het eindbeeld wat op het doosje geschetst is vaak niet voldeed aan wat ik een politiebureau vond, werd er door mij en mijn broertjes vaak van alles aan vast gebouwd. Waarom was de achterkant van de gevangenis niet dicht? Dan konden de boeven toch zo weg? Dus dat extra muurtje werd er bijgebouwd.
En als ik begon zonder handleiding had ik door de aangeleverde bouwstenen en het beeld op het doosje toch al behoorlijk wat kaders mee gekregen. Vaak werd het dan toch een politiebureau en zelden iets compleet anders. Ook zijn de elementen van het politiebureau vaak gebruikt voor andere zaken. Het torentje links op het bureau, heeft regelmatig op een stapel standaard legoblokjes gestaan naast een weg. Als verkeerstoren voor mijn zelf bedachte vliegveld.

Met software ontworpen, gebouwd en getest in een modulaire aanpak is het niet anders. Je begint met een plan, je hebt kaders en wellicht ook detailschetsen over hoe het gaat worden. Je begint met het bouwen van de software. Je voert een unittest uit om te bewijzen dat alles doet wat het zou moeten doen en zodra het kan ga je de verschillende delen in samenhang testen op hun functionaliteit. Wanneer je de modulaire aanpak goed gevolgd hebt, ook tijdens het testen zouden de enige fouten die je in functionele testen vindt het aanroepen van de verkeerde stukjes modules (of functies) moeten zijn. Of je roept de modules met de verkeerde input aan. In plaats van x min y resulteert dat in y min x. De uitkomst is dan heel anders. Met alle gevolgen van dien. Als je de unittesten niet goed aangepakt hebt kan het zijn dat je het op de verkeerde plek gaat zoeken. En dus ook het risico loopt om op de verkeerde plek een oplossing te implementeren. Naast dat het beheer vaak ook complexer maakt, want gevonden in een laat stadium en dus meestal onder hoge druk opgelost is vrijwel altijd minder goed gedocumenteerd en geborgd.

 

Lego = strenge standaard dus niet innovatief?

Als we zo strikt zijn in die modulaire leer en alles in een zo klein mogelijk werkend element stoppen, ontnemen we dan niet de mogelijkheid om snel te ontwikkelen en buiten de reguliere kaders te denken?
Als dat zo was, dan zou Lego nog steeds alleen bestaan uit de bekende vierkante blokjes. Integendeel! Je hebt raampjes, deurtjes, deels ronde vormen, doorzichtige vormen en nog veel meer. Toen kwamen er wieltjes, via een kleine houder te koppelen aan je bestaande set blokjes. En wat te denken van het Legopoppetje. Grotendeels afwijkend van het eerste Legostandaard blokje, echter de handjes en het hoofd kun je onderling eindeloos uitwisselen. En het maakt niet uit welke accessoire voor een poppetje je pakt, het past altijd. Of het nou een Starwars zwaard is of een fleurig bloemetje. En de voeten van een poppetje? Die klik je uiteraard zo weer vast op 2 standaardnopjes van elk willekeurig legoblokje. En al die plastic steentjes passen wel allemaal via de bekende standaard methode op elkaar. Maar ook nieuwere Lego innovaties als Mindstorms sluiten nog perfect aan.

Onze softwarewereld gaat ook in sneltreinvaart dezelfde kant op als Lego. Een modulair en gefragmenteerd landschap. Minder gecontroleerd is de angst van velen, want je bent afhankelijk van anderen. Binnen of buiten je bedrijf. Maar als je de kerntaken goed blijft vervullen en veel expertise op dat vlak opbouwt en dat via een standaard methode beschikbaar stelt aan anderen gaat het elkaar versterken. Net als met Lego. Een jong kind van 6 kan prima met de blokken overweg en een huis bouwen. Voor Lego Mindstorms worden hele andere vaardigheden gevraagd. Dat de door zijn oudere broer gebouwde Lego Mindstorms robot keurig in de tuin van het huis kan worden vastgeklikt is waar 2 werelden en expertises elkaar ontmoeten en via die basisafspraken kunnen samenwerken.

Op het moment dat je je standaard methode goed en helder hebt afgesproken (of het nou een taal is of de nopjes op de legoblokjes) begrijp je het antwoord. Waarom zouden we in veel omgevingen achterliggende data kopiëren en zelf interpreteren terwijl we eigenlijk alleen geïnteresseerd zijn in een specifiek antwoord op een vraag. Dan kun je beter gewoon die vraag stellen aan een leverancier met kennis van zaken in plaats van zelf het antwoord te zoeken. De kans op een foute interpretatie is, als je het zelf doet in plaats van de kennishouder, veel groter. Als leverancier moet je garanderen dat je je zaakjes goed op orde hebt en je de manier van communiceren goed op scherp hebt. Ken je talen. Ken je standaard van gegevensuitwisseling en houd hem ook zo eenvoudig mogelijk. Een tester, maar eigenlijk elke rol die iets met kwaliteitsborging te maken heeft (in mijn ogen iedereen in het team), moet zich daar bewust van zijn. Het maakt het werk van een team uiteindelijk ook makkelijker. Bijvoorbeeld in een brede ketentest een partner moeten stubben door het neerzetten van veel data welke je eigen software moet interpreteren in een ja of nee, of een simpele service die ja of nee terug geeft? Het afstemmen tussen domeinen,  onderlinge verschillen inzichtelijk maken (wij werken met kilo’s, oh, wij met grammen) vraagt om een proactieve houding. Ga op onderzoek uit, stel vragen en vorm een beeld van de omgeving. Welke bouwsteentjes hebben wij nodig om ons doel te bereiken?

 

Modulariteit in de praktijk

Software en IT componenten komen we overal in ons leven tegen. En vaak maken ze ons leven een stuk simpeler. Onder de motorkap vind je vaak een aaneenschakeling van functies, waarbij de combinatie van alle uitgevoerde taken datgene oplevert waar je om vraagt. Of wat voor jou meerwaarde heeft.

Denk bijvoorbeeld aan een webshop. Als je als klant een product zoekt, vindt en besteld. Welke functies passeer je dan allemaal?

Een willekeurige greep:

  • Zoek artikel op naam
  • Ophalen detailinformatie artikel
  • Controleer voorraad artikel
  • Plaats artikel in winkelmandje
  • Plaats order vanuit winkelmandje
  • Zoek klantgegevens
  • Bereken totaalprijs artikelen
  • Bereken verzendkosten
  • Bevestig order
  • Roep betaalmodule aan (bv een externe leverancier)
  • Verwerk terugkoppeling betaling
  • Stuur bestelling bevestigingsmail naar klant

Alle functies moet je voor je ze in een keten hangt afzonderlijk blind kunnen vertrouwen op een correcte werking. En zo is het ook met Lego. Hoe lastig zou het ontwerpen, bouwen en testen van de keten van Lego in het volgende filmpje zijn geweest als je het niet had opgeknipt in losse functies, en deze later aan elkaar te schakelen?

Door: Ide Koops