Ontwikkelen in Onzekerheid

Als iedereen het erover eens lijkt te zijn dat een opdrachtgever de requirements moet vaststellen, en de leverancier conform de requirements moet ontwikkelen, dan begin ik nattigheid te voelen. Op de beurs zouden ze me waarschijnlijk een contrarian noemen – iemand die altijd tegen de heersende opinie ingaat. Dat kan je overigens een hoop geld opleveren, maar dat terzijde. Het bevriezen van requirements leidt in de praktijk vooral tot veel dramatiek. Onlangs nog heeft UWV de nodige tientallen miljoenen moeten afschrijven omdat een systeem conform de requirements was opgeleverd, en de mening had postgevat dat het in overleg wijzigen van de requirements zou zondigen tegen de aanbestedingsregels. Ik vraag me wel eens af of er ooit een succesvol systeem gebouwd is conform vooraf opgestelde requirements. Dat moeten dan vast ofwel hele globale requirements zijn geweest, of het was een heel saai systeem.

Inmiddels dringt het besef steeds meer door dat requirements van nature een bepaalde dynamiek hebben, en dat een goede ontwikkelmethodiek juist gericht zou moeten zijn op het makkelijk kunnen wijzigen van requirements. De markt schrijdt voort, de technologie schrijdt voort, dus waarom zouden inzichten niet ook mogen voortschrijden. Of het nou SCRUM is, of nog eXtremer, het “omarmen” van veranderingen groeit in populariteit. Een van de grote voordelen is dat je als opdrachtgever op ieder moment met een ontwikkeltraject kunt stoppen als je het resultaat “goed genoeg” vindt. Perfectie is duur en concessies doen is een traject van vallen en opstaan. Het is mooi dat we op deze manier de juridisering van ons vakgebied een beetje kunnen terugdringen.

Als dwarsgebakken zeurpiet gaat mij dat nog steeds niet ver genoeg. Want een dynamisch ontwikkeltraject is wel winst, maar het ontwikkeltraject is meestal maar een klein deel van de hele levenscyclus van een applicatie. En ik zie nog al te vaak gebeuren dat zodra een applicatie is opgeleverd, het ontwikkelteam wordt ontbonden, en de functionaliteit wordt bevroren – misschien uitgezonderd nog wat moeizame changes. Alsof de marktontwikkelingen en de technologische ontwikkelingen vanaf het moment van oplevering ineens wel stilstaan. Alsof alle inzichten ineens niet meer voortschrijden als er eenmaal met de implementatie is begonnen. Alsof er een onoverbrugbare kloof gaapt tussen ontwikkeling en onderhoud van software.

Ik zit er vaak over te piekeren hoe je dat zou kunnen ondervangen. Hoe je, wat ik noem, ultraflexibele softwaresystemen kunt ontwikkelen. Systemen die zo generiek zijn opgezet, dat je niet voor ieder wissewasje de code hoeft aan te passen. Systemen die de vrijheid bieden om op een simpele manier te veranderen als dat nodig is. Systemen die ontworpen zijn om te kunnen evolueren.

Ik weet het, ik ben niet de enige die daarover nadenkt. Er is ook allerlei technologie beschikbaar, of het nou gaat om neurale netwerken, business rules engines of business process management systemen, een orchestratie subsysteem als onderdeel van een ESB of een moderne modelgedreven aanpak als MDA – flexibiliteit wordt op tal van manieren geboden. En toch gaat dat altijd om – wat ik noem – gelokaliseerde flexibiliteit. Business rules worden pas geëxecuteerd als er een of andere functie is die ze activeert. Business processen kunnen alleen reageren op de input die ze ter verwerking aangeboden krijgen. En business rules kunnen alleen maar geformuleerd worden voor feiten die ergens als een attribuut in het datamodel zitten. En de data in het datamodel is toch echt afhankelijk van de invoer van de schermen of de externe interfaces.

