HomeBlog ❱ Hoe je zonder technische kennis supergoeie software afdwingt

Hoe je zonder technische kennis supergoeie software afdwingt

Ontdek hét kenmerk van een steengoed software ontwerp, en hoe je daaraan kunt bijdragen - zonder dat je technische kennis nodig hebt.

Jorrit Venema door Jorrit - leestijd 4 minuten

De meest gebruikelijke aanleiding om software te laten maken is een concrete functionele behoefte: "we kunnen niet werken zoals we zouden willen". En in deze drijfveer schuilt meteen het grootste risico:

Software ontwikkeling is vaak gericht op de functionele wens van vandaag, waardoor je het feit dat de context van de software dagelijks verandert, snel uit het oog verliest.

Een bijkomende realiteit is dat er voor software ontwikkeling vele manieren bestaan. Softwarebedrijven presenteren zich vaak met hun methodiek ("korte sprints", "feedback" of "wij werken agile"). Maar de methodiek zegt in werkelijkheid heel weinig over de onderliggendearchitectuur.

De meeste software ontwerpen kun je in twee groepen verdelen, en hier zit hem de valkuil, maar tegelijkertijd ook dé kans om kwaliteit te selecteren:

  1. Het ontwerp beschrijft een statische combinatie van alle denkbare specificaties van vandaag.
  2. Het ontwerp beschrijft een veranderlijk systeem dat vandaag kan bestaan uit déze specificaties en morgen uit andere.

De weg naar wendbare software vind je dan ook niet in de methodiek om software te bouwen, met kleine deelontwerpen en snelle opleveringen als bewijs dat je op de goede weg bent. Wendbaarheid in software is veel meer dan alleen maar een eigenschap van je proces. Het moet een rode draad zijn in de technische architectuur.

Eigenlijk is wendbaarheid een feature die je moet specificeren in het ontwerp.

Een ontwikkelaar die samen met jou wendbaarheid specificeert in het ontwerp, zal een applicatie bouwen die ook technisch is ingericht op verandering; veel minder statisch en veel meer dynamisch en generiek van aard.

Het gevolg? Je zult minder snel verrast worden met één van de volgende uitspraken:

  • "Dat had je eerder moeten zeggen, nu kost het heel veel tijd om dat te veranderen."
  • "Dat kan wel, maar dan ben je alle data kwijt."
  • "Nee, dat kan je niet zelf, daarvoor moeten wij de code aanpassen."

Vergis je niet: als je bovenstaande voorbeelden te horen krijgt, dan gebeurt dat vaak niet één keer, maar veel vaker - vrijwel bij alle wijzigingen en uitbreidingen die je nodig hebt. Dit zijn directe uitingen van een statisch software ontwerp.

En naarmate de tijd vordert wordt dit probleem steeds groter. Je leverancier moet steeds meer kunsten uithalen om de applicatie te laten voldoen aan je wensen van vandaag. De kosten van op het oog eenvoudige wijzigingen worden steeds hoger.

Een statische basis is de grootste valkuil van maatwerk software

Met de dag verandert onze wereld en dus ook de context waarin jouw software leeft. Je branch, markt, klanten, processen en bedrijf zullen in de nabije toekomst allemaal veranderen. Tel hierbij op dat maatwerk software duur is en vooral op lange termijn moet gaan renderen.

Verandering en het belang van lange-termijn rendement maken statische architectuur de grootste valkuil van maatwerk software.

Hoe te voorkomen?

"OK, dus ik moet wendbaarheid specificeren... maar hoe dan?" Goeie vraag.

In zijn algemeenheid zijn er drie niveau's waarop je software statisch of juist wendbaar kunt ontwerpen. In elk software ontwerp zul je ze alle drie vaak tegenkomen - en je moet ze overal toepassen. Dit zijn ze:

Niveau 3: parameters

  • Het eenvoudigste niveau.
  • Vuistregel: alle vaste waardes waarmee je software rekent, moet niet gecodeerd maar als parameter instelbaar zijn.
  • Bekend voorbeeld: het BTW-percentage, dit moet een beheerder of superuser kunnen instellen, mogelijk met een ingangsdatum.
  • Let wel op dat parameters mogelijk tijdgebonden zijn: bij orders van 2018 wil je waarschijnlijk ook het in 2018 geldende BTW-percentage bewaren.

Niveau 2: beslissingen

  • Het meest voorkomende niveau.
  • Vuistregel: alle beslissingen die je software maakt ten aanzien van data, moet gedaan worden op basis van instelbare kenmerken in die data.
  • Voorbeeld: je wil alle klanten meenemen in een bepaalde omzetrapportage, behalve (om wat voor reden dan ook) 'Beemster groep B.V.'. Deze uitzondering mag dan niet in de software zelf worden opgenomen, ook niet als je denkt dat 'Beemster' tot in lengte van dagen de enige uitzondering zal zijn. Klanten moeten een kenmerk krijgen (bijvoorbeeld 'Uitsluiten van rapportage') en op basis daarvan moet de rapportage de juiste data selecteren.

Niveau 1: componenten

  • Verreweg het lastigste niveau, ook omdat dit vaak het exclusieve domein van de ontwikkelaar is.
  • Vuistregel: alle onderdelen van de software worden generiek ontwikkeld en 'georkestreerd' op basis van events in de software.
  • Voorbeeld: je wilt een e-mail sturen als een nieuwe klant zich heeft aangemeld. Dit programmeer je niet in de software na het opslaan van nieuwe klantgegevens, maar je laat de software bij het opslaan van alle data een 'event' publiceren. Je ontwerpt een component dat je op events van specifieke data (nieuwe klant) kunt abonneren en waarmee je een actie (e-mail versturen) kunt laten uitvoeren. Het abonneren en instellen van de e-mail notificatie gebeurt in de externe configuratie.
  • Nu is het mogelijk om functionaliteit snel aan te passen, in- of uit te schakelen of te dupliceren.
  • Een dergelijke architectuurbenadering maakt de software bij uitstek geschikt voor geavanceerde integratie met andere systemen.
  • In de praktijk is het gezien budget vaak onhaalbaar om de volledige software op deze manier te ontwerpen. Het verdient dan aanbeveling om dit in ieder geval toe te passen op onderdelen waarmee gebruikers met de software in contact komen, zoals notificaties, exports en rapportages, omdat de logica en vorm hiervan waarschijnlijk regelmatig zal veranderen.

Aan de slag

Ga je software laten maken? Hopelijk zie je na het lezen van dit stuk dat je ook zonder diepgaande programmeerkennis een positieve invloed kunt hebben op de technische architectuur van je software.

Neem deze aandachtspunten mee in de voorbereiding met je ontwikkelaar. Zo zul je maximaal profiteren van je investering.

Ga je hiermee aan de slag? Deel je bevindingen of vragen in de reacties hieronder, ik reageer altijd.

Reacties

Software ontwikkeling - betere software door prototyping

Over ons - Blog - Contact

Privacyverklaring - Support

Mailinglijst