CM gaat niet vanzelf, of wel?

21 december 2011

Met de toenemende complexiteit van softwareprojecten wordt configuratiemanagement er niet makkelijker op. Frank Schophuizen van Topic betoogt daarom dat we CM niet meer in isolatie moeten zien, maar beter kunnen kijken naar het ontwikkelproces als geheel.

Oorspronkelijk bestond configuratiemanagement (CM) voornamelijk uit version control, gericht op het beheer van wijzigingen in individuele bestanden. Check-out en check-in, locking en version history waren gangbare concepten. Branches en work spaces kwamen later en maakten ontwikkeling in projectteams en parallelle ontwikkeling mogelijk, labels legden de basis voor baselines en databasereplicatie gaf de mogelijkheid van multisite ontwikkeling - internetconnectiviteit stond toen nog in de kinderschoenen.

Een belangrijke stap voorwaarts was de notie dat wijzigingen van individuele files niet onafhankelijk van elkaar zijn. Door gerelateerde aanpassingen te groeperen in change sets - ook wel tasks of activities genoemd - ontstond task-based CM. En door de change sets te koppelen aan change requests (CR’s) en problem reports (PR’s) werd change management een onderdeel van configuratiemanagement. Een CR/PR doorloopt verschillende stadia volgens een gedefinieerde lifecycle, waardoor we sturing kunnen geven aan de wijzigingen, in de vorm van planning, autorisatie, voortgangsbewaking en vrijgave.

Hiermee is de basis gelegd voor het moderne CM. Met de mogelijkheid om het proces te sturen, komen we op het terrein van andere projectdisciplines, zoals projectmanagement, requirements, design, testen en kwaliteitsbewaking. Dat een configuratiemanager daarbij als volwaardige gesprekspartner moet worden betrokken, blijft echter een omstreden punt. CM-tools worden steeds krachtiger en daardoor ingewikkelder om – goed – te configureren en te gebruiken. Het gevolg is een tweedeling in type CM’ers. Enerzijds de CM-toolexperts en librarians met een operationeel ondersteunende rol en aan de andere kant de CM-procesexperts en integratie- en releasemanagers met een strategische rol. De vraag is nu hoe dit zich verder ontwikkelt.

Sociale interacties

Om inzicht te krijgen in de status van een softwareproject gebruiken veel professionele softwareontwikkelorganisaties CM-informatie zoals CR/PR-overzichten en configuratie-itemlijsten. Om een project goed te kunnen besturen, is er echter behoefte aan integratie met informatie over requirements, designs, tests, beschikbaarheid van mensen en middelen, budgetten en deadlines. Een tester wil bijvoorbeeld weten welke PR’s zijn opgelost, of die oplossingen ook in zijn configuratie zitten, met welke requirements en testcases ze gerelateerd zijn en of daarin inmiddels ook iets is gewijzigd.

Huidige CM-gereedschappen ondersteunen de integratie met informatie uit andere tools maar matig. Veel organisaties lossen dat op met zelfgemaakte scripts en programmaatjes en handmatige procedures. Deze beginnen vaak kleinschalig maar kunnen uitgroeien tot enorme bouwwerken. Onderhoud en support daarvan kosten veel tijd en geld. Deze factoren staan vaak onder druk, waardoor de flexibiliteit om in te spelen op veranderende omstandigheden regelmatig te wensen overlaat. Ik verwacht dat dit de komende jaren gaat veranderen. Zelfgemaakte en handmatige toolintegraties kunnen het evolutietempo van de projecten onmogelijk bijbenen.

Leveranciers spelen hierop in met toolsuites die de gehele project lifecycle weliswaar afdekken, maar waarbij de echte onderlinge integratie van de verschillende onderdelen nog beperkt is. De volgende stap is application lifecycle management (ALM). Daarin zijn de tools functioneel gekoppeld volgens een gedefinieerd procesmodel zoals Scrum. We kunnen bijvoorbeeld vanuit een testcase rechtstreeks requirements en PR’s benaderen of broncode bekijken, ook al worden die met verschillende gereedschappen beheerd. Ook kunnen we story boards, backlogs en burndown charts gebruiken, gevuld met informatie van de ALM-tools. Leveranciers die aan ALM-oplossingen werken, zijn onder meer Collabnet, HP, Polarion en Rally.

Collaborative lifecycle management (CLM) gaat nog een stapje verder. Naast de integratie over de levenscyclus zoals ALM die al biedt, ondersteunt CLM ook de onderlinge samenwerking en sociale interacties in projecten en teams. Het maken van software is tenslotte mensenwerk. Door allerlei sociale media zoals dashboards, fora, wiki’s, blogs, instant messaging, RSS-feeds, tweets en event notifications staat iedereen continu met elkaar in verbinding en blijft iedereen op de hoogte van de actuele stand van zaken. IBM Rational is een belangrijke CLM-speler met zijn Jazz-platform.

Nieuwe rol

Een van de gevolgen van deze geïntegreerde benadering is dat de grenzen tussen de verschillende projectdisciplines en tools vervagen. Roldefinities in een project spitsen zich toe op de specifieke taken en verantwoordelijkheden vanuit het gedefinieerde procesmodel. Project-assets en alle relevante informatie komen beschikbaar waar nodig, onafhankelijk van waar die zijn opgeslagen en met welke tool ze zijn ontstaan.

