Introductie

In dit artikel wordt uitgelegd hoe je de bedrijfsprocessen tussen met name Operations en Development goed kan stroomlijnen. Vlak daarbij overigens account – en/of bestuurlijk management niet uit als factor van invloed. Deze kunnen, mits sturend van aard, dan zoegen voor het stroever lopen van je processen. Niet voor de hand liggend op het eerste oog, en dit ligt dan ook best genuanceerd.

We leven in een wereld waar in-house software ontwikkeling inmiddels gemeengoed lijkt te zijn geworden voor heel wat bedrijven. Doordat het gereedschap dat men hiervoor gebruikt een flinke evolutie door heeft gemaakt in de afgelopen 10 jaar lijkt het allemaal erg simpel. Toch komt er een hoop bij kijken en het hangt een beetje af van in welke branch een bedrijf werkzaam is en of iets van hun producten of diensten gelieerd is aan digitalisering en internet.

Is het voor jouw bedrijf te overwegen, dan heb je om te beginnen goede Development Engineers nodig voor software ontwikkeling enerzijds. Anderzijds heb je ook baat bij goed operationeel beheer. Je wilt immer een stabiel platform, upgrades uit kunnen rollen voor nieuwe features, backups terug kunnen zetten bij issues en het moet allemaal ook nog eens veilig zijn. 

Beren op de weg (de uitdagingen)

Bij een enkelvoudige relatief simpele (web) applicatie die niet al te veel upgrade cycli door maakt is het allemaal nog wel te overzien. Ik doel hierbij overigens met name op een bedrijfsschaal aan de onderkant van het MKB. Ga je omhoog in dit spectrum dan heb je al snel meerdere developers lopen (intern of ge-outsourced) en zo mogelijk ook meerdere producten (platformen) om te onderhouden.

Daar komen dan ook vaak de uitdagingen om de hoek kijken die je structureel op moet lossen. Een mens neigt snel naar overleggen en dat eindeloos herhalen, zonder duidelijk afspraken te maken of actiepunten te definiëren. Zonder gericht werken of introduceren van verandering verbetert het dan ook niet zo veel.

Eindeloze ‘huidige versie’

Een vaker meegemaakte situatie is dat men een versie-loze applicatie onderhoudt waarbij men nooit de eerstvolgende versie oplevert. De klant wil er altijd nog iets bij hebben en dat stoppen we er dan nog wel bij in de versie waar we nu aan werken. Ergo, het is nooit af en dit geeft altijd maar druk op de developers omdat men continu in de ‘we moeten opleveren’ modus zit. Vaak is de drijfveer hierachter dat Sales of Management, met alle goede bedoelingen van dien, de klant tevreden wil houden en alle verzoeken toe staat. Echter neemt voor iedereen hierdoor de duidelijkheid (grip op de situatie) af en het leidt tot onnodige extra communicatie. En dit wordt nog erger als je koppelvlakken hebt met systemen van derden.

Om dit af te bakenen is het absoluut aan te raden om op een release cycle van expliciete software versies te sturen. Hiermee wordt er ineens voor alle betrokkenen een hoop duidelijk en ontstaat er rust in de gelederen. Sales kan immers zeggen tegen nieuwe feature wensen van de klant, ‘dat nemen we mee in de volgende versie’. Aan de andere kant hebben de developers rust en kunnen gefocust werken aan wat er opgeleverd moet worden zonder steeds tussentijds bij te sturen en af te wijken van wat er in de sprint (scrum) aan milestones gedefinieerd is. De product manager is ook blij want we halen de milestones zoals ze zijn uitgewerkt binnen de roadmap.

Aangenomen dat het Management dit begrijpt en het development team hiertegen beschermt komt de volgende stap in de oplevering. Op enig moment moet software die werkt (op een lokaal werkstation) de wereld in en op het grote boze internet ook werken. Hier is dan het Operations team aan de beurt. Bij een eerste oplevering maar ook bij volgende release cycli zal er dus altijd samenwerking nodig zijn tussen Development en Operations.

