Adaptive Enterprise Architecture: Towards a model (Рубрика Architecture)
Недавно я решил почитать whitepapers по enterprise architecture и наткнулся на статью ученых из Морокко, где они пытаются скрестить ежа с ужом, а точнее корпоративную архитектуру со скрамом:) В начале статьи авторы отмечают, что текущие подходы к корпоративной архитектуре (TOGAF, Zachman) не обладают необходимой гибкостью для обработки быстрых, разноуровневых изменений, что характерны для модных ныне цифровых трансформаций. Они сосредоточены на реактивных процессах, ориентированных на заполнение кучи документов и с их помощью сложно управлять непредвиденными изменениями. Дальше авторы решают сформулировать набор критериев для адаптивной корпоративной архитектуры, куда входят такие вещи как 1) Support multi-level dynamics (поддержка многоуровневой динамики) - изменения бывают на разных уровнях и идут с разной скоростью, а значит архитектурный процесс должен уметь работать с каждым типом изменений. Авторы отмечают, что стандартный подход с архитектурой as-is и to-be уже не является статичным, а подвергается различным изменениям, что надо учитывать в архитектурных процессах 2) Sensing of change (ощущение изменений) - процесс должен поддерживать ощущение идущих вокруг изменений и позволять планировать свои инициативы для адаптации к изменениям 3) Process of adaptation (процесс адаптации под новые потребности) - это ключевая часть подхода авторов, что называется adaptive enterprise architecture 4) Complexity of change management (комплексность управления изменениями) - TOGAF и Zachman проваливают этот критерий, ребята хотят подход, который будет сильно проще с точки зрения управления изменениями 5) Handling of unforseen changes (обработка непредвиденных изменений) - это нужно для современных корпораций, что сталкиваются с высокими темпами непредвиденных изменений в своем бизнес окружении. 6) Explicit management of adaptability trade-offs - авторы отмечают важность явного управления компромиссами по адаптивности к изменениям. Сейчас это зачастую просто одно из нефункциональных требований или атрибутов качества решений, а в новом подходе им надо управлять явно 7) Evaluation of adaptation (эволюция адаптации) - для управления адаптацией ее надо уметь измерять, а занчит нам нужны метрики внутри процесса корпоративной архитектуры
Дальше авторы сравнивают по этим критериям разные подходы к корпоративной архитектуре и оказывается, что все они не удовлетворяют критериям. Они объединяют подходы в группы
- Approaches based on guidelines (Zachman, TOGAF, Koffi A.D, LEAP, DYA)
- Integration oriented approaches (Shmidt R & al, Zimmerman A & al)
- Co-evolution oriented approaches (DEEVA, ACEM, ...)
И дальше авторы решают предложить свой подход, который удовлетворяет критериям и полагается на проверенные временем agile подходы, а точнее на Скрам. Дальше они рассказывают о том, какой Скрам замечательный, а потом натягивают его на архитектуру
- У нас появляется роли architecture owner, business/IT owners. Первый отвечает за стратегический alignment, а вторые за оптимизацию бизнес-процессов и технического решения
- Работа идет в циклах по 2-4 недели и используются скрам ритуалы: weekly cross-owner syncs, architecture reviews для обеспечения фидбека
- Появляется архитектурный беклог, в котором приоритизируются изменения корп архитектуры, а также есть KPI и отслеживание движения As-Is / To-Be на графиках Все остальные ритуалы agile про связь бизнеса и IT остаются на месте, просто EA беклог и ритуалы адаптивной корпоративной архитектуры живут рядом.
Для меня это whitepaper показался натягиванием совы на глобус без особых объяснений как это будет работать на практике, а не на бумаге:)
#Architecture #Software #Management #Governance #Engineering