The Phoenix Project recensie

Waarschuwing vooraf: deze recensie bevat een aantal kleine spoilers.

In The Phoenix Project maken we kennis met Bill Pallmer, een netwerkspecialist die plotseling gepromoveerd wordt tot VP Technology voor Parts Unlimited. Dit bedrijf produceert en verkoopt auto-onderdelen, maar echt succesvol is het bedrijf niet. De concurrent is namelijk marktleider geworden waardoor Parts Unlimited genoodzaakt is om het bedrijf nieuw leven in te blazen.

Speciaal ontwikkelde software met de codenaam Phoenix moet ervoor zorgen dat het bedrijf overleeft, maar het wil niet vlotten met het project. Bill krijgt 90 dagen de tijd om te overleven. Lukt het niet, dan wordt hele IT-operatie geoutsourcet. Met behulp van een mentor slaagt Bill er uiteindelijk in om de ‘Three Ways’ toe te passen – een soort managementfilosofie en integratie die doet denken aan de lean-methodologie. 

Hoewel het woord DevOps nooit expliciet door een personage wordt genoemd, wordt het wel suggestief uitgelegd wat DevOps is. En dat was exact waarom ik het boek heb opgepakt. Het werd me aangeraden door een collega toen ik vroeg wat de definitie was van DevOps. Hoewel die term nergens in het boek naar voren komt, heb je na het einde van het verhaal wel een idee welke kant het opgaat en kun je een eerste voorzichtige definitie voor jezelf maken.

Medelijden 

Vanaf de eerst bladzijde 1 krijg je al medelijden met Bill. Hij wordt overtuigd (of nouja, bijna gedwongen) door de directeur van het bedrijf om het IT-soepzooitje van zijn voorgangers op te ruimen. En wel binnen 90 dagen, want anders wordt de IT-operatie geoutsourcet. 

Al vrij snel wordt duidelijk dat niet alleen de directeur, maar ook de rest van de organisatie vrij weinig verstand heeft over hoe IT verwikkeld is in bijna alle processen van het bedrijf. Het duurt dan ook niet lang voordat Bill en het nieuwe team dat hij leidt de eerste problemen tegenkomen: het salarisuitbetaalsysteem (is dat een woord?) vertoont mankementen. Personeel in de fabriek zou niet op tijd betaald kunnen worden en dat zou verschrikkelijke media-aandacht met zich meebrengen. Bill en zijn team van change managers, projectmanagers en engineers zetten alles om uit te zoeken wat het probleem veroorzaakt. Het probleem blijkt te zitten in een wijziging in de databasesoftware die niet goed getest is en vrij klakkeloos op de live-omgeving is doorgevoerd, zonder dat de systeembeheerders van Bill er weet van hadden. 

Zenuwstelstel 

Zonder al te veel te verklappen weet Bill uiteindelijk het probleem op te lossen, maar het duurt niet lang of de volgende problemen stapelen zich weer op. Zo hijgt compliance in de nek van IT op security-fixes op te lossen en marketing omdat zij een nieuwe campagne willen lanceren waar zij ook de hulp van IT nodig hebben. IT is het zenuwstelsel van het gehele bedrijf maar er is geen duidelijke grip in het aantal wijzigingen dat gedaan wordt of de hoeveelheid werk die verricht moet worden. 

Three Ways

Op een zeker moment krijgt Bill een steuntje in de rug van Erik, die verder optreedt als zijn mentor. Erik neemt Bill mee naar een tripje in de fabriek waar de auto-onderdelen geproduceerd/geassembleerd zijn. Volgens Erik is IT net zo’n proces als fabriceren, en bestaat het uit Three Ways (weg). Dit wordt ook wel de ‘Three ways of DevOps’ genoemd. 

De eerste weg 

De eerste weg is dat werk altijd vloeit naar een richting toe ‘downstream’

Net als een fabriek een lopende band heeft, waar de auto-onderdelen geassembleerd worden. Het leveren van software of het leveren van en IT-dienst is volgens Erik hetzelfde. In de eerste weg zou geen enkel defect de ‘assemblagelijn’ verderop mogen en moet er altijd gekeken worden naar het verbeteren van de ‘flow’. Een belangrijk onderdeel is inzicht, zodat je kunt signaleren waar de bottleneck voor vertraging op de assemblagelijn zorgt. 

Dit klinkt misschien ontzettend cryptisch en een fabriek lijkt misschien een vreemde metafoor voor en IT-operatie. Maar eigenlijk is het een hele logische. Belangrijkste punt is dat je zonder inzicht niet kunt zien waar de problemen voortdoen. Een ander punt wat me bij is gebleven is ‘work in progress’. Als er een defect plaatsvindt op de assemblagelijn, stapelt de inventaris op het volgende product te maken zich op. Gevolg is de flow niet soepel genoeg gaat. 

Hoe vertaalt dit zich naar IT? Eigenlijk heel simpel. Bill en kornuiten komen erachter dat ze geen idee hebben hoeveel wijzigingen ze moeten maken, omdat er al in tijden geen change meetings zijn geweest waarin beoordeeld wordt welke wijzigingen er gemaakt moeten worden. Er is wel een systeem, maar niemand gebruikt het waardoor er geen zicht is op het aantal wijzigingen. Ze nemen dus flinke maatregelen om het op te pakken.

De tweede weg

De tweede weg gaat over het creëren van korte feedback loops op het geleverde werk. Het gaat met name over het inwinnen van informatie waarmee je direct iets kunt. Door IT in kleine stapjes door te voeren ontstaat er beter inzicht. De meeste mensen kennen dit denk ik als sprints.

De derde weg 

De derde weg gaat over een culturele verbetering. Een cultuur van continue experimentatie, leren van succes en falen en het vinden van meesterschap door constant te oefenen. Dat laatste werd door hoofdpersoon Erik ‘kata’ genoemd, wat in het Japans herhaling wordt bedoeld. Door incrementele wijzigingen door te voeren. Je zou dus kunnen zeggen dat het deployen van software als een spier is – door continu handelingen te herhalen wordt de spier sterker en beter in staat om zwaardere (of in het geval van The Phoenix Project) een behendiger proces te runnen. 

Knipoog naar de Lean beweging

Het boek maakt er geen geheim dat het veel te danken heeft aan The Goal van Goldratt. In dat boek werd voor het eerst het woord ‘bottleneck’ gebruikt. Verdere inspiratie is het Lean-gedachtegoed dat autofabrikant Toyota populariseerde, en waar ook Eric Ries met zijn Lean Startup miljoenen ondernemers wist te stimuleren om deze managementfilosofie toe te passen voor hun onderneming.

Als een ding me duidelijk wordt in dit boek is dat DevOps echt veel meer is dan alleen technologie. Ik besef me maar al te goed dat de term enorm uitgekauwd is, maar dit kan niet vaak genoeg verteld worden denk ik. Je krijgt DevOps niet voor elkaar zonder het te accepteren als een managementfilosofie.

Het is niet moeilijk om te zien hoe dit soort managementfilosofieën hun intrede hebben gedaan in de rest van het bedrijf. Helemaal als je bedenkt dat IT het zenuwstelsel is van het bedrijflseven. En net zoals we het eche zenuwstelsel niet kunnen zien is dat ook vaak niet mogelijk binnen de IT. Volg de drie wegen van DevOps en je ziet ze niet alleen beter, maar je kunt ze ook beter beheersen.

Drie sterren: *** 

Leave a Reply

Your email address will not be published. Required fields are marked *