IT-бюджет всегда представлял собой неоднозначную квинтэссенцию китайских иероглифов, в которой довольно тяжело разобраться бизнесу. Путь к его оптимизации обычно начинался с мысли что-нибудь «заморозить», хотя, по сути, эффективность работы бизнеса напрямую зависит от эффективности работы IT. Основные причины роста IT-бюджета — это новые проекты, связанные с развитием бизнеса, и увеличение текущего бюджета, связанное с ростом численности пользователей, объемов бизнеса и новых переведенных в эксплуатацию систем. По сути, развитие и сопровождение — это сообщающиеся сосуды: если что-то появляется, то какая-то технология должна утилизироваться, ресурсы должны конвертироваться в ресурсы с новыми знаниями и умениями.

Довольно часто можно встретить подход, при котором формирование бюджета идет от бизнес-целей и задач, но не от системных целей. В результате банк тратит удвоенные ресурсы на инфраструктуру в рамках проектов, многократно перезакладывая средства на доработку одной системы в рамках разных проектов. Например, бюджетируя свои потребности на следующий год, банк закладывает раздельные бюджеты на разные проекты в рамках внедрения CRM, хотя в принципе архитектура этой системы присутствует в единственном числе.

Чтобы этого избежать, нужно принять важный принцип управления IT: «адаптивная архитектура». Термин «адаптивная архитектура» или responsive architecture впервые появился в 60-х годах прошлого столетия как направление развития архитектуры в строительстве. Основной его смысл заключался в использовании различного рода улучшений в дизайне зданий, позволяющих зданию реагировать на изменения окружающей среды и присутствие человека. Это достигалось за счет применения кибернетических сенсоров, интерактивных систем и прочих инженерных инструментов. Например, архитекторы могли включать технологии в несущий каркас здания так, что в зависимости от управляющих параметров оно могло менять форму. Тем самым архитекторы уходили от необходимости постоянной доработки зданий.

Почему бы аналогичный подход не применять в IT? Каждую IT-доработку можно выполнить двумя способами: первый — просто выполнить бизнес-задачу, второй — создать системное решение, которое может также использоваться в выполнении другой задачи.

Обычно организации среднего размера тратят в год до 100 тыс. человекочасов или около 12 тыс. человекодней на разработку, и это прямые расходы. Крупные организации тратят на разработку еще больше. Для сравнения трудозатраты на внедрения АБС оцениваются в среднем в 2–3 тыс. человекодней. То есть многие организации могут внедрить несколько АБС с помощью тех ресурсов, которые они тратят в течение года.

Почему у банков так много разработки? Причин несколько. Во-первых, существует большой разрыв между менеджментом и исполнителем. Здесь обычно присутствует довольно много уровней, при переходе между которыми постановка задачи искажается.

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

Третья причина — внутренняя борьба за место под солнцем. Никто не хочет просто так улучшаться и автоматизироваться, ведь это непременно приведет к осознанию того, что ресурс, который раньше занимался решением определенной задачи, больше в этой области не требуется. Это рождает страх, и люди усиленно держатся за места, сопротивляясь научно-техническому прогрессу, опасаясь, что за этим последует сокращение. При этом про переквалификацию или ее повышение никто почему-то не думает.

Итак, есть три причины, которые мешают прогрессу: отсутствие единого видения в умах людей, отсутствие архитектурного контроля и страх потери своего места. Если эти факторы минимизировать, можно переходить к адаптивной архитектуре. Основная ее ценность, как и в любой архитектуре, — максимальное повторное использование уже созданного. На инженерном языке это выражается в использовании системного подхода и системного мышления, ключевым принципом которых является поиск взаимосвязей и анализ всех будущих и прошлых факторов, которые могут повлиять на ситуацию. Говоря простым языком, если банк проектирует интерфейс обмена данными по определенному продукту с бэк-офисом, то почему не сделать интерфейс универсальным для обмена данными по любым продуктам? Тогда, спроектировав один раз, не придется инвестировать больше в доработку этого интерфейса.

Звучит довольно громко, но этим интерфейсом может быть что угодно в IT-ландшафте и на любом его уровне. Чтобы следовать принципу повторного использования, потребуется выстроить методологию и прозрачный подход в части управления IT, начиная с инфраструктурного уровня и заканчивая пользовательским уровнем. Примерами следов такой гармонизации могут стать появление корпоративной модели данных (Enterprise Data Model, EDM), корпоративной модели сервисов (Enterprise Service Model, ESM), корпоративной модели ролей (Enterprise Role Model, ERM) и т.д. Каждая из этих моделей гармонизирует и унифицирует свою функциональную область. Любое новое изменение обязательно должно проходить контроль наличия места для него в описанной модели.

Вторым важным принципом адаптивной архитектуры является уход от системного программирования. Компьютерная наука шагнула далеко вперед, и время, когда требовалось писать на языках программирования, неизбежно уходит в прошлое. Более того, архитектурная зависимость от таких методов разработки делает развитие дорогим и немасштабируемым. На смену уходящему подходу пришли платформы и case-средства. Если семь лет назад можно было только насмешить программированием мышкой, то сейчас каждая современная платформа включает в себя эту функциональность в качестве основного инструмента для разработки. Процесс разработки превращается в процесс моделирования.

Отдельно стоит отметить необходимость использования настроечных таблиц и отказ от использования параметров в коде, что порождает требование непременного проведения регрессионного тестирования при любом изменении кода.

Каждое направление IT содержит в себе все возможности для внедрения адаптивной архитектуры. Она может проявляться даже в организации интеграционного взаимодействия с использованием шины данных. Многие компании делают на уровне шины достаточно много трансформаций данных, в том числе и на уровне моделей. Если эти трансформации делать на уровне системы-источника, унифицировав обмен со всеми системами с помощью одинаковых контейнеров данных, а системам-приемникам самостоятельно разбирать эти контейнеры, забирая из них то, что нужно только им, то можно уйти от постоянной доработки и регрессионного тестирования интерфейсов источников.

Применение этих принципов приводит к тому, что многие изменения переходят из бюджета на развитие в рутинную поддержку. Например, запуск нового продукта или смена тарифов в тарифном сборнике будет стоить только времени сотрудника сопровождения на то, чтобы просто изменить значения в справочниках. Продуманная адаптивная архитектура будет качественно реагировать на изменения приоритетов бизнеса. При этом для получения адаптивной архитектуры бюджеты проектов могут увеличиться на 15–20%, но сокращение бюджета на развитие может составить 30–40%. В целом можно сделать архитектуру адаптивной, даже сохраняя проектный годовой бюджет в тех же рамках, потому что обычно бюджеты сильно завышены.