Skip navigation.
Home
Software-architectuur.nl de site van en voor software architecten!

Softwarearchitectuur ontwikkeling (Introductie)

Het ontwikkelen van een softwarearchitectuur is geen sinecure. In veel organisaties wordt veelal te weinig tijd besteed aan het opzetten van een door iedereen begrepen softwarearchitectuur. Hierdoor zijn veel softwareprodukten eigenlijk al gedoemd te mislukken voordat er aan de bouw begonnen wordt. Er zijn veel oorzaken voor aan te geven, helaas is deze lijst niet uitputtend:

  • Veranderende omgeving
  • Onbekende eisen en wensen t.a.v. de functionaliteit
  • Onbekende eisen en wensen t.a.v. de niet-functionele zaken
  • Time-to-market
  • Belangenverstrengeling
  •  
    Een aantal van de bovengenoemde oorzaken liggen nogal voor de hand, maar er zijn er ook die in mijn ogen te weinig aandacht krijgen. Waar ik mij bijvoorbeeld over verbaas is het feit dat een softwarearchitect over het algemeen teamlid is binnen het ontwikkelteam van de leverancier. Ik heb dit zelf meerdere malen meegemaakt en vanuit die positie is het erg moeilijk als architect om niet in de belangenverstrengeling van budget bij de leverancier en wensen van de klant verzeild te raken. Vanuit die positie is het lastig manouvreren tussen geld en realisatie.
     
    Het uitoefenen van softwarearchitectuur management activiteiten om een zo goed mogelijke architectuur op te zetten en te handhaven blijkt erg lastig. Vreemd eigenlijk want in de bouwwereld is het al jaren zo dat er een onafhankelijke driehoek bestaat tussen klant - architect - aannemer. In deze driehoek heeft de architect een duidelijke functie, namelijk het vastleggen van eisen en wensen (zowel functioneel als niet-functioneel) in samenwerking met de klant, het ontwerpen van een architectuur in overleg met de klant, het communiceren van het ontwerp met de aannemer, het uitvoeren van controles gedurende de bouwfase.
     
    Ik heb veel situaties meegemaakt waarin zelfs het vastleggen van niet-functionele eisen onvoldoende gebeurt. In mijn ogen zijn deze niet-functionele eisen belangrijker dan functionele eisen. Op een of andere manier worden functionele eisen wel gerealiseerd, maar is het raamwerk waarin deze functies moeten ingehangen veelal ontoereikend omdat blijkt dat er geen rekening is gehouden met zaken als (ISO9126):

  • Performance
  • Onderhoudbaarheid
  • Analyseerbaarheid
  • Schaalbaarheid
  • Installeerbaarheid
  •  
    In alle gevallen gaat de ontwikkeling verder dan de keuze voor een programmeertaal, technologie of framework. Blijkbaar is een keuze genoeg om te bepalen hoe de rest van de ontwikkeling er uit gaat zien.