Az egyetlen technológiai költség, amelyet nem mér fel – milliókat takaríthat meg, ha megtenné

A felhőre való áttéréssel az egyik legnagyobb változás az, hogy hogyan fizetünk a technológiáért és az alkalmazásokért. Az iparág a telephelyi adatközpontokkal rendelkező szervereken végzett mindent megtehető feldolgozásról változó vagy segédszámítási modellre váltott. Egy friss Apptio szerint jelentést, ez azt jelenti, hogy „minden nap megtörténhet csapatszinten a mikrooptimalizálás a felhőalapú kiadások alakjának megváltoztatása érdekében… Ez az OpEx (működési költségek) világa a CapEx (tőkekiadások) helyett, teljesen megváltoztatva a pénzügyi jelentéseket. és sikerült.”

Ennek eredményeként a hagyományos kiadási beszerzési modellt felforgatták, és a vásárlóerőt azoknak a mérnököknek a kezébe helyezték, akik ezeket az alkalmazásokat és infrastruktúrát fejlesztik és kezelik, miközben nem veszik figyelembe, hogy mennyibe kerül ez a vállalat működési költségeiben. Mindenki, aki ma a technológiai lövészárkokban dolgozik, az itt és most-ra összpontosít saját tulajdoni területére vonatkozóan, így biztosítva, hogy a rendszer minden nap leállás nélkül átvészelje. Senki nem gondol arra, hogy: Megtehetnénk-e gyorsabban, jobban, okosabban, azaz hatékonyabban, amit csinálunk az alkalmazásokon és folyamatokon belül?

Az Apptio, az IT-szolgáltatások költségeinek tervezési, költségvetés-tervezési és előrejelzési célú felmérésére és kommunikálására szolgáló szoftvereket gyártó cég a továbbiakban úgy írja le a helyzet komor valóságát, hogy „a mérnökök olyan pénzügyi kötelezettségeket vállalnak a felhőért, amelyek hatással vannak a vállalatuk eredményére, miközben A pénzügyi csapatok nehezen tudnak lépést tartani a kiadások ütemével és részletességével.”

A legtöbb mérnök nem ellenőrzi vagy nem érti teljesen az általa írt kódot; pusztán infrastruktúrát adnak hozzá ahhoz, hogy bármit is üzemeltethessenek, amit a termelésben előmozdítanak.

Az iparágban nem általános gyakorlat a technológiai környezet teljes költségének kiszámítása a csapata által támogatott több száz alkalmazás vagy technológia esetében. Ezen változtatni kell. (Megjegyzés: Nem a Robotic Processing Automation-RPA-ról beszélek, amely robotokat használ a digitális feladatok automatizálására.) Megközelítésem az alkalmazások, kódok és folyamatok hatékonyságára összpontosít, nem pedig az automatizáláson keresztüli hatékonyságra.

Miért fontos a kód teljes költségének mérése?

Az alkalmazások célja, hogy a folyamatokat leegyszerűsítsék az üzleti felhasználók számára. Sok erőforrást és összetettséget igényel, hogy egy alkalmazás választ adjon, még akkor is, ha a válaszidő csak néhány másodperc. Most szorozza meg ezt a másodpercenkénti több ezer vagy millió alkalmazáskéréssel a vállalata több ezer szerverén. Könnyen előfordulhat, hogy a dolgok elérhetetlenné válnak, ha ennyi egyszerre történik, és ez a költségekre is vonatkozik. Ha az alkalmazást futtató kiszolgálók három évig működnek, de csak egy évig tartanak, mert elfogy a kapacitásuk – mennyi az alkalmazás valódi költsége? Ezt a pénzügyi igazgatóknak és másoknak tudniuk kell, mert van költségvetésük, amelyet teljesíteni kell.

Egy hatékony, egészséges rendszer kevesebb erőforrást igényel ugyanazon terhelés feldolgozásához, mint egy nem hatékony rendszer. A kódoptimalizálás még több erőforrást szabadít fel.

Gyakorlatilag bármely rendszerben megvan a lehetőség, hogy legalább 30-40 százalékkal racionalizálja a kapacitást, és a kódoptimalizálás további 20-80 százalékos költségmegtakarítást eredményezhet.

Ez azt jelenti, hogy ugyanazok a terhelések kisebb szervereken is futtathatók, csökkentve a felhő- és licencköltségeket. Ezeknek a megtakarításoknak az értéke nem egyszerűen rövid távú, hanem hosszabb ideig tartó, mivel a legtöbb alkalmazás 5-20 évig vagy tovább él. Ez nem csak a lényeg kérdése, hanem annak mérlegelése, hogy mit lehetne tenni ezzel a felszabaduló tőkével a további üzleti KPI-k érdekében.

Képzelje el a kód teljes költségét 20 év alatt, és fontolja meg: „Tehettük volna ezt a kódot 20%-kal hatékonyabbá, és ha igen, mennyit spórolhattunk volna 20 év alatt?”

Aztán ott van a költözés a felhőhöz és a pay-as-you-go ellen előre fizetés olyan modell, amely gyorsabban futja fel az adatrendszerek üzemeltetésének és karbantartásának költségeit, mint ahogyan azokat rögzíteni és elemezni tudjuk. Az Apptio-jelentés rávilágít arra, hogy mindenki veszít, ha a felhőszolgáltatások költségei nem átláthatók:

• A mérnökök többet költenek a kelleténél, miközben nem ismerik a költséghatékonyságot.
• A pénzügyi csapatok küzdenek azért, hogy megértsék – és lépést tartsanak vele –, mire költenek az elképesztő számú opcióra (csak az AWS-nek körülbelül 300,000 XNUMX SKU-ja és további ezer új funkciója van évente).
• A vezetésnek nincs elég beleszólása abba, hogy mennyit fognak költeni, vagy nem tudja befolyásolni a prioritásokat.
• A beszerzés nem szándékos résztvevője saját kiszervezésének.

A megtakarítások becslése egy kicsit több tervezést és áttekintést igényel, ha optimalizál egy kódrészletet, mielőtt az hatástalanná tenné a rendszert (legjobb esetben) vagy leállást okozna (rosszabb esetben). De ez szükséges, ha lépést akarunk tartani a vállalkozások jelenlegi növekedési ütemével.

Következő cikkemben arról fogok beszélni, hogyan mérhetjük a kód teljes költségét, és ezáltal milliárdokat takaríthatunk meg a nem hatékony folyamatokon. Velem vagy?