Переосмысление архитектурной функции 2/2 Продолжение (начало). Теперь о составе функции. Долгое время часть решений считалась архитектурными просто потому, что их реализация была дорогой и требовала большого объема ручной работы. Когда цикл пересмотра решения сокращается, часть решений можно принимать ближе к реализации и корректировать по мере появления новой информации. Руководителю важно отличать решения, которые можно недорого пересмотреть, от решений, последствия которых переживут конкретную реализацию. С этой темой я выступал на JVM Day от Т-Банка, может скоро появится запись, но суть в том, что архитекторной функции теперь жизненно необходимо сосредоточиться на нетиповых решениях, а не забивать время обсуждениями потока типовых решений, которые могут быть приняты ближе к разработке. И главная мысль, которая проскальзывала через большинство разговоров, – стоимость изменения работающей системы не сводится к стоимости программирования (а она сейчас не так очевидна в моменте, потому что ФОТ всегда был основной статьей расходов в разработке). Миграция накопленных данных, изменение обязательств перед внешними потребителями, устранение последствий потери доверия – это не то же самое, что переписать модуль. AI может помогать в такой работе, но он не отменяет ни связанности систем, ни рисков миграции, ни сложности развертывания, ни системных эффектов изменений. Если посмотреть на живые SDLC-процессы, становится очевидно, что скорость производства кода сама по себе не всегда делает изменение продукта дешевле. Без стабильной поставки и гарантий выполнения атрибутов качества стоимость изменений может даже вырасти, – компания теряет клиентов, не выполняет обязательства, тратит больше на инфраструктуру. Быстро получить реализацию еще не значит быстро получить надежный результат. Вывод в целом очевиден. Не всем нужен архитектор, но, похоже, всем нужна архитектурная функция в том или ином виде. Ее могут составлять архитектор, команда, автоматизированные механизмы, а чаще – их сочетание. Так было и раньше, теперь этого проще добиться и вопрос уже не «как это сделать?», а «почему еще не сделано?». Главное, чтобы в изменившихся условиях функция с нужной скоростью обеспечивала должное качество решений и проверку их последствий. Если в вашей компании архитектурная функция переживает кризис самоопределения, давайте обсудим, разговор ни к чему не обязывает. Пишите в личку @sergey486, договоримся о встрече. Вам – второе мнение, мне – более глубокое понимание ситуации 🤝