Минималистский подход и достаточно хорошая архитектура

Выше мы уже говорили о том, что архитектура предприятия неизбежно является упрощенной моделью бесконечно сложной реальности под названием "организация". Это означает, что нужен компромисс в степени детализации такого описания.

Основная рекомендация, которая существует на этот счёт, состоит в том, что следует придерживаться минималистского подхода в проектировании архитектуры, т.е. определять требования к архитектуре самого высокого приоритета и затем делать минимально возможное и не более того, чтобы удовлетворить этим требованиям. Это позволяет иметь ограниченный и контролируемый набор архитектурных решений, но в то же время оставляет необходимую степень свободы для технических специалистов по реализации функционала тех или иных систем.

Ранее мы рассматривали различные уровни архитектурных решений:

• уровень предприятия;
• уровень проекта (или семейства систем);
• уровень отдельной системы.

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

Это требует от нас более четкого осознания того, какие же все-таки решения являются архитектурными. Однозначно под эту категорию решений подпадают те, которые связаны с идентификацией структурных элементов систем или проектированием интерфейсов между элементами, включая спецификации и описание видимого поведения и свойств системы.

Очевидно, что архитектура предприятия должна скорее быть гибкой, чем идеальной. Это нашло отражение в принципе, который был сформулирован как "достаточно хорошая" архитектура. При этом принцип "достаточно хорошей" архитектуры противостоит стремлению создания "идеальной" архитектуры. Философия заключается в том, чтобы создать достаточно гибкую и восприимчивую архитектуру, которая может модернизироваться в процессе своего жизненного цикла в ответ на изменения в моделях бизнеса и технологиях, и это гораздо важнее, чем создание теоретически правильной, идеальной архитектуры, представляющей полное и конечное видение.

Для реализации этого подхода рекомендуется следовать следующим трем принципам:

• Быть гибким и разграничивать уровни архитектуры. Гибкость может, в частности, достигаться за счет разделения архитектуры на предметные области (Бизнес-архитектура, Архитектура прикладных систем и т.д.). Это позволяет ограничивать необходимость внесения изменений, понимать влияние изменений в одной предметной области на другие и не переделывать всю архитектуру целиком. Например, если в прикладной системе было принято решение о смене используемой системы управления базами данных, то, если вы четко придерживались принципов создания систем "клиент/сервер", такая смена не потребует изменений в логической архитектуре и в моделях.
• Концентрация на наиболее важных частях архитектуры. Используйте правило 80/20 при определении того, над какими частями архитектуры работать. Концентрируйтесь на вопросах, которые действительно важны для организации. Например, если самым высоким приоритетом является интеграция и взаимодействие систем или простота доступа пользователей к данным, то концентрируйте работу именно в этой области. При этом, конечно, важно сохранять общий взгляд на архитектуру в целом, но такой подход к приоритетной проработке определенных частей архитектуры позволяет добиться в краткосрочном плане позитивных результатов.
• Создавайте архитектуру, которая может развиваться итеративно. Основной предпосылкой должно быть то, что архитектура будет достаточно часто изменяться. Поэтому надо изначально предусмотреть такие механизмы, организационные структуры и методы управления и надзора за архитектурой, которые бы позволили вносить изменения так часто, как это требуется.

При этом имеются и другие элементы, определяющие "достаточно хорошую" архитектуру.

Дата добавления: 2013-12-13