Коли я представляюся як архітектор програмного забезпечення, багато співрозмовників чемно кивають, а в очах у них читається: «дорогий технар, який малює квадратики». Це зрозуміла реакція. Роботу програміста видно: він написав код, зʼявилася кнопка. Роботу дизайнера видно: зʼявився гарний екран. А робота архітектора виглядає як розмови, схеми й дивні питання на кшталт «а що буде, якщо клієнтів стане вдесятеро більше».
Водночас я переконаний, що добрий архітектор одна з найприбутковіших людей у технічній команді. Просто його внесок у прибуток помітний не у звіті за тиждень, а у звіті за роки. І, що ще гірше для його репутації, найкраща робота архітектора полягає в проблемах, які так і не сталися.
Місто, яке будували без плану
Візьміть два міста. Перше росло саме собою: де зручно, там і будували, дороги прокладали стежками, каналізацію додавали, коли ставало зовсім погано. Друге від самого початку будували за генеральним планом: магістралі, квартали, інженерні мережі із запасом на зростання.
За двадцять років у першому місті затори, аварії труб, нескінченні ремонти й величезні гроші на те, щоб прокласти нову дорогу крізь уже забудовані квартали. У другому місті теж бувають проблеми, але вони розвʼязуються на порядок дешевше, бо для них передбачено місце.
Програмна система компанії і є її цифровим містом. Ним їздять замовлення, гроші, дані про клієнтів. Якщо місто будували без архітектора, кожна нова зміна коштує дедалі дорожче, а кожен збій зачіпає сусідні райони. Гроші витікають крізь тріщини в дорогах, і ніхто не може показати, де саме.
Де архітектура перетворюється на гроші
Швидкість розробки нових функцій. У добре спроєктованій системі нову функцію можна додати, не чіпаючи половини наявного коду. Це називається модульністю, і її економічний сенс простий: команда робить більше за той самий час. Я бачив системи, де додавання нового способу оплати займало два дні, і системи, де та сама задача займала два місяці, бо логіку оплати було розмазано по сорока файлах. Різниця у вартості розробки тут не у відсотках, а в разах.
Вартість інфраструктури. Хмарні сервери оплачуються щомісяця, і рахунки мають властивість тихо зростати. Погано спроєктована система витрачає ресурси марно: зайві запити до бази, відсутність кешування, важкі операції, які запускаються там, де можна обійтися легкими. Архітектор, який одного разу в цьому розібрався, може знизити щомісячний рахунок у кілька разів, і ця економія повторюється щомісяця.
Запобігання простоям. Година, коли інтернет-магазин не працює в розпал сезону, коштує втрачених продажів, рекламного бюджету, що далі витрачався марно, і репутації. Архітектор думає про резервування, моніторинг, відновлення після збоїв заздалегідь, а не тоді, коли все вже впало.
Зниження операційних ризиків. Витік даних клієнтів, втрата бази без резервної копії, залежність від одного сервісу, який раптово закрився. Кожен із цих ризиків у кращому разі коштує великих грошей, у гіршому коштує компанії. Архітектура це зокрема й система страховок.
Свобода найму. Система, побудована на зрозумілих, поширених технологіях і з читабельною структурою, дає змогу швидко підключати нових програмістів. Система, побудована на екзотиці чи на особистих винаходах одного генія, робить компанію заручницею цього генія.
Чого архітектор робити не повинен
Будьмо чесні: архітектори теж уміють знищувати гроші. Найчастіший спосіб це переускладнення. Мікросервіси для системи, якою користуються двадцять людей. Три рівні абстракції там, де вистачило б однієї функції. Підготовка до навантаження в мільйон користувачів у продукту, який ще не знайшов першої сотні.
Добрий архітектор думає не про те, яка архітектура найгарніша, а про те, яка найвигідніша для конкретного бізнесу на конкретному етапі. Іноді це означає свідомо обрати просте рішення й записати в план, коли його доведеться переробити. Це не лінощі, це економіка.
І ще одна пастка: архітектор, який не розмовляє з бізнесом. Він проєктує ідеальну систему для задач, яких немає, і не помічає задач, які справді приносять гроші. Мій принцип: перш ніж малювати схему, я маю зрозуміти, як компанія заробляє, де втрачає час і що заважає їй рости. Без цього будь-яка архітектура буде гарним містом у пустелі.
Як виміряти внесок архітектора
Якщо Ви керівник і хочете зрозуміти, чи окупається архітектура, дивіться на кілька показників у часі:
- скільки часу займає випуск типової нової функції і чи зростає цей час;
- скільки коштує інфраструктура в розрахунку на одного клієнта чи одну транзакцію;
- скільки годин на квартал система була недоступна;
- скільки часу новий розробник витрачає, щоб почати приносити користь.
У системі без архітектури всі ці показники з часом погіршуються. Кожна нова функція дається важче за попередню, рахунки ростуть, збоїв більшає. У системі з доброю архітектурою вони лишаються стабільними або покращуються. Різниця між двома кривими і є внеском архітектора в прибуток.
Що робимо ми
В Ingello Systems архітектура для нас починається не з технологій, а з моделі бізнесу: які сутності є в компанії, які процеси приносять гроші, де вузькі місця. Потім ми описуємо систему формально й за допомогою Fractal генеруємо основу коду, бази та інтерфейсів за єдиними правилами. Це прибирає цілий клас архітектурних помилок, які виникають, коли кожен програміст будує свою частину міста за власними уявленнями.
Якщо Ви сумніваєтеся, чи потрібен Вашій компанії архітектор, поставте собі питання: чи стає кожна нова зміна у Вашій системі дорожчою за попередню? Якщо так, гроші вже витікають. Питання лише в тому, скільки ще Ви готові за це платити.
