Ontwikkelen in Onzekerheid

 
04 augustus 2008

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.


Werken met ?
Kijk dan bij onze mogelijkheden voor starters en/of ervaren IT'ers.


Categorieën: Project- & procesmanagement, Architectuur

Tags: , ,


Reacties (6)

  • Henri schreef:

    Allereerst mijn complimenten voor deze post. Je spreekt over een aantal zaken, waar ik al jaren mee worstel in de IT wereld.
    Ik ben zelf niet genoeg ingewijd in software ontwikkeling om er goede uitspraken over te doen, maar dat belet me niet om ook te streven naar een andere grondhouding binnen de IT. Stel je voor je werkt in “de business” zoals IT-ers hun (vaak) collega’s aanduiden en een ontwikkelaar, ontwerper of beheerder antwoordt op een “business vraag” met de bijna ambtelijke formule: “software handelt dus conform specs”, als uit alle aspecten van de vraag blijkt dat de verwachting duidelijk anders is! En al is dat goed te begrijpen, dan hoor je dat er een project moet worden opgestart om de specificaties duidelijk te krijgen via het Prince2 model (ook te begrijpen), waarna de beheerafdeling zijn mondje roert over capacity management of software distribution and control volgens ITIL (minder te begrijpen). De changes of enhancements dan volgens BISL worden geimplementeerd enz. enz. (wat the ….. is BISL?)En ondertussen loopt je gouden kans op een deal de mist in. Heden ten dage probeert de IT wereld dit gat te overbruggen door over “business-IT alignment” te spreken en oude wijn in nieuwe zakken te gieten door “requirement management” te gaan verkondigen.
    Het grote probleem is volgens mij dat we produkten gebruiken en/of maken die de flexibiliteit die gevraagd wordt niet aankunnen en we proberen dat met modellen op te lossen, maar je hebt simpelweg flexibele produkten nodig. Neem “de business” aub niet kwalijk dat ze proberen in moeilijke markten het hoofd boven water te houden door nieuwe ideeen te spuien. Toegegeven, men weet vaak niet wat de consequenties zijn van de vragen die men stelt, maar wees eerlijk, onze standaard (IT-) antwoorden zijn toch ook soms om je op te vreten (“requirements zijn net in de nieuwe release verwerkt”). Wij zouden proactief moeten zijn, mensen duidelijk moeten maken wat de consequenties zijn, maar niet door ze terug te dringen in een (wat Hans noemt) gejuridiseerde wereld, maar samen met hen proberen ultraflexibele produkten te bouwen en ze flexibel te houden. Dus Hans, ik idealiseer met je mee.

    Geplaatst op 28 augustus 2008 om 20:10 Permalink

  • Stefan Bookholt schreef:

    Dit is inderdaad een interessant onderwerp. Ik heb in het verleden al een aantal pogingen gezien tot flexibele systemen, waar soms je haren van overeind gaan staan. Dit kwam met name omdat men geprobeerd had de flexibiliteit/genericiteit door te voeren t/m de user interface.

    Waarom leidt dit vaak tot onbruikbare systemen? Volgens mij omdat een systeem het beste werkt als deze je zo goed mogelijk ondersteund in je werkzaamheden. Deze werkzaamheden verschillen vaak op vele punten. Wanneer een generiek systeem je hierin probeert te ondersteunen, kan het alleen ondersteuning bieden op de gemeenschappelijke punten van die werkzaamheden.

    Ik denk dat onze programmeeromgevingen wat volwassener moeten worden, en dat we dan in staat zijn heel snel in te spelen op elke verandering. Nu zijn zaken als databinding, zoeken en persisteren hele tijdrovende zaken waar we waarschijnlijk in de toekomst hele mooie simpele oplossingen voor gaan vinden. Op dat moment wordt inspelen op veranderingen ook geen probleem meer.

    Geplaatst op 26 augustus 2008 om 13:56 Permalink

  • Jasper Floor schreef:

    Kan je iets goeds maken ‘conform vooraf opgestelde requirements’? Natuurlijk, goede requirements die bevroren zijn kunnen best handig zijn waneer je weet dat iets niet veranderd. Een sateliet bijvoorbeeld (alhoewel die ook steeds meer reprogrameerbaar worden). Voor toepassingen die absoluut goed moeten werken over langere termijn werkt die aanpak wel mits je zeker weet dat de requirements ook niet veranderen.

    Dat is dus het echte probleem, niet dat requirements vooraf worden opgesteld, maar dat we niet vooraf kunnen weten wat de requirements aan het eind zijn. Daar zijn honderduizend technieken voor ontwikkeld.

    Hier zit echter ook een gevaar in. Als je je hele systeem zo flexibel maakt dat het alles kan…dan heb je toch gewoon een computer? Software dwingt je computer in bepaalde patronen, dat is de bedoeling. Wanneer je systeem ultra instelbaar is dan heb je even geod een expert nodig om het in te stellen.

    Een generiek systeem dat instelbaar is door een domein-expert die verder leek is op computer gebied zal wel winst op leveren (denk ik) tov een systeem dat aangepast moet worden door een engineer. Je hebt naast de engineer altijd die expert nodig. Als we echter al dat generieke syteem konden maken dan konden we vooraf de requirements meten….

    Je moet dus niet streven naar het onhaalbare. Je wilt een flexibel systeem maar de programeur raak je niet kwijt. Gedurende de levenscyclus van de meeste systemen heb je mensen nodig voor onderhoud, zowel adaptief als correctief. Het gebouwde systeem moet flexibel tov veranderingen in zichzelf.

    De gebruiker moet je niet te veel laten in stellen. Dat is het domein van experts, dus zullen er maar weinig mensen zijn die dit zouden moeten mogen (of zelfs zouden kunnen).

    Geplaatst op 26 augustus 2008 om 9:55 Permalink

  • Vorige week vroeg een collega wat ik met mijn vorige reactie bedoelde.
    Ik heb dat toen nog eens nagelezen en kwam tot de conclusie dat datgene wat ik bedoelde misschien niet voor iedereen zo overkomt.
    Om een lang verhaal kort te maken: nadat je weet wat je wilt, gebruik je IxD om te bepalen hoe.
    Domeingedreven (of modelgedreven) en IxD kunnen prima naast elkaar, alles om onzekerheid in ontwikkelen wat weg te nemen.

    Geplaatst op 21 augustus 2008 om 10:11 Permalink

  • Agile:
    Ultraflexibel systemen is zeker een zeer interessant onderwerp. Iets waar we gelukkig allemaal nog een tijd mee bezig mogen zijn :-). In mijn eigen praktijk valt op dat van onze klanten al openstaan voor een agile-achtige benadering van software ontwikkeling. Wanneer we gevraagd worden om een voorstel uit te brengen om software te ontwikkelen is dat het eerste wat ter spraken komt. (Helaas komen direct daarna de vragen als wanneer is het af en wat gaat het exact kosten. Maar ja eigenlijk is dat ook niet gek. We willen toch allemaal graag weten waar we aan toe zijn.)

    Architectuur:
    Een agile aanpak is een goede manier om tijdens een traject om te gaan met nieuwe inzichten, maar het is slechts een goede start. Naast de aanpak moet ook de software architectuur zelf aangepast worden. In onze praktijk proberen we de “separations of concerns” zo mooi mogelijk te implementeren door onderscheid te maken in code die direct betrekking heeft op het business domein en code die puur van technische aard is. Door het isoleren van het businessdomein kunnen we ons volledig focussen op de functionaliteit die de business van de software verwacht. Daarna kunnen technische services gekoppeld worden die persistentie in een database realiseren of de ontsluiting naar een GUI. Dat zo’n domeingedreven benadering werkt hebben we al een aantal keren kunnen tonen.

    Toekomst:
    Het bereiken van ultraflexibel systemen waarin we meerdere businessdomeinen met elkaar kunnen laten samenwerken en snel en eenvoudig aanpassingen kunnen maken hebben we nog niet mogen bewijzen, maar die uitdaging gaan we graag aan.
    Zoals ik er nu naar kijk komen we dan in een wereld waarin complexe samenhangende domeinen gaan samenwerken en een diensten naar elkaar gaan leveren. (Mmm de domeingedreven benadering in een SOA.) Dit geeft al meer grip op de software en verhoogd de aanpasbaarheid, maar ja zou het niet mooi zijn als we de implementatie in zo’n benadering nog eens kunnen genereren. Dat is toch nog veel sneller dan coderen. Een nog veel grotere flexibel systeem.

    Geplaatst op 12 augustus 2008 om 14:52 Permalink

  • Hans, goede post! Zelf denk ik hier ook wel eens over na. In het verlengde van pro-actief nadenken over requirements of zelfs voordat je daar over gaat nadenken, ligt naar mijn mening het Interaction Design traject. Daarmee krijg je niet niet zozeer een bak met requirements, maar complete scenario’s over hoe een gebruiker een systeem wil gebruiken. En dat veranderd naar mijn idee niet zo heel snel. Kleine aanpassingen of changes daargelaten : Een flexibel systeem bouwen dat vooraf een IxD traject is doorlopen lijkt in mijn optiek de beste oplossing om software te doen slagen.

    Maar toch zijn we er dan niet. Meestal gaat het nog verder terug. Het probleem ligt volgens mij meer bij de business. In de loop der jaren is er in de markt volgens mij niet zo heel erg veel ruimte meer voor andere gaten, dus gaan de business-mensen volgens mij maar wat gaten verzinnen. Ze roepen bijvoorbeeld “wij willen iets met sms!” zodat ze later tegen hun zakenrelaties kunnen zeggen dat ze een sms-ding op de markt hebben gezet. Marktonderzoek en een innovatief product verzinnen is één ding, maken wat de gebruiker wil is een andere, en software flexibel genoeg maken is naar mijn idee de laatste stap en indien dat gelukt is ben je tot een goed en flexibel product gekomen!

    Geplaatst op 08 augustus 2008 om 11:46 Permalink