Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het redactionele gedachtegoed van de redactie.

Configuration management is een vak apart

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.

Configuration management - een vak apart

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.

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/5185791). © Jaarbeurs IT Media.
6,8

 

Reacties

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.


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.

Computable Expert
Pa  Va Ke

Pa Va Ke
Configuration Management / Product Lifecycle Management, -. Expert van Computable voor de topics Development, Beheer en Zorg.
Hele profiel

Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×