Maar wat nu als er zich een nieuw feit voordoet? Als we, laten we zeggen, een concurrent een telefoonabonnement aanbiedt met de garantie dat de kosten voor dataverkeer buiten de bundel niet hoger zullen zijn dan maximaal €50 per maand. Dus dat je niet langer meer het risico loopt dat je €500 kwijt bent als je in het buitenland je laptop openklapt en Windows toevallig besluit om op de achtergrond geheel automatisch de maandelijkse update uit te voeren. En stel nou dat we op die concurrent willen reageren door onze klanten een flexibel slot aan te bieden. Dat is nog mooier, want dan mag je zelf de bovengrens bepalen. Ouders kunnen dan beslissen dat hun kinderen niet meer dan €10 buiten de bundel mogen sms’en, terwijl zakenlui misschien liever een veilige grens van €250 per maand willen. Een mooi nieuw product, waar vast veel vraag naar is. Maar het moet natuurlijk wel snel op de markt zijn, want anders heeft de concurrent de markt al ingepikt.

Zou het nou niet mooi zijn als je zo’n product simpelweg zou kunnen inregelen op een bestaand softwaresysteem, zonder dat je een omslachtig IT-project hoeft te starten. Dat de schermen zo slim zijn dat ze voor dit product automatisch om een grensbedrag gaan vragen, dat dit bedrag ook vanzelf in de contractendatabase wordt opgeslagen, dat het op de maandelijkse factuur verschijnt en dat het netwerk zo slim is dat het tijdig controleert of de verbinding al op slot moet en – oh ja – als het op slot zit ook tijdig constateert dat het weer open mag.

Aan de hand van dit fictieve voorbeeld valt gemakkelijk in te zien dat de flexibiliteit die de business vraagt maar al te vaak op heel verschillende plaatsen in de architectuur geboden moet worden. Dat het wel kan helpen om een flexibel platform te bouwen, waarin componenten voor business rules, process management en orchestratie vast een prominente plaats zullen innemen, maar dat zulke flexibiliteit per definitie beperkt wordt door de flexibiliteit van de kernsystemen. En dat het dus ontzettend belangrijk is om niet alleen het platform, maar ook de kernsystemen en hun onderlinge interacties voor flexibiliteit te ontwerpen.

Noem me een idealist, of een masochist, maar ik heb er lol in om zulke systemen te bedenken. En gezien de vele organisaties die nog steeds worstelen met hun legacysystemen, of met hun proces van requirements management, of met hun time-to-market, kan het niet anders of er moet een grote markt braak liggen. Een markt vol met interessante architectuuruitdagingen. Ik zou hopen dat architecten nou eindelijk eens gaan begrijpen dat ontwikkelen in onzekerheid ook kansen biedt. Dat het leuk is om een systeem te bedenken dat mee kan bewegen met wijzigende requirements. Dat je niet moet afwachten totdat de requirements vaststaan, maar pro-actief moet nadenken over mogelijkheden om requirements die nog niet bedacht zijn te implementeren. Dat je ook heel goed met scenariotechnieken kunt werken, om gevoel te krijgen voor het soort requirements waartegen een oplossing bestand zou moeten zijn.

En weet je wat pas echt cool is? Als je zo’n ultraflexibel systeem eenmaal hebt bedacht, dan zul je zien dat het een oplossingspatroon is dat je in heel veel verschillende situaties opnieuw kunt gebruiken. Dat je zoveel logica uit de kernsystemen hebt gehaald, en flexibel in modellen kunt vastleggen, dat de overblijvende kernservices ineens verbazingwekkend makkelijk te realiseren zijn. Dat je een voorheen ongekende productiviteit kunt halen. Dat de requirements gedurende de hele levenscyclus heel makkelijk mee-evolueren met het systeem zelf. En dat voorheen gescheiden processen voor ontwikkeling en beheer plotseling in één proces van evolutie samenkomen.

Separation of concerns is zo gek nog niet. Als je maar niet de fout maakt om te denken dat een kwaliteitsattribuut als flexibiliteit maar één concern is die je separaat zou kunnen implementeren. Dat mag na dit betoog toch geen verrassing meer zijn.

Deze bijdrage is geschreven door gastblogger Hans Bot.

Hans Bot is Managing Architect bij Aquila: architect voor de verzekeringsketen en docent enterprise architectuur bij DNV-CIBIT.

Hij is of was actief in het Nederlands Architectuur Forum, het Landelijk Architectuur Congres en het Nederlands Kampioenschap ICT Architectuur en is een gewaardeerd spreker op congressen en events. Hans heeft meer dan 15 jaar ervaring met archITectuur in de praktijk en schrijft hierover op zijn weblog: ArchITectuur Bedrijven.