Стратегия построения архитектуры решений
Бизнес-стратегия и стратегия построения архитектуры решений тесно связаны и зависят друг от друга. Для успешного развития предприятия необходимо, чтобы архитектура соответствовала не только текущим потребностям бизнеса и клиентов и могла быстро реагировать на меняющиеся требования рынка, но и была способна создавать основу для реализации будущих целей бизнеса.
Плохое стратегическое планирование архитектуры, недостаток в обмене информацией и недостаточная прозрачность могут привести к неоптимальной производительности систем, что значительно снизит гибкость бизнеса.
SAFe выделяет 5 элементов архитектурной стратегии предприятия.
Пять элементов архитектурной стратегии
1. Выбор технологии и областей использования
Важным элементом разработки стратегии является выбор технологий, которые соответствуют ожиданиям роста бизнеса.
На этом шаге также проводятся исследования рынка и прототипирования, анализируется применимость технологий и сферы охвата, а также оценивается зрелость потенциальных инновационных решений.
2. Стратегия архитектуры решения
Архитекторы всех уровней (Архитектор Предприятия, Архитектор Решения и Архитектор Систем) находятся в тесном контакте друг с другом при разработке стратегии развития архитектуры решений. Это необходимо, чтобы архитектура отдельных продуктов разрабатывалась в рамках единых бизнес- и технологических целей организации.
Локально разрабатываемые решения должны соответствовать общей стратегии предприятия. Если какая-то локальная разработка противоречит общей стратегии, такие решения должны быть четко обозначены, так как несовместимость может повлиять на выполнимость всей стратегии предприятия.
3. Инфраструктурная стратегия
Этот элемент стратегии требует слаженной работы от Архитектора Предприятия и Архитекторов Систем. Это касается таких зон ответственности, как: повторное использование шаблонов конфигурации, общая физическая инфраструктура, обмен знаниями между Релизными Поездами и Поездами Решения. Особенно важно учитывать текущую и будущую работу Команд Системы, в первую очередь отвечающих за Конвейер Непрерывной Доставки.
Кроме того, часть инфраструктуры разработки и развертывания скорее всего будет пересекаться с внутренними ИТ-системами. Архитектор Предприятия отвечает за создание единого понимания развития инфраструктуры и разрабатывает стратегические рекомендации на уровне всего Предприятия.
4. Взаимодействие между командами команд (поездами)
Стандартизированные методы проектирования и построения инфраструктуры помогают упростить и обеспечить согласованность архитектуры в разных командах и поездах. При этом также важно, чтобы Потоки Ценности и Релизные Поезда имели достаточную степень автономии. В противном случае инновации идут на убыль. Поэтому как фиксированные, так и меняющиеся части архитектурного дизайна должны активно обсуждаться и приниматься участниками всех Релизных Поездов.
5. Стратегия реализации
Важность динамичной стратегии инкрементальной Agile разработки трудно переоценить. Создание технической основы для бизнес-эпиков в Архитектурном Русле должно быть непрерывным и постепенным процессом. Непрерывное обучение и быстрая обратная связь позволяют архитектуре и бизнес-функциональности развиваться синхронно с течением времени.
Agile команды должны проводить рефакторинг своего кода и сохранять несколько возможных вариантов проектирования (дизайна) там, где это целесообразно. Абстракция и обобщение помогают избежать привязки специфики на ранних стадиях, что обеспечивает архитектурную гибкость для будущих потребностей бизнеса.
Узнать больше:
Статья «Agile архитектура в SAFe» — https://ionovpartners.ru/blog/agile-architecture/
Курс «SAFe for Architects» — https://ionovpartners.ru/trainings/safe-for-architects/