Is DevOps het antwoord?

Dan is daar de term DevOps. Al langer geleden bedacht en reeds ingehaald door concepten als SRE, maar in beginsel goed om meer grip te krijgen op je (deployment) processen. Devops vereist Developers die operationele awareness hebben, welke samenwerken met Operations medewerkers die kennis hebben van het ontwikkelen van software. Ideale mix zou je denken.

Devops is echter ook in niet alle gevallen een zaligmakende oplossing. Nu is enige operationele awareness absoluut geschikt voor een developer om op zak te hebben. Maar Operations is een ander vak en dat geldt ook voor de ontwikkeling van software. Met de ontwikkeling van diversen software platformen op zak ken ik absoluut mijn weg in het Development landschap. Echter pretendeer ik nooit een developer te zijn geweest. Een developer dient vergaande kennis te hebben op het gebied van software. Dit kan specialisatie zijn in data verwerking, schrijven van algoritmes, specifiek toegespitst op performance, etcetera. Kortom, voor het ontwikkelen van specifieke software, is een senior developer daar simpelweg beter in en moet je dat in veel gevallen ook door zo iemand uit laten voeren.

Voorkom context switching 

Een andere boosdoener die de productiviteit in de weg staat is het meerdere malen per dag/week wisselen van project waar een developer aan werkt. Met een dergelijke omschakeling verlies je kostbare tijd. Het minimaliseren van context switching is belangrijk en dit wordt gedicteerd door een goede planning en de juiste aansturing. Zoals eerder aangegeven stopt de uitrol van software niet als de developer klaar is. Alhoewel bij de gedachte ‘de software is klaar’, management vaak denkt meteen de klant te kunnen bellen. Nou, bijna! Er komt dan nog een deployment fase door Operations zodat het ook echt beschikbaar komt voor de klant.

Een aantal andere aspecten die hier ook zeker niet vergeten moeten worden: 

• Een functionele ketentest om te kijken of end-to-end alles in orde is. Dit vang je niet op met software- of unittests.
• Het opleveren van documentatie voor gebruikers, men heeft immers begeleiding nodig bij de bediening van de nieuwe software.
• Ook is de kans groot dat er interne applicatie beheerders mee moeten werken. Deze, alsook de klant, moeten geïnstrueerd worden, bijvoorbeeld in de vorm van training.

Vaste volgorde

Het formele DevOps diagram is eigenlijk alleen op grotere schaal van toepassing en bevat stappen die in de praktijk niet allemaal nodig of nuttig zijn. Een belangrijk aspect er aan echter is dat het een workflow weerspiegelt met stappen in een vaste volgorde. Nu hoef je, als je ze niet allemaal nodig acht, niet perse allemaal te doorlopen. Meer nog, op kleinere bedrijfsschaal vallen sommige rollen ook samen. Echter is het wel goed om je aan vaste cycle te houden te houden. Een praktijkvoorbeeld hoe zaken onnodig fout kunnen gaan is de volgende. Ik heb meegemaakt dat op enige moment een bepaalde software release door de testers beoordeeld werd. Terwijl mee hier mee bezig was, was er onderwijl op de betreffende test omgeving al een nieuwere release geplaatst. Op basis van de resultaten, die aldus niet klopte, werden verkeerde conclusies getrokken. Met deze test output is de Product manager met de klant gaan praten over de input data en hoe de output data al dan niet voldeed aan de verwachtingen. Iedereen maakt fouten en dat is heel normaal. Echter had in dit geval, door een goede aansturing en borging van processen,het onnodig manuren verbruiken voorkomen kunnen worden. Plus het staat niet zo netjes richting klanten.

Versie beheer

“Alles in de juiste volgorde” klinkt wellicht alsof iedereen op iedereen zit te wachten maar dat is niet zo. Feitelijk een kwestie van goed plannen. Ja daar is tie weer. Een aanpak die hierbij absoluut uitkomst biedt is versie beheer. En dan bij voorkeur over het hele spectrum of proces, omdat formeel gesproken aan een software versie ook een datamodel versie en documentatie versie gekoppeld kunnen worden.

