Onlangs heb ik een bezoek gebracht aan een conferentie met als thema 'configuration management for complex products'. Eén van de onderwerpen die de revue passeerden ging over het 'verkopen' van het vakgebied configuration management (cm) binnen je organisatie. Tijdens de discussies hierover bedacht ik me dat het vakgebied cm ook binnen de Computable-kringen zelden aan bod komt, met onderstaand artikel tot gevolg.
Veel van de lezers zullen configuration management wellicht kennen als onderdeel van ITIL of ITSM. Echter, ook binnen systems engineering kennen we de discipline configuration management. De historie van deze variant gaat terug naar halverwege de vorige eeuw, waar het Amerikaanse ministerie van defensie configuration management gebruikte voor het beheren van hun hardware configuraties.
Deze aanpak is in de loop der jaren verder uitgegroeid en wordt vandaag de dag ook veelvuldig toegepast bij het ontwikkelen van software. Dit klinkt misschien als een verrassing voor sommigen, maar bijna iedereen die wel eens software geschreven heeft, heeft hiermee (al dan niet bewust) te maken gehad.
Een heel simpel voorbeeld wat we allemaal wel kennen:
Programma_v0.0.cpp
Programma_v0.1.cpp
Inderdaad, de basis van configuration management ligt in het versiebeheer. Dit voorbeeld laat echter ook meteen het probleem zien van deze aanpak: voor iedere versie verandert de naam van het bestand. Niet handig dus omdat je dan telkens de verwijzingen aan moet passen.
Gelukkig zijn er diverse pakketten die ontwikkelaars hierbij kunnen ondersteunen. Met behulp van deze pakketten verwijs je altijd naar programma.cpp, en wordt op de achtergrond zorg gedragen voor versiebeheer. Deze tools bieden ook diverse extra’s, zoals kunnen vergelijken met vorige versies, toevoegen van commentaar wanneer een nieuwe versie in het systeem gezet wordt et cetera.
De uitdaging komt echter pas als je gebruik gaat maken van functionaliteiten als branching en merging. Hiermee kun je onder andere parallelle ontwikkeltrajecten uitvoeren, maar deze technieken worden ook gebruikt wanneer men meerdere versies van eenzelfde product moet onderhouden (lifecycle management).
Configuration management gaat dan niet alleen meer over versiebeheer, maar ook over het maken van strategische keuzes hoe de diverse productlijnen te kunnen ondersteunen. Combineer dit met complexe producten (miljoenen regels code, verdeeld over meerdere subsystemen) en levensduur van software die de tien jaar met gemak overstijgen, dan begint vaak pas het besef te komen dat configuration management een vak apart is, waarbij reproduceerbaarheid voorop staat.
Wanneer ik dat uitleg, krijg ik vaak de vraag waarom je configuration management zou moeten doen. Hiervoor gebruik ik graag bijgevoegde illustratie. Dit heeft weliswaar niets met softwareontwikkeling van doen, maar laat heel simpel zien wat er kan gebeuren als diverse partijen met verschillende versies van een bestand (in dit geval een bouwtekening) werken.
Voor de meeste lezers zal het weinig moeite kosten deze parallel door te trekken naar softwareontwikkeling.
CM is in feite een eco systeem en gaat veel verder dan een simpel component. Het gaat om het geheel aan sources en resources en de relaties daartussen. Een goed voorbeeld is de app store van Apple waar CM standaard in is geïntegreerd, volledig automatisch. Software wordt alleen op de devices die worden ondersteund geïnstalleerd en gebruikers kunnen hier geen keuze in maken.
Andere herkenbare eco systemen zijn de autoindustrie, waar CM integraal is ingevoerd, al jaren.
Dat is vaak anders bij de Microsoft producten. De melding ‘deze software werkt mogelijk niet goed samen op dit product is dus helemaal fout’ en daardoor krijg je problemen. CM moet dus ook by design zijn om goed te worden geïmplementeerd. In Itil is CM een nobel streven en vaak niet meer dan asset management, assets waarvan de capabiliteit meestal niet bekend is.
Boeiend vakgebied, CM.