Maatwerk software in ontwikkeling: het Triple Diamond-model

Wat is het Triple Diamond model?

Het Triple Diamond model is een stappenplan voor innovatie en productontwikkeling, waarbij je bij elke fase breed opent en sluit met een keuze. In de eerste diamant verken je het probleem en scherp je het aan tot één definitie. Bij de tweede verken je oplossingsrichtingen en kies je het ontwerp en de technologie waarmee je verder gaat. De derde diamant draait om de bouw, waarin je verkent hoe je dat ontwerp technisch realiseert en afsluit met een passende en toekomstgerichte software.

Bij Dawn Technology noemen we die drie fases Discovery, Design en Development. Elke fase sluit met een vastgelegde keuze. Daardoor weet je aan het begin van de volgende fase waar je op verder bouwt en waarom die richting is gekozen.

Twee diamanten versus drie: het verschil

Het Double Diamond-model werkt met twee diamanten: één voor het probleem, één voor de oplossing. Die tweede diamant vat ontwerp en bouw samen in één fase. Voor maatwerksoftware werkt dat onvoldoende, omdat de technische realisatie eigen risico's kent die pas zichtbaar worden tijdens het bouwen zelf. Want bijvoorbeeld een architectuur die op papier klopt, kan in de praktijk niet meeschalen.

Daarom hebben wij gekozen voor het Triple Diamond-model, omdat de bouw daarin een eigen fase krijgt met een eigen verkenning en afsluitende keuze. Zo worden architectuur- en integratierisico's vóór de start van de bouw afgewogen in plaats van er tijdens de bouw achter te komen.
 

Discovery: de kern van de vraag op tafel krijgen

In de eerste fase brengen we in kaart wat er speelt. We gaan in gesprek met jou, inventariseren het IT-landschap en tekenen de customer journeys uit. Vervolgens bepalen we welk vraagstuk we willen beantwoorden en leggen we de kaders vast voor de maatwerk software ontwikkeling.

Dat eindpunt bepaalt de waarde van alles wat erna komt. Een verkeerd afgebakend probleem levert software op die technisch klopt en functioneel mist. Vaak zit de echte vraag ook een laag dieper dan de vraag waarmee een organisatie binnenkomt. Een organisatie kan bijvoorbeeld vragen om een sneller systeem, terwijl de vertraging eigenlijk ontstaat doordat afdelingen dezelfde data los van elkaar bijhouden. Daarom wil je die onderliggende oorzaak boven tafel, zodat de probleemdefinitie waarmee je aan de slag gaat ook echt de kern raakt.
 

Wat je uit deze fase meeneemt:

• Een probleemdefinitie die je intern kunt verantwoorden
• Inzicht in je huidige IT-landschap en de raakvlakken met bestaande systemen
• Customer journeys die laten zien waar gebruikers vastlopen

Discovery case: KNMI

Hoe bepalend die eerste fase is, zie je bij de nieuwe KNMI-app. Het KNMI wilde burgers eerder en gerichter waarschuwen, nu weerextremen door klimaatverandering vaker voorkomen. Zodra je het zo formuleert, verschuift de opgave van informatie tonen naar mensen laten handelen.

Dat is terug te zien in de app. Bij een code geel, oranje of rood krijg je meteen advies over wat je kunt doen, omdat een waarschuwing zonder handelingsperspectief weinig verandert. Toegankelijkheid kreeg veel aandacht, want de app moet werken voor een brede doelgroep met uiteenlopende beperkingen. Ook bouwden wij de app volgens de principes van de Green Software Foundation, waardoor die minder batterij en processorkracht verbruikt.
 

Design: maatwerk software ontwikkeling waar je over vijf jaar nog blij mee bent

In de tweede fase werken we aan de oplossing en kiezen we de software. Die keuze baseren we op het vraagstuk en op je bestaande IT-landschap. Draait je organisatie op het Microsoft-ecosysteem, dan wegen integratiemogelijkheden zwaarder dan de voorkeur van een ontwikkelteam. Ook bepalen we hier wat we hergebruiken en wat we nieuw bouwen.

Die afweging werkt alleen wanneer je ontwikkelpartner niet gebonden is aan één vaste technologiestack. Met meer dan 250 software engineers hebben we specialisten in .NET, PHP, Delphi, Cloud, Data Engineering, AI en mobile in huis.

Wat we in deze fase vastleggen:

