Een systeem dat ontworpen is om slechts een klein aantal klanten te bedienen, kan in de problemen komen wanneer de oplossing een succes blijkt en een grote vlucht neemt. Met heel veel klanten die allemaal ook nog eens verschillende wensen hebben. 

De ontwerpbeginselen blijken niet te voorzien in componenten die ervoor zorgen dat je beheersbaar met veranderende eisen om kunt gaan. En om het nog complexer te maken ligt de focus van het ontwikkelteam op het halen van de met de licentiehouders afgesproken releases. 

We hebben te maken met een schijnbaar onontwarbare, gordiaanse knoop in de programmatuur. Die knoop moet ontward worden maar in deze snelkookpan is er helemaal geen tijd om even stil te staan – er moeten deadlines gehaald worden! 

Hoe krijg je dan toch inzicht in hoe het systeem in elkaar steekt en hoe je de problemen op kunt lossen? 

Als architect heb ik goede ervaringen met het opstellen van een applicatiecomponenten-architectuur. Daarin ontleed je welke functionele brokken (applicatiecomponenten) er zijn en wat de relatie is tussen deze onderdelen.  

Daarbij is het belangrijk om te ontdekken hoe ver je precies moet gaan met het decomponeren van de applicatie. Het inzicht moet in ieder geval gedetailleerd genoeg zijn om een architectuur roadmap op te stellen.  

In plaats van het rigoureus doorhakken van de gehele gordiaanse knoop, geef je in deze roadmap aan welke delen van de programmatuur gerefactored kunnen worden en welke delen je juist wel wilt doorhakken om ze terug te sturen naar de tekentafel voor een redesign.