Tag Archives: DevOps

Versnelling en complexiteit, daar draait het om

Snel, sneller, snelst

Bedrijven en organisaties gaan in onze westerse maatschappij steeds sneller. Nergens is dat beter zichtbaar dan in het IT vakgebied. En snelheid is belangrijk, want het houdt de kosten laag en verbetert de concurrentiepositie. Consumenten worden zo eigenlijk verwend met wachttijden die korter worden. We houden dan ook niet van wachten.

Het telkens verder versnellen van organisaties en bedrijven lijkt daarmee een logische keuze en dat is het ook. Er is nooit een bedrijf gestart om productie of diensten te vertragen. Bovendien, versnelling van productie leidt tot lagere kosten, want hoe minder tijd je kwijt bent, hoe lager de kostprijs. Dus ook vanuit een bedrijfseconomisch perspectief is versnelling een goed idee.

Complexiteit

Maar er werkt ook iets tegen de versnelling in. Een tegenkracht, zo je wilt, en dat is complexiteit. Als een situatie complexer wordt, kan je minder snel. Dus versnellen kan je ook door de complexiteit te verlagen. Complexiteit kan je bijvoorbeeld verlagen door te standaardiseren. Als iets standaard is, kan je het sneller leveren en met minder verliezen en dus goedkoper. Een aardig voorbeeld hiervan is Infrastructure as Code. Dit is het bouwen van infrastructuur middels een script (code). Dat bouwt netwerken en systemen volgens jouw recept en specificaties, telkens opnieuw, zo vaak als jij dat wil.

Concert op dubbele snelheid?

Maar moeten we dan alles altijd maar versnellen? Dat is zeker niet zo. Er zijn wel degelijk uitzonderingen. 

In een ziekenhuis of verzorgingshuis kan je de aandacht voor patient en bewoner niet versnellen, daar is juist vertraging nodig om het contact waardevol te maken. Persoonlijke aandacht is echt een belangrijke uitzondering.

Een andere uitzondering is, iets leren. Wanneer je iets wil leren en het echt wilt doorgronden, dan heb je daar aandacht voor nodig, je moet hiervoor vertragen. Je zou kunnen stellen dat alles wat te maken heeft met “Het beleven” tijd vraagt. Je wilt een massage toch niet versnellen? of een concert? Kortom, niet alles laat zich versnellen

Fouten maken mag, mits sneller

Kijk met dit perspectief eens naar kwaliteitssystemen of standaardisatie. Vanuit de automotive weten we dat een fout in processtap 1, tien keer meer inspanning kost om die in stap 2 te fixen. Fouten maken is dus kostbaar. Dubbel eigenlijk, want de inspanning die je daaraan besteed kan je niet gebruiken om (de productie) te versnellen. Je wil fouten daarom zo vroeg mogelijk in het proces identificeren en corrigeren.

Ik denk dan ook dat standaardisatie en (proces) kwaliteit ons direct helpen te versnellen. Ik denk zelfs dat hun bestaansrecht daarin gelegen is. In de IT kunnen we daarom leren van de automotive.

IT gaat snel, IT’ers zijn langzaam

Maar we kunnen zelfs een stap verder gaan. We worden al jaren overspoeld met methoden als ITIL, Prince2, Agile, Scrum en DevOps. Blijkbaar is er telkens iets nieuws nodig om het doel te bereiken. Ik denk dat de rode draad ook hierin versnelling is. Telkens proberen we met nieuwe methodes meer grip te krijgen op IT (projecten) en resultaten. En wat willen we dan bereiken? Waarschijnlijk sneller resultaten bereiken en voorspelbaar worden. Ook hier gaat het dus  om snelheid, want voorspelbaarheid verhoogt de snelheid. Hoe meer grip men op projecten (en de uitkomsten daarvan) heeft, hoe sneller het gaat.

Zoeken naar de balans

Ik denk dat de grote uitdaging van bedrijven en organisaties vandaag de dag is: “Wat kan ik versnellen, maar wat moet ik vertragen?”. Interessant hierbij is dat we met versnelling tijd, ruimte en geld kunnen creëren om andere processen te vertragen. Bijvoorbeeld, als ik het beantwoorden van 80% van alle helpdesk vragen kan automatiseren (chatbots e.d.) dan krijg ik tijd om klanten die dat nodig hebben te woord te staan. Daarmee verbetert mijn dienstverlening en mijn concurrentiepositie.

