De enige technologie die u niet meet: dat zou miljoenen kunnen besparen als u dat wel deed

Een van de grootste verschuivingen bij de overstap naar de cloud is hoe we betalen voor technologie en applicaties. De branche is overgestapt van all-you-can-process op een server met on-premise datacenters naar een variabel of utility-rekenmodel. Volgens een recente Apptio verslag, betekent dit dat “micro-optimalisaties elke dag op teamniveau kunnen plaatsvinden om de vorm van de clouduitgaven te veranderen … Het is een wereld van OpEx (operationele uitgaven) in plaats van CapEx (kapitaaluitgaven), waardoor de manier waarop financiën worden gerapporteerd volledig verandert en beheerd.”

Als gevolg hiervan is het traditionele inkoopmodel voor onkosten op zijn kop gezet, waardoor de koopkracht in handen komt van ingenieurs die deze applicaties en infrastructuur ontwikkelen en beheren zonder rekening te houden met wat het het bedrijf aan operationele kosten kost. Iedereen die tegenwoordig in de technologische loopgraven werkt, is gefocust op het hier en nu voor hun specifieke eigendomsgebied, zodat het systeem elke dag doorkomt zonder uitval. Niemand denkt aan: Zouden we wat we doen sneller, beter, slimmer, dus efficiënter kunnen doen binnen de applicaties en processen?

Apptio, makers van software die is ontworpen om de kosten van IT-diensten voor plannings-, budgetterings- en prognosedoeleinden te beoordelen en te communiceren, beschrijft de grimmige realiteit van deze situatie verder als "ingenieurs die financiële toezeggingen doen aan de cloud die van invloed zijn op de bedrijfsresultaten terwijl financiële teams hebben moeite om het tempo en de gedetailleerdheid van de uitgaven bij te houden.”

De meeste ingenieurs hebben geen controle over de code die ze schrijven of begrijpen deze niet volledig; ze voegen alleen infrastructuur toe om alles te laten draaien wat tot productie wordt gepromoot.

Het is in de branche niet gebruikelijk om de totale kosten voor uw technologieomgeving te berekenen voor de honderden applicaties of technologie die uw team ondersteunt. Dit moet veranderen. (Opmerking: ik heb het niet over Robotic Processing Automation-RPA, het gebruik van bots om digitale taken te automatiseren.) Mijn benadering is gericht op de efficiëntie van applicaties, code en processen, niet op efficiëntie door automatisering.

Waarom het belangrijk is om de Total Cost of Code te meten.

Applicaties zijn ontworpen om processen eenvoudig te maken voor de zakelijke gebruiker. Het kost veel middelen en complexiteit voor een applicatie om een ​​antwoord te geven, zelfs als de reactietijd maar een paar seconden is. Vermenigvuldig dit nu met duizenden of miljoenen applicatieverzoeken per seconde op duizenden servers in uw hele onderneming. Het is gemakkelijk om dingen buiten bereik te krijgen als er zoveel tegelijkertijd gebeurt, en dit heeft ook te maken met de kosten. Als de servers waarop een applicatie wordt uitgevoerd verondersteld worden drie jaar mee te gaan, maar slechts één jaar meegaan omdat ze geen capaciteit meer hebben, wat zijn dan de werkelijke kosten van die applicatie? Dit is iets dat CFO's en anderen moeten weten, omdat ze budgetten hebben waaraan moet worden voldaan.

Een efficiënt, gezond systeem vereist minder resources om dezelfde werklast te verwerken dan een inefficiënt systeem. Code-optimalisatie maakt nog meer resources vrij.

Vrijwel elk systeem heeft het potentieel om capaciteitsrationalisatie met ten minste 30 tot 40 procent te realiseren en code-optimalisatie kan nog eens 20 tot 80 procent kostenbesparingen opleveren.

Dit betekent dat dezelfde workloads op kleinere servers kunnen worden uitgevoerd, waardoor de cloud- en licentiekosten worden verlaagd. De waarde van deze besparingen is niet alleen op korte termijn, maar over langere perioden, aangezien de meeste toepassingen nu 5 tot 20 jaar of langer meegaan. Het gaat niet alleen om de bottom line, het gaat om de overweging van wat er met dit vrijgekomen kapitaal zou kunnen worden gedaan om vandaag de zakelijke KPI's te verbeteren.

Stel u de totale codekosten over 20 jaar voor en overweeg: "Hadden we die code 20% efficiënter kunnen maken, en zo ja, hoeveel hadden we in 20 jaar kunnen besparen?"

Dan is er de overstap naar de cloud en de pay-as-you-go tegen vooraf betalen model dat de kosten oploopt om datasystemen sneller te bedienen en te onderhouden dan we ze kunnen vastleggen en analyseren. Het Apptio-rapport laat zien hoe iedereen verliest als er geen transparantie is in de kosten van clouddiensten:

• Engineering geeft meer uit dan nodig is en heeft weinig inzicht in kostenefficiëntie.
• Financiële teams hebben moeite om te begrijpen - en bij te houden - wat er wordt uitgegeven aan het verbijsterende aantal opties (AWS alleen al heeft ongeveer 300,000 SKU's en nog eens duizenden nieuwe functies per jaar).
• Leiderschap heeft niet genoeg input over hoeveel er zal worden uitgegeven of het vermogen om prioriteiten te beïnvloeden.
• Inkoop is geen bewuste deelnemer aan zijn eigen uitbesteding.

Het schatten van de besparingen die u zult hebben als u een stuk code optimaliseert voordat het uw systeem inefficiënt maakt (in het beste geval) of een storing veroorzaakt (in het slechtste geval), vergt wat meer planning en inzicht. Maar het is noodzakelijk als we het huidige groeitempo van bedrijven willen bijhouden.

In mijn volgende artikel zal ik het hebben over hoe we de Total Cost of Code kunnen meten, waardoor we miljarden kunnen besparen op inefficiënte processen. Sta je aan mijn kant?