Er zijn er nog meer maar laat ik even het belang doortrekken van versiebeheer op het datamodel. Op marketing en customer support afdelingen zie je vaak van die mooie gekleurde dashboards die ‘de stand van zaken’ weergeven. Deze zijn vaak door een de data analyst gebouwd en gebaseerd op het datamodel. Verandering in het model kan aldus issues voor de support afdeling tot gevolg hebben. Ergo, zelfs de dashboards zou je kunnen koppelen aan je software versie.

Een ander nut van versiebeheer is dat de support medewerkers, die in de frontlinie met klanten spreken weten over welke software versie het gaat. Worden er dan issues geconstateerd kunnen zij hier duidelijk aan refereren. Zo hoeven developers op hun beurt vervolgens niet achter de juiste informatie aan bij het fixen van bugs. Sterker nog, je voorkomt onnodig werk. Immers kan je tickets sluiten die betrekking hebben op een oude software versie omdat deze hun relevantie verloren hebben.

Dit lijkt wellicht allemaal wat excessief; Mijn punt is dat je ziet wat de impact kan zijn bij geen of gebrekkig versie beheer. Dit leidt snel tot een situatie waar men achter de feiten aanloopt en alleen met herstel en correctie werk bezig is. Het bekende brandjes blussen. 

Alles in dockers!

“Alhoewel het concept docker in dit betoog ogenschijnlijk een technische side-step lijkt, onderstreept het een scheidslijn tussen verschillende betrokkenen in het deployment proces.”

We begonnen het artikel met de focus op de samenwerking tussen development en operations. Om een gezonde samenwerking te faciliteren moet er een duidelijke scheidslijn komen tussen wie wat doet. Persoonlijk al enkele decennia operationeel specialist dus enigszins bevooroordeeld. Echter haal ik voor de deployment van een applicatie graag een alom bekend oud voorbeeld aan. Wilde men vroeger op een PC nieuwe software plaatsen, stopte men er een CD in, waarna men de ‘setup.exe’ startte. Na een enkele vraag over de installatie folder en wat checks was het eindresultaat een draaiende applicatie op je PC. Starten en aan de slag. Wel nu, een hedendaags vergelijkbaar concept is het ‘inpakken’ van de software in een zogenaamde Docker container. Wat men feitelijk doet is het toevoegen van een extra virtualisatie laag. 

Is docker virtualisatie dan het magische antwoord op alles? Nee zeker niet. Een typisch antwoord maar het is zo, “het hangt er namelijk vanaf”. Bij mensen die roepen dat alles in Dockers gestopt moet worden, raad ik je aan te toetsen of er op context en omgeving gelet wordt. Een aantal factoren die van invloed zijn: applicatie en infrastructuur schaal, kennisniveau binnen het bedrijf, omvang van de betrokken teams, het aantal gekoppelde platformen en ga zo maar door. Doe tevens een kosten baten analyses, heb je nu de tijd om het proces te verbeteren en te borgen, pak die mogelijkheid dan ook. Nu wat investering in borgen van kwaliteit voorkomt dat je later een rekening gepresenteerd krijgt. Nu zal in 75% van de gevallen Docker heus een werkbare keus zijn. Probeer echter in te schatten of mensen die zeggen: ‘alles in dockers’ reëel zijn in jou situatie. Zoom even uit en neem voorgaande aspecten mee in je afweging.

