Cloud is het grote “Standaardisatie feestje”

1 Reply

Ik schreef eerder in deze reeks over versnelling en complexiteit. In een tweede schrijven ben ik ingegaan op de rol die kwaliteit van processen (en standaardisatie) spelen om verder te kunnen versnellen. In deze derde blog wil ik graag “Onze gang naar de cloud” vanuit dit perspectief belichten.

Kapotte airco

Ik kan me nog herinneren dat het bedrijf waar ik werkte alle server systemen naar een datacenter wilde verplaatsen. In eerste instantie vond ik dat jammer, het beheer van onze eigen serverruimte was best wel cool, totdat de airco het begaf. Een datacenter is toch een veel professionelere oplossing dat werd mij wel duidelijk.

De migratie naar de cloud heb ik net zo ervaren. Datacenter werkzaamheden zijn best lastig als het je core business niet is. Daarnaast heb je liever de volledige aandacht voor hetgeen wel je core business is.

Goedkoper of duurder?

Er waren veel goede redenen om naar de cloud te willen migreren. Eerste dachten we dat het goedkoper zou zijn. Dat kan ook wel, maar niet als je een-op-een de spullenboel naar de cloud verhuist. Het minimaliseren van de resources die je wilt gebruiken is toch wel handig. Voorheen kochten brokken resources vooraf in waarover we vervolgens vrijelijk konden beschikken. Inmiddels kopen we die resources fijnmazig in en het is daarom zinvol de hoeveelheid te beperken. Dat kan ook, want we kunnen de infrastructuur middels code beschrijven (Infrastructure as Code) en we kunnen middels autoscaling performance matchen met wat er echt nodig is.

Innovatie as a Service

Toen we wat meer bedreven raakten met cloud ontdekten we dat er een voortdurende stroom van nieuwe services beschikbaar kwam. Daar konden we zo gebruik van maken. Kortom, ook hier neemt de cloud leverancier een deel van de “Heavy lifting” van ons over en kunnen wij ons op onze core business richten.

Het staat ons natuurlijk vrij om wel of geen gebruik van deze nieuwe services te gaan maken. Het uitproberen is echter eenvoudig, kan snel en kost weinig. Experimenteren zou dan eigenlijk wel een deel van ons werk moeten zijn. Hierbij geldt, laat het snel mislukken (Fail Fast) want dat kost alleen maar geld. Is het niet zinvol of succesvol, dan stoppen we ermee.

Secure, dus cloud?

Daarna bleek dat de cloud ons heel veel mogelijkheden biedt om workloads secure te kunnen draaien. Daar waar we eerder dachten, “Moet het secure, dan in een eigen datacenter”, denken we nu veel eerder, “Moet het secure, dan in de cloud”. En dat klopt. De mogelijkheden en tools die cloud ons biedt om een workload secure en compliant te houden is enorm. Het is eigenlijk niet praktisch dat zelf te bouwen en dus is de stap naar de cloud zinvol. Je moet het nog steeds zelf goed inrichten, maar dat kan dan ook.

Cloud engineers willen serverless

Wanneer je met engineers over cloud spreekt, blijkt dat zij nog een ander perspectief belangrijk vinden. Ze hebben het dan over “Serverless” of over “Cloud native Development”. Los van mogelijkheden als autoscaling, ze hebben liever geen systemen in de cloud. Een deel van de functionaliteit kan je namelijk regelen middels services waarvoor de cloud leverancier verantwoordelijk is. De rest doe je dan bij voorkeur met containers of zelfs functions (FaaS – Functions as a Service) waarbij je helemaal geen verantwoordelijkheid hebt voor infrastructuur.

Er zijn dan ook referentie architecturen voor applicaties in de cloud. “Best practices” waarvan het zinvol is die te volgen. Waarom zou je het wiel gaan uitvinden als het er al is? Natuurlijk zijn deze referentie architecturen er voor verschillende typen applicaties. Gebruik je daarnaast het Well Architected Framework en Well Architected Reviews, dan ben je goed (professioneel) op weg.

