Старый технический сценарий мертв. Сегодня архитекторам нужно понимать, что даже лучшая платформа провалится, если вокруг нее не выстроены «социальная инфраструктура» и доверие.
Мы все согласны, что роль технологического лидера переписывается прямо на глазах, и если вы строите системы, на которые он опирается, вам нужно понимать, чего от вас ждут сейчас.
Скажу честно: большую часть моей карьеры разговоры с CIO шли по довольно предсказуемому сценарию. Они описывали проблему, я сопоставлял ее с решением, и мы обсуждали сроки и интеграцию. Чисто. Транзакционно. Технически. Все очень прямо, верно?
Этот сценарий был разорван в клочья.
За последние пару лет, работая с государственными структурами, глобальными корпорациями и компаниями среднего размера в Латинской Америке, а теперь и в США, я наблюдал, как роль CIO меняется так, что это действительно влияет на то, как я выполняю свою работу в качестве solutions architect. Технологический лидер, который раньше в первую очередь заботился о бесперебойной работе и экономии затрат, теперь приходит на встречи с вопросами о конкурентной дифференциации, культурных изменениях и трансформации персонала. И он прав, когда задает эти вопросы.
Сдвиг не косметический. Он структурный.
Проблема, которая прячется на виду
Вот что я постоянно видел в провальных проектах модернизации, а таких проектов я видел много: технология работала нормально. Архитектура была надежной. Внедрение было аккуратным. И все же проект буксовал или тихо умирал через шесть месяцев. Корень проблемы почти никогда не был техническим. Это была проблема принятия решений на этапе, который предшествует поставке. Стратегия, которую не перевели в четкие операционные приоритеты. Противоречивые мандаты стейкхолдеров, которые никто официально не согласовал. Организационные структуры, которые тянут в разные стороны команды инфраструктуры, пытающиеся всем этим управлять.
То, что я стал называть decision integrity — дисциплиной, которая следит за тем, чтобы стратегия связывалась с исполнением, — отсутствовало. И исторически CIO не был тем, кто должен был владеть этой разрывной зоной. Он находился ниже по цепочке.
Это изменилось. CIO, с которыми я работаю сейчас, все чаще сами продвигают эту ясность наверх. Они определяют рамки результата, арбитрируют компромиссы и добиваются организационной согласованности, которая позволяет технической поставке реально сработать. Разговор об архитектуре сегодня — это в равной степени разговор о governance и организационном дизайне, а не только о платформах.
Что это значит, если вы строите решения для них
С моей точки зрения, когда я проектирую решения вокруг open-source платформ, hybrid cloud и AI-инфраструктуры, практический вывод такой: технологические решения, которые принимают мои клиенты, уже не в первую очередь про технологию.
CIO, который инвестирует в инфраструктуру, готовую к AI, покупает не просто более быструю платформу. Он делает стратегическую ставку на то, что организация сможет работать иначе в масштабе. А значит, инфраструктура должна поддерживать не только технические требования, постоянный доступ к данным, автоматизированное применение политик и видимость в гибридных средах, но и организационные.
Могут ли нетехнические стейкхолдеры доверять системе? Выдержит ли модель governance по мере расширения масштаба? Сможет ли платформа поглотить всю сложность реальных корпоративных изменений, не рухнув целиком?
Именно technical debt делает это особенно ощутимым. Я видел среды, где 30–40% инженерной емкости уходит на поддержку legacy. Не потому, что кто-то когда-то принял плохое решение, а потому, что прежние решения накапливались со временем без осознанной стратегии модернизации. Когда CIO говорит мне, что хочет быстро двигаться в сторону внедрения AI, первый разговор, который нам нужно провести, — о том, что лежит под этой амбицией. Нельзя построить надежный AI pipeline поверх инфраструктуры, которой вы не доверяете.
CIO, которые выигрывают сегодня, — это те, кто заранее разобрался с этим долгом: не объявляя о гигантском big-bang rewrite, а системно создавая условия, в которых инновации могут происходить без наращивания entropy. Именно это я и пытаюсь помогать проектировать.
Культурная часть — самая сложная, и это реальность
Скажу прямо: когда кто-то говорит «cultural transformation», у меня обычно возникает инстинкт перевести это во что-то более конкретное, под что я могу спроектировать решение. Agile delivery models. Feedback loops. Automation, которая убирает трение там, где это действительно нужно. Это по-прежнему мой инстинкт.
Но мне пришлось принять тот факт, что культурная часть — это не просто мягкое дополнение к технической работе. Она несущая.
Вот сценарий, который я видел не раз: вы строите действительно отличную платформу automation. Инструменты хорошие. Pipeline работают. И затем внедрение буксует, потому что команды, которые должны этим пользоваться, не доверяют системе, не участвовали в ее определении или тихо защищают рабочие процессы, которые новая система нарушит. Проблема не в платформе. Проблема в том, что вокруг нее никто не построил социальную инфраструктуру.
Прогноз Gartner о том, что к 2030 году 25% IT-работы будет выполняться автономно с помощью AI, — не угроза и не обещание; это проектное ограничение. Если вы сегодня проектируете системы, нужно спрашивать: как выглядит человеческая роль в этом workflow, когда AI берет на себя рутинную работу? Какие навыки вы развиваете в команде? Где по-прежнему должно оставаться человеческое суждение?
На эти вопросы нет чистых технических ответов. Но у архитектора должно быть на них свое мнение.
Обе руки на штурвале
Есть образ, к которому я постоянно возвращаюсь: современный технологический лидер одновременно и навигатор на мостике, и инженер в машинном отделении. Именно это напряжение я и узнаю в поле. Больше всего мне хочется работать с теми CIO, кто не отказался ни от одной из этих ролей. Им по-настоящему интересно, как работает инфраструктура, а не только что она дает. И они по-настоящему отвечают за бизнес-результаты, а не только за технические. Такая двойная ориентация встречается редко, и она ценна; когда я с ней сталкиваюсь, это обычно те проекты, где мы создаем что-то действительно стоящее. И еще меня в open source всегда fascinates одно: люди, которые с ним работают, как правило, настоящие tech-эксперты.
Для нас, кто находится на стороне архитектуры, вывод ясен. Мы тоже больше не можем приходить на такие разговоры только как технический ресурс. Лучшее решение, которое я могу спроектировать, бесполезно, если оно не связано с организационной реальностью, в которой живет клиент. Понимание стратегического давления, под которым он находится, культурных условий, в которых он работает, и ограничений на принятие решений, с которыми он сталкивается, — весь этот контекст определяет буквально все, что я предлагаю строить.
Машинное отделение и мостик всегда были частью одного корабля. Просто оргструктурам понадобилось время, чтобы это признать.
Эта статья опубликована в рамках Foundry Expert Contributor Network.
Материал — перевод статьи с английского.
Оригинал: From the engine room to the bridge: What the modern leadership shift means for architects like me