We gaan even terug naar het CD-rom voorbeeld. Als de software in een container zit hoeft Operations alleen de container te starten en heeft men een draaiende applicatie. Er komt uiteraard meer bij kijken dan alleen een container starten. Echter kan het op deze manier veelal door Operations gedaan worden zonder intensieve betrokkenheid van een developer. Het is wel zaak dat er een document met operationele requirements opgesteld wordt, liefst in het begin stadium van (nieuwe) ontwikkeltrajecten. Daarin staan de eisen van Operations, maar daarin kan ook alles opgenomen worden dat de applicatie nodig heeft om zich ‘prettige voelen’. Voor die informatie is uiteraard de developer nodig. Deze bouwt immers de software. En afhankelijk van de schaal van de applicatie zo mogelijk ook een applicatie architect.

Na die eerste fase kan het aantal contact momenten aanzienlijk omlaag omdat er ontwikkeld gaat worden. Er zullen uiteraard nog een aantal intensievere contacten volgen. Met name de eerste deployment op een development of test server. Als men OTAP aanhoudt (wiki: OTAP) zal er nog een aantal deployment cycli komen, te weten naar de acceptatie en productie omgeving, die aandacht behoeven. Staat de eerste versie ‘buiten’ dan is upgrades uitrollen van de applicatie feitelijk meer van het zelfde.

Docker containers, en ‘docker-compose’ voor het combineren van meerdere containers in een software stack, is dus een uitstekende manier voor het stabiliseren van je platformen, maar zeker ook voor je bedrijfsprocessen.

Juiste perspectief

Alhoewel het artikel specifiek de relatie Development en Operations belichtte zijn er, zoals je hebt kunnen lezen veel meer partijen die een rol spelen bij een soepele uitrol van een applicatie. De belangrijkste invalshoeken hieronder nogmaals op een rij.

Development is geen Operations

Het gaat allemaal feitelijk om zo optimaal mogelijk je resources in plannen. Houd rekening met het feit dat een Developer en een Operationeel beheerder van elkaar enigszins weten wat ze doen, maar dat het twee volledig andere vakgebieden zijn. Voorts is vanaf een bepaalde schaalgrootte container virtualisatie een uitstekend middel om ‘het stokje’ door te geven van de development afdeling naar operations tijdens ontwikkeling en deployment van software.

Voorkom context switching

Laat developers zo veel mogelijk werken aan hetzelfde project en niet wekelijks/dagelijks wisselen. Een dergelijke omschakeling snoept tijd af van het aantal productieve uren dat iemand inzetbaar is. Voorkomen hiervan vereist een goede planning en de juiste aansturing. 

Vaste stappen

Waak voor behoud van volgordelijkheid. Zolang als iedereen weet wanneer men ‘aan zet’ is verklein je de kans op misstanden en gaat de deployment trein vanzelf alles stations langs.

Versie beheer

Zorg voor end-to-end versie beheer zodat men weet waaraan men werkt op enig moment. Dit strekt zich uit van developer tot product manager, maar ook support medewerkers. Zo weet men allemaal over welke versie het gaat en heeft men in de communicatie altijd een duidelijke referentie.

Kleine iteraties

Niet behandeld, en hoofdzakelijk nuttig bij ontwikkeling van nieuwe applicaties maar toch goed om even te noemen. Ontwerp niet vooraf de hele wereld maar begin klein en breid vanaf daar stapsgewijs uit. Denk aan het concept Minimum Viable Product (Wiki: MVP). Toets per iteratie of functionele uitbreiding met de klant of je op koers zit. Jij kan bedenken wat je wilt, maar de enige die goed weet wat het moet doen is de klant of opdrachtgever zelf.

Ter afsluiting …

Er is geen one-size-fits-all oplossing voor dit soort trajecten omdat inrichten en verbeteren van processen altijd afhangt van context. Zaken zoals bedrijfsschaal, kennis niveau, platform omvang, klant die in meer of mindere mate weet en uit kan leggen wat hij wil, altijd invloed uitoefenen op wat de beste aanpak is.

Betrek mensen die in het proces zitten in de discussie tijdens de inrichting omdat die weer andere aspecten en vaak meer zien dan de aansturende persoon. Houd als manager daarentegen de processturing in de gaten en vooral niet alle details. 

Vragen of hulp nodig? Vraag een Business intake aan.