ITIL4 Управление архитектурой: как не построить цифровой сарай

ITIL4 Управление архитектурой: как не построить цифровой сарай

20 мин
1074 чит. Полезно: 0 / 0

Она ответи на вопрос, что делать, если у тебя в компании зоопарк совершенно разных систем. Сегодня разберемся с управлением архитектурой по ITIL. Наведём порядок в шкафу, только в масштабах всей твоей ИТ-инфраструктуры.

Суть Architecture Management в ITIL 4

Architecture Management - это практика ITIL, которая отвечает за создание и поддержание чертежей твоей ИТ-среды. Представь, что ты строишь дом: архитектор рисует план, где какая комната, как проводка идёт, где трубы. Architecture Management делает то же самое, но для ИТ.

Конкретно эта практика занимается:

  1. Создание архитектурных принципов и стандартов
    • Какие технологии использовать, а какие - табу
    • Как системы должны взаимодействовать друг с другом
    • Какие паттерны проектирования применять
  2. Описание текущего состояния (AS-IS)
    • Что у нас есть сейчас: какие системы, как связаны, где узкие места
    • Инвентаризация всех компонентов архитектуры
  3. Проектирование целевого состояния (TO-BE)
    • Куда мы хотим прийти через год/два/пять
    • Какая архитектура нужна для поддержки бизнес-целей
  4. Планирование перехода
    • Как от текущего состояния дойти до целевого
    • Какие проекты запустить, в какой последовательности
  5. Управление архитектурными решениями
    • Когда разработчики хотят "вкрутить новую библиотеку", Architecture Management говорит "стоп" или "ок, но по таким правилам"

У тебя интернет-магазин на самописном PHP + MySQL и бизнес хочет мобильное приложение и интеграцию с 1С.

💩 Без Architecture Management: разработчики делают API как попало, мобилка дёргает базу напрямую, 1С интегрируется через FTP. Через год этот хаос никто не сможет поддерживать.

🏆 С Architecture Management: ты сначала рисуешь архитектуру с API Gateway, поднимаешь отдельный сервис, с единым стандартом API. Все новые системы строятся по этому плану.

Пример из моей практики

В чём фишка такого подхода:

Architecture Management - это не просто рисование схем умным видом.
Это именно управленческая практика, которая:

  • Связана с бизнес-стратегией
  • Учитывает жизненный цикл услуг
  • Интегрирована с другими практиками ITIL (Change Management, Service Design и т.д.)

Короче, суть в том, чтобы осознанно проектировать и развивать ИТ-архитектуру, а не лепить системы как попало и потом удивляться, почему всё тормозит и падает.

Если нужна одна схема - вот она

Architecture Management - это когда ты объясняешь джуну, почему нельзя подключать MongoDB напрямую к проекту на jQuery

🔥 Какие проблемы это решает

  1. Технический зоопарк - когда у тебя столько разных технологий, что сеньор, пришедший на проект, плачет и просится на курсы. А интеграции напоминают индийские провода на столбах.
  2. Бюджет улетает в трубу - когда 80% бабла уходит на поддержку легаси, а на новые фичи остаются копейки. И каждый раз приходится объяснять СЕО, почему нельзя просто починить.
  3. Скорость черепахи - когда конкуренты выкатывают новые фичи каждую неделю, а у тебя на добавление поля в форму уходит месяц, потому что оно используется в 15 разных местах.
  4. Постоянные факапы. Никогда не знаешь, что сломается на этот раз.
  5. Дублирование всего. Когда обнаруживаешь, что в компании три разных системы для управления клиентами, потому что каждый отдел думал, что он самый умный.

Когда пора этим заняться?

Если у тебя стартап из трех человек, которые пилят первую версию продукта - забей.
Но пора задуматься об архитектуре, если:

  • У тебя больше 5 разработчиков, которые не могут договориться, как делать правильно
  • Количество систем перевалило за 10, и ты уже путаешься, что с чем интегрировано
  • Каждый день начинается с "блядь, опять что-то упало"
  • Фича, которая по оценке должна занять неделю, растягивается на месяц
  • Ты уже не можешь нарисовать на салфетке схему всех систем и их связей

