Пересказ выступления на Арх. конф бай Сбер декабрь 2025.
Почти год назад, нас - команду крайне скиловых ИТ-менеджеров и инженеров высадили в одну компанию, владельцем которой являлся наш работодатель. Высадка эта имела цель - привести в срочном порядке ИТ в приемлемое состояние - обеспечить стабильность устойчивое развитие и так далее.
Начнем с начала, что за компания?
- Один из крупнейших luxury-курортов в России
- Включает: гостиницу, СПА, рестораны, конференц-залы, винодельню, сыроварню. парк развлечений, медицинский институт, клиника и много чего еще
- Дополнительно: девелоперские проекты, управление недвижимостью
- 15 разных бизнесов
- ИТ в бизнесе, а не отдельная функция
- Полное отсутствие документации.
- И 1500+ бизнес-процессов (к этой цифре пару раз еще вернусь).
В целом все вообще не удивительно, сфера гостиничного бизнеса всегда славилась вложением в ИТ по остаточному принципу.
Но тут так не прокатит - огромный комплекс, который еще и развивается семимильными шагами, тот уровень который был не смог
Ну и точная задача:
Необходимо составить стратегию цифровизации на 10 лет вперед, которая по факту является обоснованием инвест-стратегии и ошибка в ней очень дорого может сказаться на дальнейшем развитии ИТ и всего Предприятия.
Первые шаги.
Итак, есть я и я в ресурсе )), есть почти месяц и абсолютно не описанный бизнес, часть которого имеет большую специфику, которая, в свою очередь, мне не известна.
Нужно выработать подход, да такой, чтобы в указанные сроки получить корректную архитектуру AS-IS и TO-BE, правила транзита, арх. процесс и все остальное.
И тут пошел по пути организации процесса и всего вокруг него не по книжке, а через опыт и знания. Было сделано два акцента:
- Метамодель - архитектурные артефакты, их состав, назначение, связь. Должна решать описанные проблемы, быть наглядной для непрофессионалов и не содержать ничего лишнего.
- Арх. процесс - собранные данные не должны устаревать, а изменения должны верефицироваться и фиксироваться.
Начнем с мета-модели.
Сейчас она другая, чуть усложненная, но тогда сделал так.
Еще раз про задачу: мне нужно было описать бизнес, сделать это как можно точнее и как можно быстрее. Привязать к этом информационные системы. И составить, как минимум, концептуальную модель данных.
За основу взял карту бизнес-способностей (BCM). Бизнес-способность у меня реализовывалась автоматизированными системами (АС)
Бизнес-способности композировались по бизнес доменам и областям, а те в свою очередь, распределялись по слоям.
Сами бизнес-способности имеют проблемку исходя из определения - они могут быть очень разного размера, что в целом так же плохо. BCM должно позволять не только оценить составные части бизнеса, но и выполнять, например, трассировку изменений - определение количества АС при изменении или создании БС и так далее.
Для этого БС у меня имеют обязательные атрибуты:
А так же способ проверки назовем это Defenition of ready: наличие людей, исполняющих это БС, процессов в ней, данных и технологий. Если их нет - наверное это не бизнес-способность.
Кроме того, я отказался от декомпозиции по размеру БС. Как показал опыт - это потенциальный corruption который ведет к запутыванию, увеличению количества БС и полной не читаемости BCM.
Домены БС - сгруппированные по похожести атрибутов бизнес-способности в рамках отдельной области бизнеса.
Бизнес-слои - эта штука поинтереснее, в то же время вещь простая и понятная. Для того, чтобы сконцентрироваться на самом важно, а на не важном не концентрироваться, сделал три слоя CORE, GENNERIC и SUPPORT по полной аналогии с свойствами доменов в DDD.
Два промаха.
Первоначально планировал использовать бизнес-метрики для нормализации карты. Но выяснилось (кто бы мог подумать), что метрики роляют только если их считать.
Второе: бизнес процессы. Они есть, они описаны. но описаны они ради описания, вспоминаем "Транзит ответственности": если артефакт не используется в процессе, а желательно до самого его завершения, то ценности он не несет и решает только проблему необходимости своего создания.
По этому бизнес-процессы я исключил в итоге.
Репозитарийи инструменты.
Времени мало, ресурсы ограничены при этом нужен простор под эксперименты. Шанс, что я сразу делаю все правильно далеко не 100%.
Должна быть возможность быстро менять подход и мета модель. По этому выбор инструментов и репозитария у меня был быстрый: git+plantUML + скриптики.
Что я получил:
- За счет гита - версионность и историю изменений
- За счет plantUML- возможность быстро менять метамодель и отображение, а так же plant UML это ахитектура как код и мы к этому вернемся.
- За счет скрипточков - связанность моделей, возможность валидации и генерации
Ну страх конечно, с точки зрения сексуально-оптического восприятия, но это данные которые руками можно переложить в draw.io например.
При этом, я сделал две связанные вьюхи: бизнес карта с слоями и доменами, а так же распределение БС по АС.
был план сделать экспортер в draw.io но в какой-то момент мне стало лень.
Как это все наполнить?
Как? Пойти опрашивать бизнес? Смысла не много, кроме того, что на это просто нет времени, бизнес будет поставлять информацию в формате его восприятия, скрывая какие-то очевидные для него вещи. Когда итераций описания много - это нечего. А вот когда она почти одна - это уже серьезная проблема.
Мои 15 бизнесов не уникальные, это не еком с которым дело имел до этого.
Берем референсные модели из TOGAF, SAP и так далее, а так же функциональное описание отраслевых ИТ-решений: там Oracle PMS, Micros, iiko и так далее. Нормализуем данные и крутим RAG модель на основе OpenAI API.
В целом на картинке выше было, что делал бы сейчас и то, что делаю на завтра. Но уже совсем не так, То, что делаю на основе своего опыта - это про самоуправляемую архитектуру на основе ML-моделей.. Но об этом отдельной статьей.
Чего получилось?
Получилось ни 100% очевидно попадание, но за одну итерацию верефикации полученой BCM удалось получить картину AS-IS, чуть докрутив модельку - получить почти гарантированно корректную картину TO-BE, верефицировав её с бизнесом.
Про процесс.
Я уже говорил и не раз, что артефакт который не используется и не верефицируется - скорее мертв. По этому немного оп процессе.
Тут все просто, картину как есть просто стер и пустил все изменения в ИТ через арх. ком. Но на этом останавливаться сильно не будем.
Что получилось?
Класс, я рассказал как вспотел, но что получила компания?
Неожиданно управляемый ИТ через архитектуру. Почему так произошло? В основном, потому, что архитектурный процесс завязан на бюджетный, топ-менеджмент вдруг стал заказчиком архитектурной функции.
Но дело еще в том, что я не только главный архитектор, но так же руковожу change деятельностью в компании.
Ну и в завершении. Какие уроки я извлек?
ну и собственно главное - открыл для себя практическую пользу ML и ИИ в производственных арх. процессах.