Configuratiemanagement (CM) is niet meer weg te denken uit de hightech. De evolutie in productontwikkeling, ontwikkelprocessen en ondersteunende tools en de opkomst van uitbesteding hebben de afgelopen jaren voor een aantal verschuivingen gezorgd in het CM-landschap. In dit artikel geven Pascal van Kempen en Sander Mathijssen van Philips Healthcare hun visie op deze veranderingen.
In de vijftiger jaren van de vorige eeuw zag configuratiemanagement (CM) het levenslicht als discipline binnen de hardwareontwikkeling, in eerste instantie vooral binnen de Amerikaanse luchtmacht. Destijds was het vooral van belang om wijzigingen in versies vast te leggen om zodoende het productieproces te beheersen en problemen snel op te lossen door te kijken naar de gemaakte aanpassingen. Een voorbeeld dat ook nu nog regelmatig het nieuws haalt, zijn de terugroepacties van autofabrikanten, die aan de hand van een probleem precies kunnen aangeven welke wagens terug moeten komen naar de garage. Zonder CM zou dit niet mogelijk zijn.
Toen de softwareontwikkeling opkwam, leidden de goede ervaringen met hardware-CM al snel tot de geboorte van software-CM. Zeker in het begin waren de principes uit de hardwarewereld een-op-een te hergebruiken omdat de software direct verbonden was met de hardware. Met de introductie van nieuwe technologieën, zoals snellere processoren, standaard componenten en intelligente programmeertalen, ging de softwareontwikkeling echter steeds meer een eigen leven leiden. Het aantal te managen bestanden groeide explosief, architectuur en structuur werden steeds belangrijker en ook de ontwikkelsnelheid van software lag al snel vele malen hoger dan die van hardware.
Passend pakket
Parallel aan deze groei zijn ook de ondersteunende tools voor CM verder geëvolueerd. Command line-interfaces hebben plaatsgemaakt voor grafische interfaces en de koppeling met diverse ontwikkelomgevingen is nu standaard geworden. Ondersteuning voor parallelle productontwikkeling, feature-based development, defect tracking en complexe merge-scenario‘s zijn vandaag de dag niet meer weg te denken uit de CM-toolset.
Het is ook al langere tijd mogelijk om ontwikkelactiviteiten voor meerdere locaties te ondersteunen. In eerste instantie gebeurde dat onder de verantwoordelijkheid van het bedrijf zelf, waardoor het vanuit de techniek betrekkelijk eenvoudig was om alles aan elkaar te knopen. Het netwerk, de ontwikkelomgevingen en het intellectuele eigendom van de code waren immers allemaal van dezelfde partij. Door bedrijfsbrede standaarden in te voeren, werkte iedereen bovendien op dezelfde manier. Dit maakte de integratie van de diverse onderdelen een stuk eenvoudiger.
De opmars van outsourcing bracht hier verandering in. In eerste instantie hielden de diverse betrokkenen hun ontwikkelomgevingen strikt gescheiden, maar al snel zag een nieuwe vorm van softwareontwikkeling het levenslicht: collaborative development. De broncode staat ’ergens in de cloud‘, waarbij toegang, beheer en CM worden geregeld via een webinterface. Deze manier van software ontwikkelen is overigens niet nieuw; ze is lean-and-mean overgenomen uit de opensourcegemeenschap. Voor bedrijven is deze aanpak echter minder evident. Zij staan niet altijd even hard te springen om de code en het intellectuele eigendom van hun producten ’ergens in de cloud‘ neer te zetten en het beheer deels uit handen te geven.
Inmiddels gaat CM-ondersteuning veel verder dan alleen versie- en databeheer. Behalve defect tracking bevatten de nieuwste pakketten ook mogelijkheden voor planning en tracking, automatisch bouwen en/of continue integratie en kennisdeling, bijvoorbeeld via wiki‘s, instant messaging of discussiefora. Sommige bieden zelfs al volledige ondersteuning voor de diverse Agile- en watervalworkflows, uiteraard met een naadloze koppeling naar het versiebeheer. Tel daar de integratie met diverse ontwikkel- en productieomgevingen bij op en het wordt duidelijk dat er meer en meer totaalpakketten beschikbaar zijn die vrijwel de gehele levenscyclus van producten ondersteunen. De uitdaging voor CM zal dan ook worden om het passende pakket te vinden bij de wensen en behoeftes van de ontwikkelafdelingen.
CM-roots
Niet alleen de CM-tools hebben zich flink ontwikkeld, ook de werkwijze is zowel sterk uitgebreid als veranderd. Configuratiemanagement is in de loop der jaren binnen diverse sectoren een erkende discipline geworden. Onder invloed van certificeringen, normeringen, reguleringen en procesmodellen, zoals Nen, IEC, FDA en CMM(I), zijn de CM-processen steeds verder verbeterd. Er is meer nadruk komen te liggen op de controle van die processen zelf en de toetsing aan de normen waaraan de organisatie dient te voldoen.
Waar CM in het begin vooral bezig was met operationele zaken, gaat het nu vooral om het beheersen van het hele proces eromheen. Het vak van configuratiemanager is daardoor heel veelzijdig geworden: onderhouden van de processen, controleren van de processen via status accounting en auditing, implementeren en onderhouden van ondersteunende tools en onderhouden van contacten met de diverse disciplines waar CM mee te maken heeft.
CM is ook een volwaardige gesprekspartner geworden op het gebied van roadmap- en architectuurkeuzes. In het verleden was de (vaak monolithische) architectuur een-op-een te implementeren in een CM-omgeving. Hierdoor kon een architect de CM-overwegingen eenvoudig meenemen bij het bepalen van strategische keuzes. De architectuur is echter complexer geworden, net als de manier van ontwikkelen (parallel, featuregebaseerd, de introductie van productlijnen). CM-systemen hebben veel functionaliteit gekregen om in de nieuwe behoeftes te voorzien. Door dit alles is het vertalen van de gebruikerswensen naar een CM-implementatie een vak op zich geworden. De configuratiemanager reeds in een vroeg stadium betrekken bij architectuur- en roadmapkeuzes voorkomt dat het gekozen CM-systeem op termijn een bottleneck wordt bij de implementatie van de gemaakte keuzes.
De multidisciplinaire rol van CM heeft er mede toe geleid dat de aandacht van de configuratiemanager aan het verschuiven is van software naar het gehele product. Hardware staat ook weer volop in de schijnwerpers. Daarmee keren we als het ware terug naar onze CM-roots. Tegenwoordig gaan we wel een stapje verder. Zo maken de papieren archieven langzaam plaats voor digitale documentmanagementsystemen. De grote uitdaging is om hier ondersteunende CM-processen voor te definiëren, want zo gemakkelijk als we parallelle projecten in softwareland kunnen ondersteunen met branching en merging, zo lastig is dat voor documenten, spreadsheets en tekeningen.
De afgelopen decennia hebben we in de CM-wereld veel nieuwe kennis en ervaring opgedaan. Na de nodige omzwervingen kunnen we configuratiemanagement beter en efficiënter uitvoeren op meer en complexere producten dan voorheen. De uitdagingen liggen vandaag de dag op het vlak van interdisciplinair samenwerken en het opzetten en implementeren van een integraal CM-proces.