Єдина технологічна вартість, яку ви не вимірюєте, яка могла б заощадити мільйони, якби ви це виміряли

Однією з найбільших змін, які відбуваються з переходом до хмари, є те, як ми платимо за технології та програми. Галузь перейшла від обробки «все, що можеш» на сервері з локальними центрами обробки даних до моделі змінних або корисних обчислень. Згідно з нещодавнім Apptio звітом, це означає, що «мікрооптимізація може відбуватися на рівні команди щодня, щоб змінити форму витрат на хмару... Це світ операційних витрат (операційних витрат) замість капітальних (капітальних витрат), що повністю змінює спосіб звітування про фінанси і вдалося».

У результаті традиційна модель закупівель для витрат була перевернута, передавши фінансову спроможність у руки інженерів, які розробляють і керують цими програмами та інфраструктурою, дуже мало враховуючи, скільки це коштує компанії в операційних витратах. Кожен, хто сьогодні працює в технологічних галузях, зосереджений на «тут і зараз» у своїй конкретній сфері власності, гарантуючи, що система працює щодня без збоїв. Ніхто не думає про: Чи можемо ми робити те, що робимо, швидше, краще, розумніше, тобто ефективніше в програмах і процесах?

Apptio, виробник програмного забезпечення, призначеного для оцінки та передачі інформації про вартість ІТ-послуг для цілей планування, бюджетування та прогнозування, далі описує похмуру реальність цієї ситуації: «інженери беруть фінансові зобов’язання перед хмарою, що впливає на прибутки їхніх компаній, а фінансовим командам важко встигати за темпом і деталізацією витрат».

Більшість інженерів не контролюють і не повністю розуміють код, який вони пишуть; вони просто додають інфраструктуру для запуску всього, що просувається до виробництва.

Обчислення загальних витрат на ваше технологічне середовище для сотень додатків або технологій, які підтримує ваша команда, не є загальноприйнятою практикою в галузі. Це потрібно змінити. (Примітка: я не говорю про Robotic Processing Automation-RPA, що використовує ботів для автоматизації цифрових завдань.) Мій підхід зосереджений на ефективності програм, коду та процесів, а не на ефективності через автоматизацію.

Чому вимірювання загальної вартості коду є важливим.

Програми створені, щоб спростити процеси для бізнес-користувачів. Щоб програма надала відповідь, потрібно багато ресурсів і складності, навіть якщо час відповіді становить лише кілька секунд. Тепер помножте це на тисячі або мільйони запитів додатків за секунду на тисячах серверів у вашому підприємстві. Речі легко стають недосяжними, коли так багато відбувається одночасно, і це також стосується витрат. Якщо сервери, на яких запущено програму, мають працювати три роки, але лише один, тому що вони вичерпані, яка справжня вартість цієї програми? Це те, що повинні знати фінансові директори та інші, оскільки вони мають бюджети, які потрібно виконати.

Ефективна, працездатна система потребує менше ресурсів для обробки того самого робочого навантаження, ніж неефективна система. Оптимізація коду звільняє ще більше ресурсів.

Практично будь-яка система має потенціал для реалізації раціоналізації потужностей принаймні на 30-40 відсотків, а оптимізація коду може забезпечити ще 20-80 відсотків економії витрат.

Це означає, що однакові робочі навантаження можна виконувати на менших серверах, зменшуючи витрати на хмару та ліцензування. Цінність цих заощаджень є не просто короткостроковою, а протягом тривалих періодів часу, оскільки більшість програм зараз живуть від 5 до 20 років або довше. Справа не лише в кінцевому підсумку, а й у розгляді того, що можна було б зробити з цим вивільненим капіталом для підвищення KPI бізнесу вже сьогодні.

Уявіть загальну вартість коду за 20 років і подумайте: «Чи могли б ми зробити цей код на 20% ефективнішим, і якщо так, то скільки ми могли б заощадити за 20 років?»

Потім є перехід до хмари та платити як-ви-гоу в порівнянні з передоплата модель, яка збільшує витрати на експлуатацію та підтримку систем даних швидше, ніж ми можемо їх охопити та проаналізувати. Звіт Apptio підкреслює, як усі втрачають, коли немає прозорості щодо витрат на хмарні сервіси:

• Інженерія витрачає більше, ніж потрібно, мало розуміючи економічну ефективність.
• Фінансовим командам важко зрозуміти — і не відставати — від чого витрачається вражаюча кількість опцій (тільки AWS має приблизно 300,000 XNUMX SKU та додаткові тисячі нових функцій на рік).
• Керівництво не має достатнього впливу на те, скільки буде витрачено, або здатності впливати на пріоритети.
• Відділ закупівель не є навмисним учасником власного аутсорсингу.

Оцінка економії, яку ви отримаєте, якщо ви оптимізуєте частину коду, перш ніж вона зробить вашу систему неефективною (у кращому випадку) або спричинить збій (у гіршому), вимагає трохи більше планування та розуміння. Але це необхідно, якщо ми хочемо не відставати від поточних темпів зростання бізнесу.

У своїй наступній статті я розповім про те, як ми можемо виміряти загальну вартість коду, заощаджуючи таким чином мільярди на неефективних процесах. Ви зі мною?