Tag Archives: kwaliteitssystemen

En hoe nu consultancy versnellen?

In deze reeks over versnelling en complexiteit heb ik gekeken naar het “waarom” van versnelling & complexiteit en het “hoe” van kunnen versnellen. Wat werkt versnelling tegen (complexiteit) en wanneer is versnellen geen goed idee (persoonlijke aandacht). Verder heb ik belicht waarom proces kwaliteit bestaat (het versnelt ons) en welke rol standaardisatie en cloud hierbij kunnen spelen (dat versneld ons ook, mede door complexiteit te verlagen). Dit keer wil ik graag naar ons als IT professionals kijken. Moeten wij ook versnellen, waarom en hoe doen we dat dan?

Business as usual?

Als ons klanten willen versnellen – en die case is wel gemaakt denk ik – dan is de eerste vraag die IT professionals zich moeten stellen, “Kunnen we onze klanten daarbij helpen”? Mij lijkt dat IT instrumenteel is bij het versnellen van bedrijfs – en productieprocessen. Dus ja, daar kunnen we bij helpen. De producten en diensten die we leveren moeten daarom bovenal in staat zijn om onze klanten te helpen versnellen. Dat is ook vaak zo, denk aan Infrastructure as Code (IAC) waarmee we heel snel netwerken en servers kunnen bouwen. Ook kan je hierbij denken aan geautomatiseerde deployment van changes (CICD). Een klant wil vast geen technologie, dat is namelijk maar een middel, maar die wil iets bereiken, een website draaien bijvoorbeeld. Feitelijk wil men een business vraagstuk oplossen en geen nieuwe introduceren.

Low Code wel zinvol dan?

Naast onze klanten direct versnellen, kunnen we ook de complexiteit verlagen. Zoals ik eerder al betoogde is de gang naar de “Cloud” daar een aardig voorbeeld van. Door standaardisatie zijn we beter instaat te begrijpen wat we doen en kennen we de kwaliteit (en beperkingen) beter. Het is als puzzelen met hapklare brokken. Het gevolg is dat de klant dan kan versnellen.

Ook het gebruik van Low Code kan klanten versnellen, door (wellicht tijdelijk) de focus te leggen op de business en wat minder op technologie. In een later stadium kan dat weer anders worden. Misschien wil een bedrijf na verloop van tijd meer aandacht geven aan de technische implementatie. De juiste keuze helpt je dan te versnellen.

Vertragen levert toch meer uren op?

Als IT consultancy klanten helpt te versnellen, waarom zouden we dan zelf moeten versnellen? Dat lijkt contra intuïtief, want we verdienen ons geld aan uren, dus waarom dan sneller?

Als eerste denk ik dat als we relevant willen blijven en succesvol willen blijven concurreren met onze vakbroeders, we moeten versnellen. Ook lijkt mij dat als we onze klanten willen helpen versnellen – en dezelfde technieken gaan gebruiken – we daardoor zelf ook versnellen. En dat heeft alles te maken met het “Hoe” van het versnellen.

Hoe dan?

Zoals ik eerder betoogde, bestaat een kwaliteitsysteem om de snelheid te verhogen. Willen we IT consultancy versnellen, dan is “One Time Right” wel een goede aanpak. Waarom omarmen we in de IT dan het kwaliteitsdenken niet? Laten we een voorbeeld nemen aan Toyota. Door te standaardiseren kunnen we klanten sneller helpen, met voorspelbare resultaten, tegen voorspelbare kwaliteit en kosten. Naar mijn idee sluit dat aan bij wat klanten nodig hebben en willen.

Waarom heeft Max een pits stop?

Daarom lijkt mij dat we de IT consultancy business kunnen versnellen als we zorgen voor een hogere kwaliteit (certificeringen bijvoorbeeld), professionalisering en verdergaande standaardisatie. Klanten vragen niet meer om een “One off”, maar willen liever “Standaard” tegen een voorspelbare doorlooptijd en prijs. Het her-gebruik van software en standaardisatie middels het gebruik van “Standaard bouwblokken” ligt dan ook voor de hand. Dit is niet nieuw, maar wel heel actueel. Dus waarom heeft Max een pits stop nodig? Om daarna sneller te kunnen gaan!

Cloud is het grote “Standaardisatie feestje”

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.