Het beheer van bestanden en informatie gebeurt dus vooral achter de schermen, vrijwel onzichtbaar voor gebruikers. Het wordt een vanzelfsprekendheid, een functie die overal in zit en niet meer apart als configuratiemanagement is te onderscheiden. Het maakt niet meer uit of we documenten, broncode, planningstaken of gebruikersprofielen opslaan. CM wordt als het ware een commodity binnen de projectomgeving.

Dit betekent niet dat configuratiemanagement verdwijnt. Wel verandert het traditionele CM-landschap erdoor. Zelfstandige CM-tools zoals Clearcase, Synergy of Subversion verschuiven naar het back-end van het ALM/CLM-systeem, worden daarin geïntegreerd of verdwijnen zelfs omdat de functionaliteit al is geïntegreerd. Ook de rollen van operationele configuratiemanager en librarian kunnen geleidelijk verdwijnen uit de projecten omdat gebruikers die taken impliciet zelf uitvoeren. Minder mensen betekent minder kosten. Minder zelfgemaakte integraties betekent minder onderhoud en minder organisatiespecifieke training.

De medaille heeft ook een keerzijde. We kunnen misschien kosten besparen op de projecten, maar we moeten wel de procesflows en datastructuren goed configureren. Voorgedefinieerde procestemplates die een ALM/CLM-oplossing standaard aanbiedt, moeten we afstemmen op de specifieke behoeftes van de organisatie. Denk aan terminologie van projectfases en mijlpalen, attributen bij PR’s of specifieke rapportages. De nieuwe rol van de configuratiemanager omvat dan de gehele projectcyclus, datastructuren en procesflows van alle disciplines. Hij zal dus verstand van de ALM/CLM-tool én de processen moeten hebben, en is op beide vlakken ondersteunend aan projecten.

Open standaarden

Een tweede kanttekening is dat organisaties waarschijnlijk niet gebonden willen zijn aan één toolleverancier. Veel toolsuites en ALM/CLM-producten ondersteunen echter geen alternatieve toolintegraties. Maar ook hier zit ontwikkeling in.

ALM/CLM-oplossingen integreren de onderliggende tools naadloos en kunnen complexe datastructuren en procesflows onzichtbaar voor de gebruiker achter de schermen uitvoeren. Dit is alleen mogelijk als interfaces en protocollen tussen de tools exact op elkaar zijn afgestemd. Eigen en eventueel opensource gereedschappen integreren is voor veel leveranciers nog wel te doen, omdat ze alles in eigen hand hebben. Integreren met producten van andere leveranciers is een stuk lastiger.

Het antwoord hierop is open standaarden. Tools die hieraan voldoen, kunnen wel onderling samenwerken en klanten kunnen eventueel zelf uitbreidingen toevoegen, bijvoorbeeld integratie met een ERP- of een servicemanagementsysteem. Een aantal jaren geleden is de Open Services for Lifecycle Collaboration (OSLC) opgericht, een open community om te komen tot een specificatie van standaarden voor het integreren van lifecycletools. De OSLC-specificaties gebruiken Rest-servicedefinities (Representational State Transfer), waardoor interacties en datakoppelingen over het internet mogelijk zijn. Zo zijn ALM/CLM-platforms op te zetten waarbij de tools, databases en ontwikkelteams over de hele wereld zijn verspreid en applicaties van verschillende leveranciers kunnen worden gekoppeld.

Rational Team Concert van IBM Rational is een CM-applicatie op het Jazz-platform, dat de OSLC-standaarden ondersteunt. Dit product is dus te koppelen aan alternatieve CM-tools. Ook andere applicaties zijn inmiddels beschikbaar op Jazz. IBM loopt op dit moment voorop in ALM/CLM-producten die de OSLC-specificaties, internetconnectiviteit en sociale-mediatechnologie combineren. Het is afwachten wat andere leveranciers en de opensourcewereld zullen doen. Mijn verwachting is dat meer tools en ALM/CLM-platforms de OSLC-standaarden gaan ondersteunen en dat deze standaarden zich verder zullen ontwikkelen.

Niet houdbaar

Ten slotte is het de vraag hoe de softwareontwikkelorganisaties zullen reageren. Blijven ze werken met eigen integraties van tools die op zich steeds krachtiger worden, ook in het opensourcedomein, of schakelen ze over op ALM/CLM-oplossingen? Die zijn veelzijdiger en flexibeler tegen minder kosten, maar de overstap vergt wel een investering.

Om projecten flexibeler, transparanter, sneller en goedkoper uit te kunnen voeren, moeten we de processen en de ondersteunende tools goed op elkaar afstemmen. Voeg daar uitdagingen aan toe zoals geografisch gedistribueerde ontwikkelteams, parallelle ontwikkeling, hergebruik van componenten, platformontwikkeling met productvarianten en onderhoud op vrijgegeven producten en componenten, en we ontkomen niet aan een volledig geïntegreerde en geautomatiseerde oplossing voor project- en configuratiemanagement. Ik geloof niet dat dit met eigen integraties uiteindelijk houdbaar is, maar de grote vraag is hoe lang het duurt voordat we ALM/CLM-oplossingen op basis van open standaarden breed gaan adopteren.

Frank Schophuizen is consultant bij Topic Embedded Systems. Hij is gespecialiseerd in configuratiemanagement.

Frank Schophuizen

Terug naar overzicht