Привет, Хабр! Эта статья про то, как команда корпоративной архитектуры ДОМ.РФ выстраивала управление ИТ на основе единого реестра автоматизированных систем. В ней мы поделимся опытом, как и почему и пришли к этому решению, а также расскажем про плюсы и минусы данного подхода.
Предыстория
Для начала объясним, что из себя представляет группа ДОМ.РФ и её ИТ‑ландшафт.
Группа компаний ДОМ.РФ реализует нацпроекты в области жилищного строительства с 1997 года и развивает цифровизацию российской строительной отрасли и банковской сферы. В группу входит множество направлений — от собственного банка до лифтостроительного завода. Все направления имеют ИТ‑составляющую и свои оцифрованные процессы.
До 2023 года участники процессов с ИТ‑составляющей оперировали своими объектами управления, которые не пересекались между собой.
Архитектура. Объект управления — система. Использовался для целей проектирования.
Инфраструктура. Объект управления — актив, локальный список, который использовался для целей управления мощностями.
Поддержка. Объект управления — ИТ‑услуга, привязанная к собственному списку систем. Использовался для целей управления запросами на консультации и поддержку.
Закупки. Объекты управления — заявка на потребность от каждого заказчика.
Бюджетирование. Объект управления — лот.
Информационная безопасность. Объект управления — информационный ресурс. Собственный список информационных ресурсов, используемый для предоставления доступов.
Импортозамещение (проектный офис). Объект управления — система из собственного списка, сформированного для целей по закрытию КПЭ импортозамещения.
При таком подходе каждое подразделение «разговаривало на своем языке», а управление ИТ‑активами было нецентрализованным, кое‑где сложным и непонятным.
Так пришла идея создать новых подход в ИТ‑управлении, который будет основан на базовых объектах управления. Вокруг них будут строиться команды, выстраиваться управление производством, поддержкой, бюджетированием и т. д.
Такими базовыми объектами стали автоматизированные системы (АС) и группы АС (ГАС).
Описание подхода
АС — система, состоящая из персонала и комплекса средств автоматизации его деятельности, реализующая информационную технологию выполнения установленных функций. Является обособленной частью группы автоматизированных систем, реализующей прикладной набор функциональностей. На текущий момент у нас порядка 500 АС.
ГАС — набор АС, организационно‑управляемых в ИТ‑процессах как единое целое и реализующих логически связанный набор функций для выполнения бизнес‑задач. Таких групп у нас получилось 38.
Для каждой ГАС выделили три ключевых сотрудника:
ИТ‑владелец — отвечает за управление командой ГАС, бэклог, бюджет и сроки по реализуемым инициативам.
Корпоративный архитектор — отвечает за стратегию развития ИТ‑ландшафта курируемых ГАС и проектирует концептуальную архитектуру реализации новых инициатив.
Менеджер поддержки — отвечает за сопровождение, непрерывность и доступность курируемых АС.
АС создаётся только по решению Архитектурного совета, для неё определяется «родительская» ГАС и организуются все последующие процессы жизненного цикла. Так, без решения Архитектурного совета и созданного в реестре объекта управления для него не выделяются вычислительные мощности и бюджет, а поддержка не берёт его на сопровождение.
Инструмент обеспечивает прозрачность и управляемость всех технологических ресурсов компании и помогает подразделениям как в ИТ, так и в смежных блоках строить необходимые срезы по развитию ИТ-ландшафта.
Реестр помогает видеть и анализировать 150 атрибутов на уровне АС и ГАС.
Ключевые из них:
Опубликованные архитектурные модели (концептуальная архитектура, техническая архитектура) позволяют управлять полнотой покрытия архитектурными артефактами;
Решения Архитектурного совета позволяют отслеживать всю историю изменений по АС и обосновывать закупки;
Метки мониторинга и инструкции для L1/L2/L3-поддержки позволяют быстрее закрывать инциденты;
Метки подключения к платформенным сервисам позволяют управлять проникновением платформы и оценивать переиспользование платформенных сервисов;
Индекс стоимости архитектуры АС. Это относительная стоимость АС, которая рассчитывается по соответствию системы архитектурным требованиям и основным характеристикам ИТ-ландшафта. Чем выше индекс стоимости, тем качественнее система и ниже затраты на владение и развитие.
Отдельно отметим, что мы заводим в реестр АС, а что не заводим. Для этого разработали следующую матрицу принятия решений:
Теперь немного рефлексии о плюсах и минусах данного подхода.
Плюсы
все функции и подразделения, которые задействованы в процессах создания ценности с ИТ-составляющей, начали «говорить на одном языке»;
минимизировали закупки или выдачу инфраструктуры под несогласованные АС;
выявили дублирование и вывели такие системы из эксплуатации (порядка 50 АС);
выстроили понятную систему распределения бюджета RUN и CHANGE в разрезе АС и ГАС;
выявили «белые пятна» в ИТ-ландшафте, провели аудит, наполнили объекты необходимой информацией для корректных схем сопровождения;
выстроили гибкий инструмент, позволяющий формировать новые аналитические срезы.
Минусы
Мы видим, что при реализации новых продуктов, например кредита наличными, требуется изменение сразу во многих ГАСах, таких как Сайты/ДБО, CRM, Кредитный конвейер, АБС и тд, таким образом возникает задача синхронизации большого количества команд и определения одного ответственного за продукт End-to-End.
Поэтому уже сейчас мы развиваем этот трек и добавляем к системе координат ГАС-АС объект управления «цифровой продукт», который должен иметь конечную ценность для клиента.
Надеемся, эта статья была вам полезна. Спасибо за внимание 😊