door: Gert Florijn, Mark van Elswijk, Marc Evers
verschenen in: Automatisering Gids, jaargang 35, nr. 10, maart 2001, p. 17
De belangstelling voor softwarearchitectuur is de afgelopen jaren sterk gegroeid. Het grote aantal deelnemers aan het tweede Landelijk Architectuur Congres (november 2000) maar ook het verschijnen van diverse publicaties getuigen daarvan. Ook over de inhoud van softwarearchitectuur ontstaat de laatste jaren steeds meer consensus. Zo heeft de IEEE een standaard aangenomen voor het beschrijven van softwarearchitecturen (IEEE-1471-2000); deze standaard geeft definities en een aanbevolen aanpak en structuur voor het opstellen en vastleggen van architectuurdefinities. Volgens IEEE-1471-2000 beschrijft een softwarearchitectuur de fundamentele organisatie van een systeem in termen van zijn componenten, hun onderlinge relaties (waaronder ook interactie) en de relaties met de omgeving. Daarbij worden de leidende principes voor het ontwerp en de evolutie van het systeem vastgelegd. Toch betekent dit alles niet dat het gebied van softwarearchitectuur "af" is. Er zijn nog diverse problemen en uitdagingen.
Zowel in de literatuur als in de praktijk zijn verschillende argumenten te vinden om aandacht te besteden aan de architectuur van systemen:
Naast de beoogde voordelen van architectuur is er ook nog een aantal belangrijke probleemgebieden bij het opstellen, vastleggen en in gebruik nemen van een softwarearchitectuur. Een greep uit het aanbod:
Architectuur is vooral een middel om complexiteit en omvang beheersbaar te maken. Maar dat is zeker niet de enige reden voor de groeiende belangstelling. Een andere drijvende en inspirerende kracht is de onzekerheid over voor de veranderingen in de toekomst.
Het enige dat zeker is, is dat veranderingen komen: uit de technologie, uit de maatschappij, uit de wetenschap, et cetera. Een bron van verandering die steeds prominenter wordt is het feit dat systemen vaker moeten samenwerken met andere systemen en dat de samenstelling van systemen steeds weer verandert. Dat geldt natuurlijk in de wereld van de informatiesystemen; de introductie van e-commerce toepassingen is het meest recente voorbeeld hiervan. Maar ook van oorsprong geïsoleerde software, zoals embedded software in kopieerapparaten, moet steeds meer open zijn voor communicatie met de buitenwereld.
Een goede architectuur kan omgaan met verwachte veranderingen. Dat kunnen we via assessmentmethoden zelfs proberen in te schatten. Maar helaas bieden resultaten behaald in het verleden geen garantie voor de toekomst. Hoe moeilijk het voorspellen van de toekomst is, kunnen we dagelijks zien bij herhalingen van Star Trek en andere oude SF-series. Ervaringen, kennis en aannames bepalen de grenzen en spelregels van onze fantasie. Ook in de ICT-wereld volgen veranderingen en vernieuwingen elkaar snel op, sommige met een onverwacht grote impact. Daarnaast kunnen informatietechnologieoplossingen niet losgezien worden van de context waarin ze worden gebruikt - ook die is aan verandering onderhevig.
Als de toekomst anders uitpakt dan verwacht, kan diezelfde flexibele architectuur op een gegeven moment in de weg gaan zitten. Het gezegde "baat het niet dan schaadt het niet" gaat niet op voor een softwarearchitectuur. Integendeel, teveel verkeerde en irrelevante aannames en ontwerpbeslissingen maken het moeilijker en tijdrovender om software te begrijpen en aan te passen. Dit probleem wordt nog eens verergerd door het fenomeen dat hoe meer in en rond die architectuur is geïnvesteerd, hoe moeilijker het wordt de architectuur los te laten of grondig te wijzigen. Misschien moeten we in dit geval wel spreken over "architectuurlegacy".
Terecht zijn de aanpasbaarheid en veranderbaarheid van de architectuur dan ook een belangrijke bron van inspiratie, maar ze zijn ook de grootste bron van zorg. Het zo effectief en efficiënt omgaan met veranderingen is waarschijnlijk de belangrijkste uitdaging. Hoe kunnen we de zorg zo veel mogelijk verminderen? Of moeten we ons geen zorgen maken en de evolutie haar gang laten gaan?
Om beter om te gaan met (continue) veranderingen moeten we in de eerste plaats proberen meer inzicht te krijgen in de aard van de veranderingen zelf. Op dit gebied vindt op verschillende plaatsen onderzoek plaats. Zo wordt er bij de Vrije Universiteit gewerkt aan een classificatie van veranderingen die veel impact hebben op de architectuur (en dus op het systeem). Met behulp van dergelijke classificaties is het wellicht mogelijk de impact van bepaalde soorten veranderingen te verminderen of te beheersen. Daarnaast vindt empirisch onderzoek plaats waarin de evolutie van concrete (families van) software producten wordt bestudeerd.
Hieronder zullen we nader ingaan op een aantal oplossingsrichtingen om de impact van veranderingen te beheersen.
Ontwikkelprocessen en verandering
Voor ontwikkelprocessen kunnen twee extremen worden onderscheiden met betrekking tot het omgaan met veranderingen: voorspellend en adaptief. Het traditionele watervalproces bijvoorbeeld is voorspellend, processen als Extreme Programming en DSDM zijn in hoge mate adaptief.
Een adaptief ontwikkelproces gaat ervan uit dat veranderingen niet te voorspellen zijn. De focus van de architectuur ligt op de functionaliteit die nu nodig is en er wordt niet geanticipeerd op specifieke verwachte veranderingen. Als veranderingen zich voordoen, kan een adaptief proces daar op twee manieren mee omgaan: het bestaande systeem weggooien en alles opnieuw bouwen óf het systeem en de bijbehorende architectuur steeds weer aanpassen. Deze laatste aanpak kan ondersteund worden door te proberen de architectuur en het systeem in goede conditie te houden door veelvuldig te herstructureren.
Het vastleggen van de intenties, aannames en overwegingen achter de architectuur kan ook een belangrijke ondersteuning bieden bij het continu aanpassen. Het idee is dat het eenvoudiger is om de architectuur aan te passen als de bedoeling achter de architectuur bekend is. Dit thema is onderwerp van actief onderzoek en komt ook terug bij bijvoorbeeld Extreme Programming. Het is gerelateerd aan de documentatieproblematiek waar veel ontwikkelprojecten op een gegeven moment tegenaan lopen: wat moet er precies gedocumenteerd worden en welke kennis is nodig om software te kunnen onderhouden?
Er is recentelijk een verschuiving te zien naar meer adaptieve processen. Een belangrijk probleem is het vinden van een balans tussen voorspellen en adaptiviteit.
Indirectie
Het is mogelijk om specifieke verwachte veranderingen te anticiperen in de architectuur. De gebruikelijke manier om veranderbaarheid in te bouwen is het introduceren van extra indirectie, waarbij functionaliteit in delen gesplitst wordt en de communicatie tussen die delen expliciet gemaakt wordt. Gelaagde modellen zijn het bekendste voorbeeld van indirectie. Veranderingen zouden gelokaliseerd moeten zijn binnen invidivuele lagen. In de praktijk beslaan veranderingen vaak verscheidene lagen, doordat die lagen allerlei aannames over elkaar doen en sterk afhankelijk zijn.
Minder aannames
Bij standaardarchitecturen voor het koppelen van apparatuur, zoals Jini, zien we de trend om componenten zo min mogelijk aannames over elkaar te laten doen. Het opstellen van een dergelijke minimale architectuur houdt de componenten flexibel voor onverwachte veranderingen. In HAVI (Home Audio/Video Interoperability), een standaardarchitectuur voor interoperabiliteit van audio- en videoapparaten van verschillende fabrikanten, worden zo min mogelijk aannames gedaan over wat apparaten kunnen en is er geen centrale besturing. De gedefinieerde interfaces zijn uitbreidbaar en de architectuur is in hoge mate flexibel. Een risico bij deze aanpak is dat de architectuur te weinig aannames doet en triviaal wordt.
Adaptieve componenten
Een oplossingsrichting die nog erg speculatief is, is het bouwen van softwarecomponenten die zichzelf tot op zekere hoogte kunnen aanpassen aan een veranderende context. Er vindt op dit gebied allerlei onderzoek plaats onder de noemer van bijvoorbeeld actieve objecten, agent-gebaseerde software en lerende systemen.
Gebruik van domeinkennis
Kennis en aannames over een probleemdomein en mogelijke veranderingen binnen dat domein kunnen in generatietools, domeinspecifieke talen en frameworks verwerkt worden. Het idee hierachter is dat kennis van het probleemdomein stabiel is en te scheiden is van oplossingskennis. Veranderingen die zich voordoen, kunnen op een hoger abstractieniveau verwerkt worden en de aangepaste software kan opnieuw gegenereerd worden. Voorwaarde is dat de veranderingen voorzien zijn binnen het probleemdomein. Voorbeelden hiervan vinden we bijvoorbeeld terug in de financiële wereld.
Kennis van het probleemdomein is in de praktijk echter lang niet altijd stabiel. Dit zien we ook bij het opstellen van bedrijfsbrede, semantische datamodellen. Deze aanpak wordt toegepast om verschillende componenten te kunnen koppelen en om veranderingen te beheersen. Deze aanpak heeft niet alleen last van instabiliteit van domeinkennis, maar ook van het feit dat het zeer moeilijk is om een groot aantal, nogal uiteenlopende gezichtspunten expliciet te maken en te integreren. In de praktijk blijkt deze aanpak meestal niet afdoende te werken.
Zelfbeschrijvende componenten
Het gebruik van zelfbeschrijvende componenten biedt mogelijkheden om met veranderingen om te gaan. Componenten worden dan voorzien van meta-informatie over wat een component doet, hoe deze te gebruiken en welke aannames de component bevat over zijn omgeving. Doordat deze informatie expliciet is en samen met een component geleverd wordt, kan hier bij het gebruik van de component in verschillende omgevingen rekening mee worden gehouden. Deze aanpak wordt o.a. door Microsoft toegepast in haar .NET-technologie. Een ander voorbeeld van deze aanpak is XML, dat gericht is op het expliciet maken van aannames over de inhoud en structuur van de communicatie tussen componenten.
Zelfbeschrijvende componenten nemen een aantal belangrijke technische problemen weg, maar de essentiële problemen blijven: hoe leg je de semantiek van een component precies vast, welke informatie is precies nodig, hoe gebruik je die informatie, enzovoort.
Aspect-oriented programming
Aspect-oriented programming (AOP) en aanverwante technologieën geven mogelijkheid om aspecten als logging expliciet en onafhankelijk te modelleren en implementeren. Normaal gesproken zijn deze aspecten sterk verweven met de rest van code en dus moeilijk aan te passen. AOP-tools zorgen ervoor dat code en aspecten automatisch en op correcte wijze gecombineerd worden. Op deze wijze zou het gebruik van AOP de veranderbaarheid kunnen verbeteren. Hoe AOP precies te gebruiken is echter nog niet duidelijk.
Verbeteren van veranderbaarheid van bestaande systemen
Het verbeteren van de veranderbaarheid van bestaande systemen is een moeilijk probleem dat steeds belangrijker wordt. Systemen weggooien en opnieuw bouwen is niet aan de orde, omdat het vaak gaat om bedrijfskritische software.
Een veelgebruikte aanpak is het inpakken van bestaande systeemcomponenten. Bestaande systemen zijn vaak innig met elkaar verweven. Met behulp van middleware-oplossingen kunnen de systemen in zekere mate losgekoppeld worden. Wat middleware niet kan oplossen zijn subtiele afhankelijkheden zoals impliciete aannames over semantiek die in de systemen verwerkt zitten.
Een interessante ontwikkeling om bestaande systemen verbeteren is het herstructureren van systemen om ze beter aanpasbaar te maken. Hoewel het herstructureren van legacysystemen nog in de kinderschoenen staat, zijn er al wel interessante ontwikkelingen, zoals onderzoek op het gebied van het automatisch herstructureren van COBOL/CICS systemen, het gebruik van aspect-oriented programming om bestaande code uit te breiden en het FAMOOS-project dat onderzoek heeft gedaan naar reengineering van objectgeoriënteerde software.
Het omgaan met verandering is volgens ons een van de grootste kopzorgen voor softwarearchitecten. Oplossingsrichtingen zoals hierboven geschetst bieden op termijn wellicht soelaas, maar om meer grip te krijgen op de problematiek moeten we meer leren over veranderingen, wat voor soort veranderingen zich kunnen voordoen, met welke waarschijnlijkheid en frequentie, wat de impact is van veranderingen, enzovoort. Op basis van deze kennis kunnen we vervolgens bepalen op welke veranderingen geanticipeerd kan worden, hoe er kosteneffectief mee om te gaan en - als het niet loont of niet mogelijk is om te anticiperen - hoe een architectuur flexibel op te zetten.