Но не надо сразу пытаться внедрять TOGAF и строить enterprise-архитектуру как в Сбере.
Начни с малого:

Размер компанииЧто делать
Стартап (до 10 человек)Просто документируй основные решения и не плоди зоопарк технологий
Малый бизнес (10-50 человек)Базовые принципы + документация + код ревью с учетом архитектуры
Средний бизнес (50-200 человек)Назначь архитектора + регулярные архитектурные ревью + стандарты
Крупный бизнес (200+ человек)Архитектурный комитет + формальные процессы + фреймворки

Как это работает на практике

Вот тебе пошаговая инструкция для чайников:

1. Разберись, что за хрень у тебя сейчас творится

  • Составь список всех систем (да, ВСЕХ, включая Excel-таблицы с макросами у бухгалтерии)
  • Нарисуй, как они связаны между собой (спойлер: будет похоже на тарелку спагетти)
  • Отметь самые больные места (где чаще всего падает, где больше всего костылей)

2. Придумай, как должно быть в идеальном мире

  • Пойми, куда движется бизнес (если не знаешь - иди и спроси у CEO)
  • Сформулируй базовые принципы (например, никаких прямых интеграций между системами или все через API. Да 1000 их, они нужны, чтоб все работали в ключе договоренностей)
  • Нарисуй целевую архитектуру (как должно быть через 1-2 года)

3. Введи правила игры

Привила разработки в Architecture Management
  • Создай процесс ревью (без этого все скатится обратно в хаос)
  • Определи, кто принимает решения (один архитектор или комитет)
  • Пропиши, как обрабатывать исключения (иногда правила можно нарушать, но осознанно)

4. Контролируй и обновляй

  • Регулярно проверяй, что реальность соответствует документации
  • Обновляй архитектуру по мере изменения бизнес-требований
  • Измеряй эффект (меньше инцидентов, быстрее внедрение новых фич)

Главное правило: архитектура - это не догма. Если твоя архитектурная документация не менялась больше полугода - она нахрен устарела.

Какие инструменты юзать в 2025 году для этого?

Для рисования красивых схемочек

  • draw.io - бесплатно, просто, работает везде, можно интегрировать с Confluence
  • PlantUML - для гиков, которые хотят писать диаграммы кодом
  • Mermaid - как PlantUML, только проще и с поддержкой в GitHub/GitLab
  • Archi - если тебе реально нужна ArchiMate нотация и ты понимаешь, зачем она

Для хранения всего этого добра

  • Confluence - классика жанра, можно хостить локально
  • GitLab + Markdown - для хипстеров, которые хотят хранить архитектуру как код
  • Notion - если хочется красиво и модно (но есть риски с блокировкой)

Для контроля качества

  • Любой статический анализатор кода - чтобы автоматически ловить косяки
  • Любой инструмент для анализа и визуализации зависимостей
  • Любой инструмент для автоматического написания тестов

Но помни: инструмент - это дай бог чтоб 10% успеха. Можно нарисовать охуенную архитектуру в блокноте, а можно просрать миллионы на Enterprise Architect и получить диаграммы, которые никто не понимает и не использует.

Как выбрать инструменты
Как выбрать инструменты для архитектуры

Как внедрить всё это?

Шаг 1: Подготовка (1 месяц)

  • НЕ ЧИТАЙ TOGAF ЦЕЛИКОМ - там 900 страниц корпоративного буллшита
  • Выбери, кто будет главным по архитектуре если читаешь эту статью, скорее всего это ты
  • Придумай 5-7 простых принципов типа "Все общаются через API" или "Никаких прямых запросов к чужим базам"
  • Убеди директора, что это нужно (покажи, сколько денег тратится на поддержку легаси)

Шаг 2: Разведка (1-2 месяца)

  • Составь список ВСЕХ систем
  • Нарисуй карту интеграций (будет похоже на тарелку спагетти)
  • Отметь самые больные места красным (где чаще всего падает)
  • Посчитай, сколько времени уходит на поддержку каждой системы
Твой пусть к управлению архитектурой
Твой пусть к управлению архитектурой

