העלות הטכנולוגית היחידה שאתה לא מודד - זה יכול לחסוך מיליונים אם תעשה זאת

אחד השינויים הגדולים ביותר שיתרחשו עם המעבר לענן הוא האופן שבו אנו משלמים עבור טכנולוגיה ויישומים. התעשייה עברה מעיבוד כל מה שאתה יכול בשרת עם מרכזי נתונים מקומיים למודל מחשוב משתנה או שירות. לפי Apptio לאחרונה לדווח, זה אומר ש"מיקרו-אופטימיזציות יכולות לקרות ברמת הצוות בכל יום כדי לשנות את צורת ההוצאה בענן... זה עולם של OpEx (הוצאות תפעוליות) במקום CapEx (הוצאות הון), שמשנה לחלוטין את האופן שבו מדווחים כספים ונוהל."

כתוצאה מכך, מודל הרכש המסורתי להוצאות שופץ, והכניס את כוח ההוצאה לידיים של מהנדסים שמפתחים ומנהלים את היישומים והתשתיות הללו תוך התחשבות מועטה מאוד למה שזה עולה לחברה בהוצאות התפעוליות. כל מי שעובד היום בתעלות הטכנולוגיה מתמקד בכאן ועכשיו עבור תחום הבעלות הספציפי שלו, ומבטיח שהמערכת תעבור כל יום ללא הפסקה. אף אחד לא חושב על: האם נוכל לעשות את מה שאנחנו עושים מהר יותר, טוב יותר, חכם יותר, כלומר, בצורה יעילה יותר בתוך היישומים והתהליכים?

Apptio, יצרניות תוכנה המיועדות להעריך ולתקשר את עלות שירותי ה-IT למטרות תכנון, תקצוב וחיזוי, מתארת ​​עוד יותר את המציאות העגומה של מצב זה כ"מהנדסים שמקבלים התחייבויות פיננסיות לענן שמשפיעות על השורה התחתונה של החברות שלהם. צוותי כספים נאבקים לעמוד בקצב ובפירוט ההוצאות".

רוב המהנדסים אינם שולטים או מבינים לחלוטין את הקוד שהם כותבים; הם רק מוסיפים תשתית להפעלת כל מה שמקודם לייצור.

זה לא נוהג מקובל בתעשייה לחשב את סך העלויות עבור הסביבה הטכנולוגית שלך עבור מאות היישומים או הטכנולוגיה שהצוות שלך תומך בו. זה צריך לשנות. (הערה: אני לא מדבר על Robotic Processing Automation-RPA, שימוש בבוטים לאוטומציה של משימות דיגיטליות.) הגישה שלי מתמקדת ביעילות של יישומים, קוד ותהליכים, לא יעילות באמצעות אוטומציה.

מדוע מדידת העלות הכוללת של הקוד היא חשובה.

אפליקציות נועדו להפוך תהליכים לפשוטים עבור המשתמש העסקי. נדרשים משאבים רבים ומורכבות לאפליקציה לספק מענה, גם אם זמן התגובה הוא שניות ספורות בלבד. כעת, הכפל את זה באלפי או מיליוני בקשות יישומים בשנייה על פני אלפי שרתים ברחבי הארגון שלך. קל לדברים להיות מחוץ להישג יד עם כל כך הרבה שקורים בו זמנית, וזה קשור גם לעלויות. אם השרתים המריצים אפליקציה אמורים להחזיק מעמד שלוש שנים, אבל רק אחת בגלל שאין להם קיבולת — מה העלות האמיתית של אותה אפליקציה? זה משהו שסמנכ"לי כספים ואחרים צריכים לדעת כי יש להם תקציבים שצריך לעמוד בהם.

מערכת יעילה ובריאה דורשת פחות משאבים כדי לעבד את אותו עומס עבודה מאשר מערכת לא יעילה. אופטימיזציה של קוד מפנה משאבים נוספים.

למעשה לכל מערכת יש פוטנציאל לממש רציונליזציה של קיבולת ב-30 עד 40 אחוזים לפחות ואופטימיזציית קוד עשויה לספק עוד 20 עד 80 אחוז מהחיסכון בעלויות.

המשמעות היא שניתן להפעיל את אותם עומסי עבודה על שרתים קטנים יותר, מה שמפחית את עלויות הענן והרישוי. הערך של החיסכון הזה הוא לא רק לטווח קצר, אלא לפרקי זמן ממושכים שכן רוב היישומים חיים כיום בין 5 ל-20 שנים, או יותר. זה לא רק עניין של השורה התחתונה, זה השיקול של מה ניתן לעשות עם ההון המשוחרר הזה כדי לקדם מדדי KPI עסקיים היום.

דמיינו את העלות הכוללת של הקוד במשך 20 שנה ושקול: "האם היינו יכולים לייעל את הקוד הזה ב-20%, ואם כן, כמה יכולנו לחסוך במשך 20 שנה?"

לאחר מכן, יש את המעבר לענן ול- לשלם כ- you-go נגד תשלום מראש מודל שמעלה עלויות לתפעול ותחזוקה של מערכות נתונים מהר יותר ממה שאנו יכולים ללכוד ולנתח אותן. דוח Apptio מדגיש כיצד כולם מפסידים כאשר אין שקיפות לגבי העלויות של שירותי ענן:

• הנדסה מוציאה יותר ממה שהיא צריכה עם מעט הבנה של יעילות עלות.
• צוותי פיננסים נאבקים להבין - ולהתעדכן - מה מושקע במספר האופציות המהמם (ל-AWS לבדה יש ​​כ-300,000 SKUs ועוד אלפי תכונות חדשות בשנה).
• למנהיגות אין מספיק מידע לגבי כמות ההוצאה או היכולת להשפיע על סדרי העדיפויות.
• רכש אינו משתתף מכוון במיקור חוץ משלו.

להעריך את החיסכון, יהיה לך אם תבצע אופטימיזציה של פיסת קוד לפני שהוא הופך את המערכת שלך ללא יעילה (במקרה הטוב) או גורם להפסקה (במקרה הרע) דורש קצת יותר תכנון ותובנה. אבל זה הכרחי אם אנחנו רוצים לעמוד בקצב הנוכחי של הצמיחה שעסקים חווים.

במאמר הבא שלי, אדבר על איך אנחנו יכולים למדוד את העלות הכוללת של הקוד, ובכך לחסוך מיליארדים בתהליכים לא יעילים. אתה איתי?