Sharing IT Best Practices with youSharing IT Best Practices with you
Control in Pipeline
Met de komst van DevOps is het begrip ‘pipeline’ erg in zwang geraakt. Het betreft hier de hele flow van requirement tot en met in productie name van een solution of een aanpassing daaraan. Zowel mensen, methoden als middelen worden op een efficiëntie en effectieve manier aan het werk gezet om business value op te leveren door deliverables voort te brengen via de traditionele ontwikkel-, test-, acceptatie- en productieomgeving die vooral zo veel als mogelijk geautomatiseerd wordt. Maar hoe zit het nu met de beheersing en besturing (control) van het op deze manier vormgegeven ontwikkel- en beheerproces?
Dit artikel is eerder verschenen op 18 oktober 2019 op IT Executive.
Traditioneel is de control belegd in strak geprotocolleerde beheerprocessen zoals change management van ITIL en de processen van Prince2®. De toekenning van de functies zoals project manager, change manager en release manager, die zelf geen deel uitmaakten van het voortbrengingsproces, moesten borgen dat de control geïmplementeerd en verantwoordbaar was. Met de komst van het Agile werken zijn deze controls echter steeds meer losgetrokken van deze functionarissen. Het zijn vaak rollen, en zelfs alleen taken, die toebedeeld worden aan deelnemers van de DevOps teams. De control moet uitgeoefend worden door de DevOps teams zelf en waar mogelijk verankerd worden in geautomatiseerde stappen in de pipeline, waarbij het normenkader geborgd is in de Definition of Ready (DoR) DoR en de Definition of Done (DoD).
Deze loskoppeling heeft veel voordelen omdat deze mensen met de vakkennis aangaande de deliverables nu zelf goed moeten nadenken over het in control zijn. Zo moet security een integraal onderdeel vormen van de flow. Dus vanaf non functional requirement, of operationele requirement zoals dat tegenwoordig heet. Dit geldt ook voor de continuïteit, beschikbaarheid, performance en capaciteit. De vraag is alleen of een DevOps team van maximaal negen mensen al deze competenties diepgaand genoeg kunnen beheersen om de juiste keuzes te maken. Ook is de vraag of de DevOps engineers deze competenties zich wel willen eigen maken!
En ten slotte is het nog maar de vraag of er ook zoiets als een ‘span of knowledge’ geldt, of wel de maximale hoeveelheid aan kennis en kunde die van een E-shaped (multiple expert) DevOps expert verwacht mag worden. Het antwoord op deze vraag is, zo is mijn ervaring, dat de control dan wel in de pipeline moet komen, omdat het een willekeurig DevOps team nog ontbreekt aan de nodige kennis en kunde. De pipeline is echter nog niet volwassen genoeg, vooral vanwege de onvolwassenheid van het DevOps team. Aan de andere kant komt het managers soms eigenlijk te goed uit dat er nu één team is dat integraal verantwoordelijk is voor alles. Door deze factoren ontstaat er frictie tussen de verwachting van de prestaties van het DevOps team en de gerealiseerde serviceverlening.
Ik geloof alleen in kwaliteitsmanagers die met de voeten in de modder staan. Het moeten kwaliteit coaches zijn die in zeer concrete vaktechnische taal aan de DevOps teams uitleggen hoe ze concreet control in de pipeline kunnen (of moeten) aanbrengen en dus niet meer de managers die roepende zijn in de woestijn of generaals zonder leger. Bij voorkeur zijn het de nieuwe scrum masters die E-shaped zijn in kwaliteit competenties. Zij moeten over ontwikkel- en beheervaardigheden beschikken om mensen uit te leggen hoe de pipeline tools, way-of-working et cetera aangepast moeten worden om te komen tot de juiste control in de pipeline.
In veel gevallen is dat nog niet genoeg en is er ook nog een corporate DoD nodig waarin de verplichtingen van de organisatie naar de buitenwereld (lees W&R) zijn vertaald naar ontwikkel – en beheerproceseisen. Daarbij zou de DoD bij voorkeur uit vier control onderdelen moeten bestaan:
Deze vier control segmenten van de DoD zouden samen de eisen moeten omvatten die aan de pipeline worden gesteld. Daarmee is de control gedefinieerd en meetbaar geworden zodat het afleggen van verantwoording mogelijk is. De check op de DoD borgt in dat geval dat de control in de pipeline verankerd is en geeft een duidelijke en overzichtelijk definitie van de vereiste externe beïnvloeding op het DevOps team.
Een visie zoals hierboven besproken vereist een gedegen implementatie. Een goede weg om te bewandelen is om aan te haken bij de gebruikelijke acht stappen van Kotter. Een extra idee om naar te kijken is het minder bekende veranderparadigma zoals in figuur 1 weergegeven.
Figuur 1 Veranderparadigma.
Beeld. De beeldvorming is de eerste stap bij een verandering. Hierbij wordt vastgesteld of de stakeholders die betrokken zijn bij de verandering dezelfde beeldvorming hebben van waar ze nu staan en waar ze heen willen. Zij moeten de high level requirements opstellen van de eindsituatie. De huidige situatie (Ist), de gewenste situatie (Soll) en het migratiepad moeten worden verkend. Hierbij speelt architectuur een belangrijke rol.
Macht. Nadat overeenstemming is bereikt over de route is het belangrijk om vast te stellen wie het voor het zeggen heeft. Wie is de eigenaar van de betrokken services, producten, processen en dergelijke. Dit eigenaarschap is essentieel om lange discussies te voorkomen en om resources te kunnen claimen voor de inrichting en verrichting van de gekozen richting.
Organisatie. De werkwijze wordt pas bepaald als duidelijk is wat het beeld en de macht inhouden. Dit scheelt heel veel discussies over de Way of Working (WoW).
Resources. In de laatste stap wordt pas gekeken waar de verandering in de organisatie moet landen en welke functie, rollen, taken en tools er nodig zijn.
Bij een discussie over de resources moet deze gestopt worden en nagegaan worden of de macht wel duidelijk is bij de betrokkenen. Dit geldt ook bij een discussie over de WoW, waar dan twee stappen terug moet worden gegaan en moet worden vastgesteld of de beeldvorming duidelijk is. Bij de laatste discussie over macht is er maar één stap terug te gaan en dat is naar de beeldvorming.
Ter illustratie volgt hier een voorbeeld invulling van het paradigma van de verander manager. Figuur 2 geeft een plaat weer die in een workshop van de denkbeeldige organisatie Assuritas is gebruikt. Alle stakeholders zijn uitgenodigd om in een uur tijd te brainstormen over de vier perspectieven van het veranderparadigma. Het was niet toegestaan om te discussiëren. Per perspectief zijn de meningen gevraagd en met post-its op een whiteboard geplaatst. De verschillen van inzicht zijn vastgesteld en in een aantal workshops met de betrokkenen uitgediscussieerd. Het resultaat is in de figuren 3, 4, 5 en 6 weergegeven.
Figuur 2. De basisplaat van control in de pipeline bij Assuritas.
De eerste brainstormsessie betrof die van de beeldvorming. Al snel werd duidelijk dat control een zeer breed begrip is en dat het niet in control zijn enorme consequenties heeft voor Assuritas. Ook bleek dat iedereen vond dat je hier tot in het oneindige in door kan schieten. Economisch omgaan met control werd dan ook als een rode draad gezien in de beheersing. De beste wijze hiertoe werd gevonden in het automatiseren van controls, hergebruik van gevonden oplossingen en beperking van de controls door de gates van de product backlog en de corporate DoD. Tot slot was de eis dat het in control zijn, geborgd dient te worden door fast feedback met uitstekende traceability. Figuur 3 geeft de belangrijkste bevindingen van de brainstormsessie en de daarna gevoerde workshops.
Figuur 3. Control beeldvorming.
De macht was zoals bij veel organisaties ook bij Assuritas een heikel punt. De brainstormsessie was kort maar de vervolgsessies duurden langer. De macht van de stakeholders was de belangrijkste discussie. Tenslotte is gekozen voor een Corporate DoD waarin de control requirements van de stakeholders worden geplaatst als deze organisatie breed van toepassing zijn. De invulling van de Corporate DoD is conform de Kotter aanpak vormgegeven, waarbij vooral aandacht is gegeven aan de guiding coalition en de communicatie.
Figuur 4. Control macht.
De brainstormsessie leverde al snel een goed beeld bij de organisatie van de control. De zelfstandigheid van de DevOps engineers is evident. Edoch de kennis en kunde ten aanzien van de controls, en hoe deze te implementeren, zou te snel leiden tot versplintering en daarmee waste creëren. De zelfstandigheid van de DevOps engineers kan gehandhaafd blijven mits deze DevOps engineers hecht samenwerken in een control guild waarin oplossingen voor control worden gedeeld en gechallenged.
Figuur 5. Control organisatie.
De laatste stap was evident en snel besloten. Het tool portfolio mag niet versnipperd raken en de oplossingen moeten deelbaar zijn. Wel is er nog het risico van fraude dat een vier-ogenprincipe vereist.
Figuur 6. Control resources.
Nadat de vier stappen van het veranderparadigma waren vastgesteld werden de principes meegegeven aan de guiding coalition die de verandering bestuurt. Het veranderparadigma werd door de guiding coalition breed gecommuniceerd door gebruik te maken van posters, townhall meetings en aanwezigheid in de Control Guild. Tevens werden Hackathons georganiseerd op oplossingen te vinden voor moeilijk te implementeren Control requirements. Daarmee was de control in de pipeline binnen een jaar grotendeels af en de waste maximaal gereduceerd. Vooral het enthousiasme van de DevOps engineers heeft gezorgd voor vele positieve side effects zoals kennisdeling op vele vlakken en saamhorigheid.
Deze casus geeft een voorbeeldinvulling van de in dit artikel voorgesteld visie om control in de pipeline te krijgen. Het risico van kennisgebrek is in de casus gecompenseerd in de vorm van de Control Guild. Er zijn ook andere oplossingen denkbaar. De betrokkenheid van de specialisten in de Control Guild is een prima oplossing omdat hiermee een gelijkwaardige communicatie mogelijk is waar coaching eenvoudig is in te weven. De borging van wet- en regelgeving is ook in deze casus vormgegeven in de zin van een corporate DoD.
Hierbij dank ik Niels Talens voor de review van dit artikel. Meer informatie over het gestructureerd vormgeven van DevOps kunt u nalezen in mijn publicatie DevOps Architectuur.
Discussieer mee op ITpedia LinkedIn of op Financial Executives LinkedIn. Mogelijk is dit een vertaling van Google Translate en kan fouten bevatten. Klik hier om mee te helpen met het verbeteren van vertalingen.