Een ander mooi voorbeeld hiervan is Coolblue. Het overgrote deel van de verkoop verloopt via de website – lekker snel, maar voor klanten die daaraan behoefte hebben zijn er de Coolblue winkels. Daar krijg je persoonlijke, 1 op 1 , aandacht van een medewerker die je helpt met al je vragen rond de producten die je wil kopen.

Versnelling en complexiteit zijn in mijn ogen bruikbare perspectieven om ons handelen in de IT te begrijpen. Ik zou zelfs willen voorstellen het actief als criterium te gaan gebruiken.

Cloud computing leugen

IT dienstverleners zijn het er wel over eens. Cloud computing heeft de toekomst. En die toekomst is inmiddels gearriveerd.  Veel consumenten en bedrijven gebruiken al producten “Uit de Cloud”. Ook overwegen ze bestaande IT diensten naar een Cloud omgeving te migreren. Hierbij spelen nog wel issues als “Safe Harbor“, maar uiteindelijk lijken ook deze bezwaren overkomelijk. Cloud computing belooft dat we “los” komen van de infrastructuur. Dat we ons eindelijk kunnen richten op de kern van de (IT) zaak, namelijk functionaliteit. Tegelijkertijd is het risico dat we verder in infrastructuur verzeilen. De Cloud computing leugen.

Cloud computing

Big change

Cloud computing brengt ons vele voordelen. Natuurlijk begrijpen we dat we voor daadwerkelijk gebruik betalen (van Capex naar Opex), dat capaciteit schaalbaar is (scale out en scale in) en dat deployment en management van servers geautomatiseerd is (Puppet of Ansible). Echter achter al deze details gaat de werkelijke verandering schuil. We besteden minder energie aan de infrastructuur. Infrastructuur wordt een gegeven. Het is er en het doet het. Geen disks wisselen, systemen in racks schroeven en netwerkkabels aansluiten. Geen gedoe met ijzer, dat regelt de Cloud provider. Eindelijk kunnen we ons richten op  functionaliteit. Dat is namelijk waar bedrijven en consumenten het voor doen. Niemand draait een operating systeem “just for the fun of it”.

Containers en microservices

Als de nadruk op functionaliteit komt te liggen en de steeds sneller ontwikkelen noodzaak is, dan ligt het voor de hand steeds kleinere stukjes functionaliteit te maken. Dit verklaart de populariteit van de microservices. Maar als gevolg hiervan wordt de overhead van het (gevirtualiseerde) operating systeem relatief wel steeds groter. Container technologie zoals Docker verlaagt deze overhead weer. De onderliggende hardware wordt zo beter benut. Amazon gaat nog een stap verder met de AWS Lambda Model (hier mee lijkt het overigens op Red Hat’s Open Shift). De applicatie draait met nog minder overhead op het onderliggende cloud platform.

DevOps en agile

Het is dan ook niet verwonderlijk dat deze technologische ontwikkelingen een andere manier van werken vereisen. Met het verdwijnen van de infrastructuur en het bijbehorende beheer, komt de DevOps discussie in een ander licht te staan. Het wordt noodzakelijk (maar nu ook  mogelijk) om agile te gaan werken. Microservices worden sneller ontwikkeld en traditionele constructies zoals OTAP verlaten. Spotify bijvoorbeeld, doet software ontwikkeling in tribes. Het een kan niet zonder het ander lijkt wel.

Cloud computing leugen

Sneller software ontwikkelen en minder “last” van de infrastructuur zijn goed nieuws voor bedrijven en organisaties. Kortere doorlooptijden en er efficiënter werken het gevolg. We kunnen ontwikkelen tegen lagere kosten en klanten worden slagvaardiger. Ook betekent het dat IT bedrijven zich eindelijk bezig kunnen houden met alles op, of boven, de infrastructuur. Tenzij je natuurlijk deel wil uitmaken van een steeds kleinere groep infrastructuur specialisten. En dit is de Cloud computing leugen. Veel IT bedrijven die nu bezig zijn met Cloud, zijn eigenlijk bezig met infrastructuur. Is dat nog wel zo interessant?