Шаг 3: Планирование (1 месяц)

  • Поговори с СЕО о планах на 1-2 года
  • Нарисуй, как должна выглядеть архитектура, чтобы поддерживать эти планы
  • Выдели основные архитектурные блоки (например, клиентские данные, биллинг, аналитика)
  • Определи, какие системы останутся, какие нужно заменить, а какие объединить

Шаг 4: Дорожная карта (2 недели)

  • Сравни "как есть" и "как должно быть"
  • Разбей переход на конкретные проекты
  • Расставь приоритеты (что болит сильнее всего - делаем в первую очередь)
  • Оцени, сколько времени и денег нужно на каждый проект

Шаг 5: Процессы (1 месяц)

  • Введи обязательное архитектурное ревью для всех новых проектов
  • Создай простые шаблоны для описания архитектурных решений
  • Определи, кто и как принимает архитектурные решения
  • Проведи пару воркшопов для команды, чтобы все поняли, зачем это нужно

Шаг 6: Инструменты (2 недели)

  • Выбери самые простые инструменты, которые реально будут использоваться
  • Создай репозиторий для хранения всей архитектурной документации
  • Настрой автоматические проверки там, где это возможно

Шаг 7: Поддержка (постоянно)

  • Регулярно проверяй, что реальность не разошлась с документацией
  • Обновляй архитектуру по мере изменения бизнес-требований
  • Празднуй маленькие победы "Смотрите, мы стали страдать на 30% меньше!"
Дорожная карта внедрения  Architecture Management
Дорожная карта внедрения будет выглядеть как-то так

Реальный пример

Что было

Спагетти архитектура
Вот такой вход при первом приближении

Боли:

  • Каждый релиз = молитвы
  • 85% бюджета уходило на поддержку этого зоопарка ада
  • Данные о клиентах в трех системах и везде разные
  • Чтобы добавить новую акцию, нужно было менять код в трех местах

Что сделали

  1. Собрали команду спасателей
    • Назначили главного архитектора (чувак, который дольше всех работал и знал все скелеты)
    • Привлекли по одному представителю от каждой системы
  2. Нарисовали карту боли
    • Задокументировали ВСЕ системы и как они связаны
    • Создали единую модель данных (оказалось "клиент" в разных системах - разные сущности)
    • Выявили, где данные дублируются и противоречат друг другу
  3. Спроектировали нормальную архитектуру
Правильная архитектура для ритейлера
Теперь даже заопарк технологий не такая уж проблема
  1. Внедрили процессы
    • Создали архитектурный комитет
    • Ввели обязательное архитектурное ревью для всех новых проектов
    • Разработали план миграции (что за чем менять, чтобы не убить бизнес)

Что получили

  1. Меньше систем = меньше головной боли
    • Вместо трех систем лояльности - одна
    • Вместо зоопарка интеграций - единая шина
  2. Бабло перестало улетать в трубу
    • Затраты на поддержку снизились минимум на треть
    • Высвободившиеся время разработки пустили на развитие фитч
  3. Скорость как у нормальных пацанов
    • Новые фичи стали делать сильно быстрее
    • Релизы перестали быть стрессом для всей компании
  4. Надежность выросла
    • Инцидентов стало меньше
    • Время отката теперь в половину меньше

Самое прекрасное, что вся эта движуха окупилась полгода года. Просто за счет того, что стали меньше тратить денег на поддержку легаси и костылей.

⚠️ Как делать не надо

Ошибка 1: Архитектура ради архитектуры

Что за хрень: Архитекторы рисуют красивые схемы, которые никто не использует, потому что они никак не связаны с реальными задачами бизнеса.

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

Ошибка 2: Архитектура для Нобелевской премии

Что за хрень: Архитектура настолько сложная и идеальная, что кроме ее создателя никто не может в ней разобраться.

Как не облажаться: KISS! (Keep It Simple, Stupid). Если джун не может понять твою архитектуру за 10 минут - она слишком сложная. Это не он не умный, это ты перемудрил!

Как выбрать правильную архитектуру, схема
Повесь на видном месте

Ошибка 3: Ð