• De technologiekeuze met de afweging die eraan ten grondslag ligt
• Een architectuur waarin privacy en security by design zijn meegenomen
• De verdeling tussen herbruikbare componenten en nieuwe code via onze Bake-strategie
• Afspraken die vendor lock-in voorkomen, zodat je later kunt wisselen zonder herbouw

Design case: Vitens

Bij Vitens bepaalden twee eisen de hele opzet van het systeem. Het laboratorium van Vitens bewaakt de kwaliteit van het drinkwater dat bijna zes miljoen klanten dagelijks uit de kraan halen. Vitens levert jaarlijks zo'n 33 miljoen kubieke meter water, gecontroleerd met uiteenlopende meetapparatuur. De software moest daardoor jaarlijks miljoenen meetgegevens verwerken.

Daar kwam een tweede eis bij. De rapportage moest voldoen aan strenge normen, waardoor elk resultaat achteraf te reconstrueren moet zijn tot aan de meting waar het uit voortkomt. Wij ontwikkelden software op maat met een controle op het proces zelf, waardoor het systeem signaleert wanneer de analyse niet meer aan de kwaliteitseisen voldoet. Daardoor neemt Vitens sneller en betrouwbaarder besluiten over de waterkwaliteit, met een architectuur die vanaf de start was ingericht op het datavolume en de traceerbaarheid die het laboratorium nodig had.

Development: toekomstgericht bouwen binnen een vast kwaliteitskader

In de derde fase ontwikkelen we software in korte ontwikkelcycli van een aantal weken. Aan het eind van elke cyclus draait er werkende software die je zelf kunt bekijken en gebruiken. Testen loopt daarbij mee met de bouw. Voordat we beginnen leggen we vast wanneer een onderdeel af is, welke tests het moet doorstaan en wat we precies gaan testen.

Die volgorde bepaalt wanneer je fouten tegenkomt. Test je pas aan het eind, dan komen problemen boven water op het moment dat de code is veranderd en andere onderdelen erop voortbouwen. Test je doorlopend, dan los je ze op terwijl de code vers is en de gevolgen beperkt blijven. Daarnaast zie je elke cyclus iets werkends, waardoor je kunt bijsturen op basis van software in plaats van een voortgangsdocument.

Wat we in deze fase vastleggen:

• Elke wijziging wordt beoordeeld door een collega voordat die erin gaat
• Geautomatiseerde tests controleren of bestaande functionaliteit blijft werken
• Wijzigingen gaan langs een vaste reeks controles voordat ze op de live-omgeving komen
• Je ontvangt rapportages met de bevindingen en de verbeterpunten die eruit volgen

In de weken na oplevering houden we alles in de gaten. Gaat er iets mis, dan lossen we het op en krijg je achteraf een analyse van de oorzaak. Ook waarschuwen we je proactief wanneer onderdelen verouderen of een risico gaan vormen.

Development case: Groenendijk

Groenendijk kreeg van het ministerie van Defensie de opdracht om ruim 45.000 militairen en reservisten aan nieuwe gevechtslaarzen te helpen, ieder met de juiste pasvorm. Om alles handmatig op te meten bij deze geen optie, dus klopte Groenendijk aan bij ons.

Wij bouwden voor hun een 3D-inmeetapplicatie, gekoppeld aan bestaande bedrijfssystemen, in tweewekelijkse sprints. Pas tijdens die sprints kwamen praktijksituaties boven water die vooraf niet volledig te voorzien waren, zoals militairen met verschillende schoenmaten links en rechts. Elke sprint leverde werkende software op, dus testten en verfijnden we die logica meteen in de applicatie zelf. Nu staat er een stabiele applicatie die elke militair, in de pastrailer of op de vaste meetlocatie in Soesterberg, gegarandeerd de juiste laars helpt te vinden.
 

Wat het model oplevert bij maatwerk software ontwikkeling

Drie dingen merk je terug in het verloop van een traject.

• Het probleem staat vast voordat er code wordt geschreven. Daardoor blijft herstelwerk uit op het moment dat aanpassen het meeste werk kost.
• De technologiekeuze is onderbouwd. Je krijgt de stack die bij het vraagstuk past, los van wat een leverancier toevallig in huis heeft.
• De oplevering is voorspelbaar. Vooraf ligt vast wanneer iets af is en welke controles daaraan voorafgaan, en na livegang blijven we betrokken.