Vertragen om te versnellen

Leave a 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.

Paradigmaverschuivingen door Cloud

Leave a reply

Toen ik me (zo’n twee jaar geleden) ging verdiepen in Cloud Computing werd mij snel duidelijk dat ik er vooroordelen over had die niet met de werkelijkheid overeenkwamen. Zo dacht ik tot die tijd  bijvoorbeeld dat het duurder zou zijn dan on premise. En ook dat het alleen geschikt zou zijn voor webserver workloads. En dat het so-wie-so niet geschikt was voor enterprise workloads. Bovendien dacht ik dat Windows workloads op Azure en Linux workloads op AWS gedraaid moeten worden. Ik zag Cloud een beetje als hosting 2.0. Dit bleken vooroordelen omdat ze allemaal niet waar zijn. Nadat ik deze vooroordelen bij mijzelf had opgespoord en structureel verwijderd, werd de Cloud al veel aantrekkelijker.

Nog interessanter werd het toen ik de grote verschillen ontdekte tussen Cloud Computing en legacy IT. Deze verschillen zijn opmerkelijk en ik vind het serieuze paradigma verschuiving.

Dynamisch

Zo waren we gewend om workloads van voldoende hardware (capaciteit) te voorzien zodat klanten voldoende performance ervaren. Deze resources waren veelal ruimschoots voldoende. Te veel resources was geen probleem en bij een tekort aan resources kochten we hardware bij. Virtualisatie maakte dit proces eenvoudiger, maar niet fundamenteel anders. Maar, zowel “Under utilisation” als “Over utilisation” zijn beiden feitelijk verlies. In het eerste geval had ik meer resources gekocht dan nodig was en in het andere geval is de performance niet optimaal en raken mijn klanten ontevreden. Cloud stelt ons juist in staat resources dynamisch toe te wijzen en dus beide vormen van verlies te vermijden. Hiermee kan Cloud goedkoper zijn dan on premise. Het is aan ons om het slim in te richten.

Kosten

Het kiezen van de meest geschikte Cloud service (of combinatie van services) en het juist toepassen ervan is dus key. De consequentie hiervan is dat IT architecten, engineers en developers daarmee verantwoordelijk worden voor het kostenefficiënt zijn van de applicatie. Want was eerder een budgetaanvraag een managementbeslissing, nu zijn de kosten een gevolg van het ontwerp. Da applicatie moet niet gewoon functioneren, maar deze moet ook kostenefficiënt zijn. Kostenefficiëntie is hiermee een design criterium geworden. Amazon AWS heeft hiervoor een hulpmiddel, het: “Well Architected Framework”. Dit framework kent een 5 tal pilaren waarvan “Cost Efficiency” er een is. Development teams zouden er goed aan doen dit framework te gebruiken tijdens het ontwerp en bouwen van applicaties en omgevingen.

Capex versus Opex

Een andere verschuiving is dat kosten niet vooraf vallen (Capital Expenditures), maar achteraf vallen (Operational Expenditures). Dit, op het eerste gezicht, simpele verschil heeft verstrekkende gevolgen. Financiële bestuurders van bedrijven (en IT afdelingen) waren gewend jaarlijks budgetten te maken waarin de kosten voor het komende jaar ingeschat wordt. Dat werkt nu anders. Alle kosten komen achteraf en bovendien kunnen ze fluctueren als gevolg van het dynamisch toewijzen van resources. Maar hoe komen we dan in control van de kosten? De Cloud biedt gelukkig veel mogelijkheden hiervoor, zoals gedetailleerde overzichten van kosten van services, het kunnen isoleren van applicaties in een eigen AWS account en het kunnen instellen van budget alerts. Bestuurders zullen deze nieuwe mogelijkheden leren gebruiken. Ik ben ervan overtuigd dat zodra dat lukt, zij voor het eerst echt in control komen van IT kosten en zij ook niet anders meer willen.

Experimenteren

Er os nog een ingrijpende verandering als gevolg van de “Pay-as-You-go” methode. Experimenteren wordt eenvoudiger en goedkoper. Enterprise features (zoals bijvoorbeeld een Content Management Systeem – CDN) zijn beschikbaar, laagdrempelig en tijdelijk te gebruiken. Dit tijdelijke gebruik is erg  kostenefficiënt. Experimenteren wordt hierdoor gestimuleerd. De keerzijde ervan is dat je ook snel moet beslissen of een experiment geen succes wordt (“Fail fast”). Waar voorheen dure en tijdrovende pakketselecties werden gedaan, loont het zich nu kleine Proof of Concepts (PoC’s) te doen met alle versies van een applicatie die je maar overweegt. Wat niet naar wens werkt ruim je snel weer op.

Alles code

Voor infrastructuur engineers belooft Cloud ook een behoorlijke verandering te zijn. Waar we ons voorheen konden profileren met kennis van hardware en appliances, willen bedrijven nu standaardiseren op native Cloud services. In de meeste gevallen is dit efficiënter en daardoor kosteneffectiever. Bovendien bouwen we de infrastructuur middels code en templates. Infrastructuur wordt code en daarbij adopteren we de werkwijze van developers met bijvoorbeeld CI/CD pipelines en code repositories.

IT feestje

Zoals uit de voorgaande paradigmaverschuivingen blijkt veranderd er toch wel veel in vergelijk met hoe we tot nu toe te werk gingen. De grootste en belangrijkste paradigma verschuiving is naar mijn idee dat Cloud iets voor de gehele organisatie is.

Amazon AWS heeft inmiddels de ervaring dat bij bedrijven die Cloud zien als een “IT feestje” het geen succes wordt. De veranderingen raken immers  alle geledingen van de organisatie, of dat nu de IT afdeling zelf is, HR, financiën of de business. Het is daarom doorslaggevend of we in staat zijn de gehele organisatie te betrekken in het uitnutten van Cloud. Ook hiervoor heeft Amazon AWS hulpmiddelen. Zo is er het “Cloud Adoption Framework” (CAF). In de CAF worden technisch en organisatorische gezichtspunten gebruikt om de obstakels voor Cloud adoptie in kaart te brengen. Hiervoor worden alle stakeholders betrokken en kan bijvoorbeeld gebruik worden gemaakt van de “Cloud Discovery Workshop” om een eerste start te maken met de CAF.

IT 2.0

Mijn vooroordelen over Cloud ben ik inmiddels wel kwijt, maar ik heb er paradigmaverschuivingen voor terug gekregen. Deze verschuivingen maken Cloud voor mij juist extra interessant omdat het aspect “Organisatie” veel prominenter meedoet en dat vond ik altijd al belangrijk. Zo zullen de IT en de business nu wel moeten samenwerken. Dat is iets dat mij al jaren verstandig leek. Zonder deze samenwerking wordt het geen succes. Dit is voor veel mensen ook niet nieuw, maar nu is het echt noodzaak geworden, helemaal bezien in het licht van “Digital Transformation” (https://aws.amazon.com/government-education/digital-transformation/). Gelukkig biedt Amazon AWS hier ook hulpmiddelen, zoals het “Cloud Adoption Framework” (https://aws.amazon.com/professional-services/CAF/getstarted/)  (en de bijbehorende “Cloud Discovery Workshop”) en het “Well Architected Framework” (https://aws.amazon.com/architecture/well-architected/). Voor mij wordt de IT hiermee met sprongen interessanter.