Devops is een reactie op het probleem dat de beheerorganisatie niet is aangesloten op de ontwikkelorganisatie. Dit uit zich vaak in conflicten en inefficiëntie over en weer, ook wel de 'wall of confusion' genoemd. Deze ontstaat door een combinatie van conflicterende motivaties, processen en tooling. Een development team is er op uit om een verandering tot stand te brengen terwijl een beheerorganisatie gebaat is bij (en vaak ook afgerekend wordt op) een stabiele productie-omgeving.
De meeste Agile-implementaties hebben de muur tussen development en business al geslecht, het logische vervolg is om ook de kloof tussen development en beheer te dichten, zodat op die manier een organisatie in staat is om software snel in productie te nemen en effectief te beheren.
Het nut
Organisaties zien dat er veel geld te besparen valt als de ontwikkel- en beheerorganisatie op elkaar zijn aangesloten. Doordat organisaties met Agile-ontwikkelingsmethoden snel en wendbaar wensen van de business kunnen vertalen naar een systeemoplossing, maar vervolgens veel tijd kwijt zijn met het in productie nemen en beheren van de software, is het paard een beetje achter de wagen gespannen.
Als de beheerorganisatie niet in staat is iteratief software in productie te nemen, loopt men nog steeds vertraging op. Devops is een manier om de beheerorganisatie bij het voortbrengingsproces te betrekken door ze een integraal onderdeel van het proces te maken. Hierdoor kan de keten sneller software in productie nemen, worden kosten bespaard en dit kan een groot concurrentievoordeel zijn binnen een markt waar een korte time-to-market van belang is.
Een andere reden voor bedrijven om over te stappen naar Devops is dat de eerder aangehaalde ‘wall of confusion’ een hoop frustraties oplevert die ten koste gaan van productiviteit, samenwerking en werksfeer. Als deze nadelen kunnen worden weggenomen, en hierdoor medewerkers meer werkplezier ervaren, is de opzet in ieder geval gedeeltelijk geslaagd.
Adoptie
Er zijn een aantal grote bedrijven in Nederland die Devops hebben aangenomen als voorkeursmethode voor softwareontwikkeling, het in productie nemen en beheren van software. Voordat je begint, moet eerst het Agile-transformatie- en Scrumproces op orde zijn, omdat de complexiteit van de organisatieverandering anders teveel toeneemt. Naast it en business (wat je in een ‘standaard’ Agile-transitie doet) moet namelijk óók de beheerorganisatie transformeren. Daarnaast is het belangrijk dat het Agile-gedachtengoed volledig is geland binnen de organisatie. Het is beter klein te beginnen en langzaam uit te bouwen om de organisatie te laten wennen en leren. Hierdoor kan je de feedback die je ontvangt gebruiken om het transitieproces te verbeteren waardoor een volgende transitie nog succesvoller kan zijn. Oefening baart kunst.
Vereiste veranderingen
Iedere organisatie zou in principe met Devops kunnen werken, mits je bereid bent de organisatie (ingrijpend) te veranderen. Het doel moet niet zijn op korte termijn een time-to-market probleem op te lossen, maar wel om een it-organisatie vorm te geven die voortdurend in staat is in samenspraak met de business systeemwijzigingen door te voeren en te beheren. Dit kan het verhelpen van incidenten zijn, of het toevoegen van (nieuwe) functionaliteit.
Om DevOps correct te implementeren zijn er op drie gebieden veranderingen nodig:
Meten van cultuurverandering
Als je een cultuur wilt veranderen moet je goed kijken hoe je het resultaat gaat meten en beoordelen. Wat gemeten wordt beïnvloedt het gedrag en vice versa. Het succes van individuen en groepen dient te worden gemeten binnen de context van het succes van de gehele development-beheer cyclus. Voor veel organisaties betekent dit een verandering van kpi’s per silo en/of afdeling vaststellen, naar kpi’s per proces vaststellen. Het is belangrijk dat aan iedereen die deel uitmaakt van een proces duidelijk wordt gemaakt wat hun bijdrage aan het uiteindelijke doel is en hoe hun activiteiten zich verhouden tot andere activiteiten binnen het proces.
Geïntegreerde processen
Binnen Devops dient de gehele development-beheer cyclus als één geïntegreerd proces te worden gezien en vormgegeven. Waarbij het ook als één geheel moet worden gemanaged. Hierbij kunnen verschillende segmenten of subprocessen hun eigen methodes hanteren zolang deze maar samen kunnen worden gevoegd tot één proces op hoofdniveau. In de praktijk betekent dit dat men het eigen ‘eilandje’ moet loslaten. Dit is niet gemakkelijk en zal met weerstand gepaard gaan omdat men bepaalde macht op zal moeten geven ten gunste van het grotere geheel.
Geïntegreerde tooling
Hier lijkt de Devops-discussie zich het meest op te richten. Dit is niet verwonderlijk aangezien het een bijna natuurlijke reflex van techneuten is om meteen een discussie over tooling te starten als er een probleem moet worden opgelost. Want er moet toch een ‘tooltje’ zijn dat helpt dit proces vlot te laten verlopen? Het is belangrijk dat alle individuele tools samenwerken om als keten van tools de procesketen volledig te ondersteunen. Tools moeten voorzien in het automatiseren van handmatige taken (testen, deployment, monitoring, et cetera), beschikken over een software library die onder versiebeheer staat, zodat men in de hele keten met dezelfde gedeelde software configuratie werkt. Daarnaast moet het mogelijk zijn om softwaresystemen zo te modelleren (alle componenten, policies en dependencies zijn beschreven) zodat deze op ieder moment kunnen worden geproduceerd zonder dat dit conflicten geeft met andere omgevingen. Vaak is het beheer binnen organisaties ook van elkaar gescheiden (functioneel applicatiebeheer, technisch beheer, infrastructuur en werkplekken), wat het extra lastig maakt om flexibel met omgevingen om te gaan of om tools uit verschillende domeinen aan elkaar te koppelen. Als organisatie moet je je ervan bewust zijn dat hier veel werk moet worden verricht om alle neuzen dezelfde kant op te krijgen.
Sander de Jonge, Agile-expert bij Bartosz ICT
Bij de eerste zin begint het al te kriebelen, ontwikkeling loopt namelijk ook nog weleens voor de muziek uit zoals we kunnen zien bij veel projecten waarbij de front-office niet aansluit op de back-office. Integraal beheer gaat om een attitude vanuit de organisatie en niet de zoveelste belofte van een verzameling tools.
Natuurlijk kunnen we veel activiteiten binnen het beheer automatiseren mits er bij ontwikkeling al rekening meegehouden wordt. Helaas is dat dus niet het geval en kijken we tot op vandaag nog steeds tegen cryptische meldingen aan in de logfiles, missen essentiele meldingen over de gezondheid van een applicatie of ontbreekt elke overdracht van kennis naar beheer.
In 9 van de 10 gevallen is alle aandacht gericht op de functionele vereisten, er wordt niet of nauwelijk getest op de non-functionele eisen die vaak bepalend zijn voor de beheersbaarheid van een oplossing. Tel daarbij op dat snelle wisselingen ook niet zorgen voor continuiteit in het opbouwen van kennis en het is niet vreemd dat legacy een bewezen trackrecord heeft in betrouwbaarheid.
Nu zijn er gelukkig ook uitzonderingen die de regel bevestigen en de 10% van de projecten die wel rekening houden met beheer zorgen ervoor dat de events geformaliseerd zijn. Dat voorkomt namelijk een wildgroei aan tools, de meeste worden toch altijd weer later toegevoegd om een vergeten requirement rond beheer in te vullen met de genoemde ‘eiland automatisering’ tot gevolg.
Dit euvel is trouwens niet alleen verwijtbaar aan ontwikkeling want ook de business kiest nog weleens COTS software die onder de motorkap een oplossingen hebben die voor beheer problemen zorgt. Platform-, middleware en database keuzen zijn uiteindelijk ook mede bepalend voor de opdelingen die er gemaakt moeten worden in het beheer.
Ook een leuke is dat het technisch beheer in de vorm van infrastructuur steeds vaker uitbesteed is, er is organisatorisch een Chinese muur opgetrokken die het integraal beheer bemoeilijkt. Het is namelijk best lastig om problemen in applicaties te achterhalen als meldingen – al dan niet cryptisch – naar een systeemlog geschreven worden waar je geen toegang toe hebt.
Kortom, voor DevOps moeten uiteindelijk alle sterren in lijn staan en dat is in menige organisatie nog weleens lastig.
Goed verhaal Sander. Je legt wel de focus op puur het IT-stuk, terwijl het logischerwijs te verwachten is dat als Agile de business en Ontwikkeling uitlijnt en DevOps juist Ontwikkeling en Beheer uitlijnt, dat we terug gaan naar een soort lokale IT-voorziening die de primaire processen van de diverse afdelingen ondersteunt. Dus een volledige uitlijning van IT en business! 🙂
Zie ook mijn eerdere Opinie bijdrage over DevOps:
https://www.computable.nl/artikel/opinie/development/4629565/1277180/devops-maakt-af-wat-agile-begon.html
@Ewout: je betoog onderschrijft de noodzaak die Sander schetst. We moeten inderdaad toe naar uitlijning en samenwerking over afdelingen heen. Die uitlijning is er nu niet, en daarom is het zaak dat organisaties zich kritisch over de vraag moeten gaan buigen hoe dat te tackelen. De DevOps gedachte is mijns inziens een belangrijke katalysator daar in.
Echt interessant is natuurlijk wat het het tot nu toe concreet heeft opgelevert. Maken de grote bedrijven die Devops aan hebben genomen meer winst dan andere vergelijkbare bedrijven die nog niet volgens Devops werken? Of kunnen ze b.v. aantoonbaar sneller reageren op ontwikkelingen? Of kun je dat niet goed vaststellen?
@Ewout Kriebelen? Ik krijg overal jeuk als ik dit lees. Dat ontwikkeling en beheer, hoewel twee verschillende taken, gerelateerd zijn is duidelijk en overleg en afstemming is gewenst. Maar dit is vooral een organisatorisch probleem. Dat tools voor het uitrollen van nieuwe software handig kan zijn daaar kan ik het ook mee eens zijn.
Maar als ik ook nog lees dat er iteratief steeds nieuwe brokken snel en vaak in productie te nemen dan denk ik, dat lijkt me niet wenselijk. Iteratief betekent dat je een stap vooruit maakt, weer een stap achteruit maakt om er weer 2 vooruit te maken. Voortschrijdend inzicht. Dat is hoe softwareontwikkeling in elkaar steekt. Daar wil je de gebruiker/klant toch niet mee confronteren? Dat gedeelte aan de buitenkant zou juist incrementeel moeten zijn. Een stap voorwaarts. Maar wil je de gebruiker/klant te vaak steeds met nieuwe software confronteren die eigenlijk niet deugt? Buiten dat iedere uitrol een risico is ook al zet je de hele handel geautomatiseerd in productie. Je moet zeker van je zaak zijn. Dat is ook mijn kritiek op het maar vlug vlug snel snel werken, onzorvuldigheid werk je niet weg met een paar tools. Het is ook opvallend dat een organisatie die ik wat ken en die volgens deze vlug vlug snel hogedrukpan methode werkt grossiert in storingen.
Dat de business bij monde van de productowner de kadans van de softwareontwikkeling bepaalt vind ik al discutabel want er zijn ook gewenste werkzaamheden die geen direct resultaat aan de buitenkant geven. Maar om ook nog je hele ICT organisatie om te toveren tot een grote soep die zich met mantra’s als samen, het team over ‘alles’ verantwoordelijk is? Een scheiding van taken heeft dan toch mijn voorkeur, zolang de organisorische barrieres maar niet in de weg staan.
Misschien toch nog een keer interessant om wat deze Agile specialist te zeggen heeft:
http://blog.cutter.com/2013/12/10/2014-the-failure-of-agile-software-development-is-taken-seriously/
Ook niet alles, incrementeel en iteratief worden naar mening niet helemaal correct gebruikt maar hij doet wel enkele interessante uitspraken over ontwikkeling en de op agile gebaseerde procesbegeleidings methoden.
@Louis DevOps is een heel interessant fenomeen. Even los of het goed of slecht is (en dan: voor wie?) en of het wel in elke situatie past: Waarschijnlijk niet. Denk maar aan belastingdienst of bijvoorbeeld een bank of ziekenhuis.
Wat je ziet is dat veel cloud computing diensten DevOps (succesvol) inzetten. Dat moeten ze ook wel, omdat het nu innovatie-tijd is. Te lang stil blijven staan betekent achteruitgang ten opzicht van concurrenten die wekelijks nieuwe functies toevoegen.
De belofte van DevOps is dan ook enorm. Als je DevOps toepast betekent dit dat je *heel erg* in control bent. Dat moet ook wel, anders is het bedrijfsrisico veel te groot. Maar met goede DevOps krijg je agile wat anders log zou zijn.
En denk niet dat DevOps roekeloos is, er is wel zeker A/B testing, Unit testing, et cetera. Soms heb je wel eens dat de userbase een wijziging totaal niet accepteert dan zie je dat juist door deze manier van werken ook dit weer teruggedraaid kan worden. DevOps is dus in veel gevallen the way to go en ik geloof er heilig in.
Continuous delivery is de bom 🙂
Met Agile is Continuous Delivery en Integration een must en Operations moet in het tempo mee om Agile succesvol te laten zijn. Uiteraard zijn hier risico’s aan verbonden en kwaliteitsborging door middel van testen, reviews en controle op standaards en richtlijnen vallen niet weg met de introductie van de Agile aanpak. Sterker nog, de kwaliteitsborging (Quality Assurance) is een belangrijk aspect in DevOps. Op DevOps.com staat een interessant artikel met 5 top tips:
http://devops.com/features/five-top-tips-cloud-devops-automation/
Louis, je moet toch echt wat meer golven om de business te begrijpen 😉
@louis
Inderdaad is het meer een afstemmingsprobleem dan een tekort aan tools, de argumentatie in sommige reacties is als het paard achter de wagen spannen. Want Agile is soms gewoon een kruiwagen vol met kikkers wat de afstemming natuurlijk niet makkelijker maakt.
@Henri
Het is geen discussie tussen goed of slecht maar tussen passend of niet. DevOps is in mijn ogen niet veel anders als ‘pipeline deployment’ wat alleen werkt als je korte ketens hebt. En dat DevOps prima past bij Cloud Computing komt mede doordat die wereld plat is, een hoge mate van standaardisatie.
@Anko
Ja en nee, de samenwerking is er meestal wel alleen dan officieus. Probleem (of uitdaging) welke ik nog vaak zie is dat het beheer vooral aangestuurd wordt op contracten, de SLA die weinig flexibiliteit kent als je beheer uitbesteed hebt. DevOps is voor mij in de eerste plaats over schaduwen heen springen, iets wat veel managers werkeloos maakt.
Heel veel organisaties zijn nog maar net begonnen met Agile en dan vaak ook nog eens in hun eigen variant die een groot gedeelte van Agile denken en doen ondermijnt. Niet dat het ultieme doel zou moeten zijn om 100% netjes Agile te werken. Maar slechte gewoontes hebben een eigenschap om maar moeilijk te slijten.
Om dan maar meteen door te stoten naar een DevOps is misschien dan wel wat overmoedig. Wat dat betreft is het volgens mij meer een hype buzzword dan dat het daadwerkelijk ook concreet veel inhoud heeft waar organisaties wat aan hebben. Zoals altijd gaat het meer om de invulling.
De kwaliteit daarvan is vaak te herkennen in de volwassenheid van de QA. Bij menig bedrijf vaak toch wel het ondergeschoven kindje.
Vandaar ook mijn stelling.
Zonder een goed afdekkende QA is continuous delivery vrij zinloos. Dus vermijden dat QA het kritieke pad vormt voorkomt niet alleen afraffelen. Het voorkomt ook dat de hele pijplijn verstopt komt te zitten als QA de hoogste prioriteit gekregen heeft. Het is vrij goed uit te leggen dat het product wat later geleverd wordt omdat er nog eens goed naar gekeken word en er fouten uitgehaald worden. Daar heb je onderhoud sprints voor.