The Phoenix Project

Med en undertitel som: “A Novel about IT, DevOps, and Helping You Business Win”, så er det her en bog, som jeg rigtigt gerne vil knus-elske. Den handler om et fiktivt produktionsfirma et uglamourøst sted i USA. Her er IT-afdelingen af den ret dysfunktionelle slags, som er alt for dyr og leverer alt for lidt. Kvaliteten på driften er i bund og det monumentale IT-projekt, som skal bringe selskabet tilbage i kampen, er planmæssigt kuldsejlet. Det ved alle, men ingen tør rigtigt se realiteterne i øjnene.

ThePhoenixProjectDet er med andre ord tid til at finde en ny syndebuk, og den tidligere midrange-mellemleder Bill Palmer forfremmes til det varme sæde som chef for IT Operations. Herefter går det fra den ene katastrofe til den næste – mens vi følger Bill’s kamp på at få styr på IT Operations i et miljø, som mere end een gang vækker genkendelsens glæde.

Som når IT-driftsfolkene brokker sig over Change Management IT-systemet, der er så inficeret af ufleksible drop-down bokse, langsomme svartider og godkendelses proces-helvede at det helt slår alle gode intentioner om struktur ihjel. Eller når IT-sikkerhedsafdelingen dropper kæmpe-opgaver ned over IT Operations under påskud af at det er bydende nødvendigt for at overholde Sarbanes-Oxley og undgå endnu en revisionsanmærkning. Og ikke mindst når den silo-opdelte organisation glimrer ved at tabe sager i mellemrummet og under hand-off’et mellem to afdelinger. Klassisk og ret forudsigeligt.

Rigtigt farligt bli’r det dog ikke, for Bill har jo sin trofaste væbner: Patty. Hun er tilsyneladende en 24-timers super-struktureret Duracell-kanin af en mellemleder, som lynhurtigt forstår og følger op på hvor Bill vil hen med sin Lean fabriks-metaforer.

De fabriks-metaforer, som Bill ikke mindst får fra den excentriske Eric Reid der, under påskud af at overveje at blive bestyrelsesmedlem, giver kryptiske råd og støtte som en anden Mr. Miyagi-Yoda. Imens bumler sikkerhedschefen John lidt rundt og Bill finder snart ud af hvor højt i systemet hans virkelige fjende sidder.

Det går der så 30 kapitler med – før Bill og resten af produktionsfirmaet er klar til at indse at det er nødvendigt med et tættere samarbejde mellem udvikling og drift. At DevOps-rollen skal defineres og fyldes ud.

Men på det her tidspunkt er bogen så også ved at være slut, så der viftes lidt med hænderne: Se, nu drikker Bill og chefen for udviklingsafdelingen dus – og vupti: Så får vi da langt om længe en lille smule DevOps. Tak for det. Det var på tide.

Bogen er en glimrende gennemgang af hvilke udfordringer, som en uharmonisk IT-organisation står med, når de er ude af takt med den omliggende forretnings behov og krav – og etableringen af en DevOps funktion lanceres bestemt ikke som det ottende vidunder. Det kan jeg godt li’.

At jeg så skal tre fjerdedele gennem bogen før der lidt demonstrativt og uelegant hives en DevOps-kanin op ad hatten med et svirp med håndleddet – det har jeg sværere ved at holde af.

Bevares, det er da en rigtig fin, hvid DevOps kanin – men jeg kunne godt have ønsket mig at der blev dvælet lidt mere ved processen og udfordringerne ved at skabe et DevOps team og en fælles kultur. Det går for nemt – også selvom fortælle-vinkelen sidder på en chef for IT Operations.

Jeg kunne også have ønsket mig en lidt mere farverig persontegning. Der mangler kulør i kinderne på persongalleriet, som reelt alle er statister. Hovedrollen i den her bog er en IT organisation, og den udvikling, som organisationen gennemgår.

Det her er ikke en bog, der vipper “The Soul of a New Machine” af pinden som litterært nørd-epos, men det er dog en bog med noget på sinde: At IT Operations skal handle om at gøre IT tilgængeligt som forretningens helt nødvendigt værktøj i jagten på kunder og succes,

Budskabet leveres så passende direkte at selv ikke den mest tykhovedede driftskonsulent kan være i tvivl om hvad der er moralen i historien. Tak for det, nu har selv jeg vist forstået det.

Dev og Ops samarbejde hos Flickr

I sommeren 2010 så jeg tilfældigvis et sæt vældigt inspirerende slides om samarbejdet mellem udvikling og drift – de var fra et par gutter fra Flickr.

Jeg og en kollega havde på det tidspunkt drøntravlt med at få pudset de allersidste kapitler af en hovedopgave af. Jeg kan huske at vi var enige om at forfatterne til de her slides havde fat i noget. Men vi var også enige i at vi ikke kunne smide halvdelen af vores opgave væk og i stedet jagte et-eller-andet – uanset om “det andet” føltes rigtigt.

Egentligt fik jeg vist aldrig rigtigt registreret hvilken sammenhæng, som de her slides stammede fra eller forfatternes navne. Til gengæld fik vi afleveret hovedopgaven til tiden dengang.

Så da jeg tidligere her i aften stødte på en reference til Allspaw, Hammond og Flickr i The Phoenix Project, så var det et glædeligt gensyn med en stak umådeligt inspirerende slides:

10+ Deploys Per Day: Dev and Ops Cooperation at Flickr

Det gik som sagt ikke op for mig – da jeg så de her slides første gang – at de var blevet præsenteret på en konference, og at indlægget på konference naturligvis var blevet optaget.

Velocity 09: John Allspaw and Paul Hammond, “10+ Deploys Per Day”

Hvis man sidder med drift eller udvikling, og har brug for inspiration eller et spark i røven, så er de her slides altså rigtigt, rigtigt glimrende! Foredraget er også okay – der er naturligvis et par ekstra anekdoter, som i hvert fald fik mig til at nikke genkendende.

En cloudgøglers sæbekasse