1. Управление архитектурой в 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-архитектуру как в Сбере.
Начни с малого:

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

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

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

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

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

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

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

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

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% меньше!”

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

Что было

Боли:

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

Что сделали

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

4. Внедрили процессы
   • Создали архитектурный комитет
   • Ввели обязательное архитектурное ревью для всех новых проектов
   • Разработали план миграции (что за чем менять, чтобы не убить бизнес)

Что получили

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

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

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

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

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

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

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

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

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

Ошибка 3: Архитектура в вакууме

Есть красивые диаграммы, а есть реальный код. И они никак не связаны между собой.

Как не облажаться: Вовлекай разрабов в архитектурные обсуждения. Кодревью! Автоматизируй там, где можно и есть выбил деньги на это.

Ошибка 4: Давайте всё перепишем с нуля

Архитекторы рисуют идеальный мир, игнорируя тонны легаси и технического долга.

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

Ошибка 5: Один раз нарисовал и забыл

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

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

🎯 Чек-лист юного архитектора

1. Убедил CEO, что это нужно (без этого все остальное бессмысленно)
2. Решил, кто главный по архитектуре (ты или кто-то еще)
3. Придумал 5-7 простых архитектурных принципов, которые все могут запомнить
4. Составил список систем и нарисовал, как они связаны (карта боли)
5. Отметил самые проблемные места и посчитал, сколько они жрут ресурсов
6. Поговорил с бизнесом о планах на будущее
7. Нарисовал, как должна выглядеть архитектура через 1-2 года
8. Составил план перехода от как есть к как должно быть
9. Внедрил процесс архитектурного ревью для всех новых проектов
10. Выбрал простые и понятные инструменты для документирования
11. Создал место, где хранится вся архитектурная документация
12. Создал процесс регулярного обновления документации
13. Придумал, как измерять, что стало лучше (меньше инцидентов, быстрее релизы)
14. Объяснил команде, зачем все это нужно и как им это поможет

Заключение

Architecture Management – это не про красивые диаграммы в модных инструментах и не про умные слова на совещаниях. Это про то, чтобы перестать страдать с легаси и начать делать нормальные системы, которые можно развивать, а не поддерживать на соплях.

Главное правило: хорошая архитектура не та, в которую нельзя ничего добавить, а та, из которой нельзя ничего убрать без последствий.

Начни с малого, двигайся итерационно, и через год ты будешь смотреть на свой старый код и думать: “Какой же я был долбоеб”.