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

Оптимальный уровень детализации и распределения усилий в процессе создания Архитектуры предприятия

Достижимость стандартов

Как же на практике реализуется "самый нижний" уровень ИТ-архитектуры предприятия, связанный непосредственно с определением инфраструктуры ИТ? Принимая во внимание наличие детально разработанных стандартов открытых систем, их "привлекательность" и "обоснованность" со стороны многих международных, национальных и некоммерческих организаций по стандартизации, можно было бы ожидать, что за прошедшие с их появления примерно 10 лет большая часть окружающих нас информационных систем должна бы полностью соответствовать их принципам.

Увы, в действительности этого не наблюдается. Основные причины заключаются в том [6.28], что, с одной стороны, эти стандарты не являются необходимо полными, а с другой – производители программных и аппаратных средств реально далеко не всегда выпускают взаимозаменяемые продукты, даже когда они (частично) соответствуют одним и тем же стандартам. Дополнительным фактором может являться значительное время, которое требуется для согласования и утверждения стандартов. Поэтому многим предприятиям приходится выбирать ограниченное количество вендоров и в дальнейшем руководствоваться совместимостью с данными технологиями.

Следствием такого выбора становится тот факт, что принцип "единства архитектуры" перестает быть абсолютным. В ряде случаев оказывается, что определенное отклонение от установленных принципов может быть обосновано. Например, предприятие могло бы выбрать СУБД Oracle и UNIX-платформу для ведения основных производственных баз данных, требующих высокой производительности и надежности. Но для реализации решаемой в течение одного месяца задачи ввода данных из архивов вновь приобретенной компании вполне могут использоваться более простые и дешевые средства. Другим примером может служить применение готового, существующего на рынке, приложения для решения частной задачи одного из бизнес-подразделений. Даже если это приложение будет использовать другую СУБД, отличную от той, которая определена в стандарте предприятия, практически во всех случаях стандарт будет либо проигнорирован, либо пересмотрен. В любом случае, нужно также учитывать и факторы инвестиций и времени, необходимых для перехода к единой архитектуре в масштабе предприятия. При этом, как правило, чем более жесткие ограничения накладывает архитектура предприятия, тем менее она становится полезной на практике.

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

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

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

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

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

Выше, в "Архитектура предприятия: основные определения" , "Интегрированная концепция и уровни абстракции" , мы рассматривали различные уровни архитектурных решений:

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

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

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

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

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

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

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