Standaard is sneller

Met al deze “Best Practices” in de cloud zijn we aardig op weg gebruik te maken van standaard services, standaard design en een standaard manier om zaken aan te pakken. Is dat erg dan? Nee helemaal niet, ik ben er groot voorstander van. Ga maar na, je pakt het optimaal aan, gebruikt optimale design (patterns) en het ontwerp is door iedereen te begrijpen, want de referentie architectuur is leidend. Daar waar IT graag telkens het wiel wil uitvinden, gaat het zich nu langzaam conformeren aan een standaard manier van oplossingen bouwen en beheren. Dit is toch veel professioneler, is het daarmee het “Grote standaardisatie feestje”?

Want wat was ook weer het voordeel van kwaliteitssystemen en standaardisatie? Oh ja versnelling en het verlagen van complexiteit. Naar mijn stellige overtuiging is dit dan ook de grootste toegevoegde waarde van cloud, het versnelt ons en laat het daar nu net om gaan.

Vertragen om te versnellen

1 Reply

Versnelling en complexiteit, daar hebben we het over..

Eerder schreef ik al over het versnellen van onze maatschappij. Soms heb ik alleen het idee dat we in het IT vak graag telkens het wiel opnieuw uitvinden. Ieder project zien we graag als leeg vel papier waarop we een mooie, nieuwe tekening mogen maken. Het liefste gaan dan iets gebruiken dat we net hebben ontdekt, aan de slag met ons laatste speeltje zal ik maar zeggen. Ik zou een lans willen breken voor hergebruik en standaardisatie van software. Er is immers een goed argument voor.

Leren van Toyota

De kwaliteit van Toyota auto’s is legendarisch. Dat is niet uit de lucht komen vallen. Na de tweede wereld oorlog moest Japan herstellen, het land, de economie, alles eigenlijk. Er was veel invloed vanuit America hierop. Zo werd de Deming cirkel (Do, Plan, Act, Check) van W. Edwards Deming geïntroduceerd. Tot dan toe waren Japanse producten eerder goedkoop dan van goede kwaliteit. Maar dat veranderde snel. Kaizen (Japans voor improvement) werd een leidend principe. Dit principe werd door Toyota omarmd en de kwaliteit werd snel beter en beter. Het werd ook wel “The Toyota Way” genoemd, of “Lean Manufacturing“. Maar wat is dat dan eigenlijk en waarom werkt het?

Fix problemen zo snel mogelijk

In een productieproces, vraagt een fout gemaakt in stap een, gemiddeld 10 keer meer effort om in stap 2 te fixen. Het probleem is eigenlijk nog veel groter, want die effort kan je niet gebruiken voor productie. Als je dat eenmaal duidelijk is, snap je dat je problemen zo snel mogelijk en zo vroeg mogelijk in een proces moet identificeren en op lossen. Kortom, fouten vertragen je productieproces. Complexiteit vergroot de kans op fouten en dat wil je daarom dus voorkomen. Een kwaliteitssysteem en standaardisatie helpen je om deze complexiteit te verlagen en daardoor fouten te voorkomen en als resultaat te versnellen. Ik denk daarom dat het bestaansrecht van kwaliteitssystemen gelegen ligt in versnellen.

Versnellen in de IT

Mij lijkt dat we in ons “IT vak” lering kunnen trekken uit wat de automotive ons hier voorhoudt. Het verklaart mij waarom standaardisatie zo belangrijk is. Het is dan ook de “echte” reden waarom we SaaS over PaaS over IaaS kiezen, waarom de gang naar de cloud zinvol is en waarom IaC (Infrastructure as Code) zinvol is. Standaardisatie verlaagd complexiteit en dat gaat ons versnellen. En dat is wat onze klanten willen en vragen. Voorspelbare resultaten tegen voorspelbare kosten.

Versnelling en complexiteit, daar draait het om

2 Replies

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.