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.
Tja, en CM is niet alleen iets als ITIL en SW management maar ook Product configuratie management.
Denk maar eens aan je laptop, welke onderdelen zitten daar allemaal in en hoe weet je welke onderdelen vervangen kunnen worden.
En welke identifikatie heeft dat onderdeel, mogelijk heeft het onderdeel ook verschillende versies.
Dan kom je met CM al snel in de buurt van het product Lifecycle Management concept.
@Maarten: klopt, het vakgebied CM kent vele gezichten en is een must wil je optimaal profiteren van Product Lifecycle Management
Het gaat zelfs nog wat verder terug in de tijd en buiten het vakgebied van ICT: as_n, as_n+1 en daarmee meteen de vragen ‘past as_n+1 nog in lager_n’ of, erger nog: past as_n+1 ook in lager_n-1?… Backward compatibility is een concept wat in de mechanische engineering zeer bekend is, evenals revisie- (versie-) beheer.
En denk je de logistiek van een leger in: past kogel x in pistool en/of geweer y?
Wat me veel meer verbaast is dat geen van de genoemde (en geen van de mij bekende) methodieken in ITIL / ITSM daadwerkelijk iets zeggen over het opzetten van een goed generiek config-model. Processen te over, maar elke beheerorganisatie en elke pakket-boer gaat bij iedere implementatie wederom een flink groot en complex wiel uitvinden. Is erg fijn als je per uur mag factureren, dat natuurlijk wel….
Pascal, het zou zeker interessant geweest als je jouw verhaal nog wat verder zou uitdiepen.
Loop af en toe wel eens tegen dit soort issues aan…
@Pascal … ik kan hier uren over vertellen hoor, maar wilde eerst eens proefballonnetje oplaten om te kijken of dit onderwerp enigszins leeft onder de computable lezers.
CM is een van die dingen waaraan je de volwassenheid van een organisatie af kan leiden. Als het niet goed geregeld is dan kost het veel tijd en vertraagt het projecten.
Maar vooral de laatste jaren zijn er veel softwarepakketten in zwang geraakt en is automatisering van CM stukken makkelijker geworden. En zijn de betere IDE uitgerust met ondersteuning op diverse aspecten voor CM. Want wat dat betreft is CM vaak ook goed te automatiseren. Boven dat staat en valt CM met de consistentie van de gebruikers.
Meen me te herinneren dat ik onderwerp CM regelmatig op de agenda heb gezet in opinies omdat het een essentieel onderdeel is van IT governance framewerken:
http://www.isaca.org/Groups/Professional-English/test-topic-for-isaca-employeespbwb9qf12/GroupDocuments/Configuration-Management-Using-COBIT-5_res_eng_0913_4.pdf
@Ewout: misschien komt het dat ik niet al je artikelen lees.
Maar het stuk CM waar jij naar verwijst is (wat ik zo snel kon zien) vooral gebaseerd op asset management. De CM tak waar ik op doel gaat meer over bijvoorbeeld source code management tijdens ontwikkeling.
Pascal, leuke opinie. Wat dat betreft weet je altijd dingen op een originele manier onder de aandacht te brengen…
Als ik meteen de cloud erbij mag betrekken.
Tegenwoordig deploy je oplossingen over meerdere virtuele servers die pas aangezet worden als ze nodig zijn, maar ook weer uitgezet worden. Dit voegt een extra dimensie toe aan webapplicaties voor de cloud. Waar je vroeger op 1 plek de configuratie regelde is die plek nog wel centraal, maar naar een abstracter niveau getild. Het gevolg is dat het aanpassen van de configuratie in een always-on situatie die ook nog eens gedistribueerd is best uitdagend kan zijn.
Het vakgebied is alleen niet sexy, en het is in feite net zo’n hygiëne product als security. Het goed regelen kost geld, maar levert niet direct iets op.
@Henri
Inderdaad, het vervelende van CM is dat het vaak pas geld kost als je het niet / niet goed doet.
Een leuk voorbeeld wat ik een keer gehoord heb kwam uit een fabriek, waar een bepaald proces nogal wat afval op leverde. Hiervoor was een nieuw proces gedefinieerd, maar de werkinstructie was nooit bij de gebruikers aangekomen.
Doordat de mensen in de fabriek nog steeds met de verouderde versie werkten, was de beoogde efficiency/kostenbesparing (minder afval) nog steeds niet behaald.
Op zo’n moment kun je als configuration manager heel makkelijk inzichtelijk maken wat het kost als je het niet op orde hebt.