Критерии «хорошей» архитектуры

Содержание

1. Введение  ………………………………………………………….. 3
2. Критерии «хорошей» архитектуры …………………………….... 5
3. Заключение ……………………………………………………… 12
4. Список используемой литературы ……………………………... 13

Введение 

      Архитектура предприятия - общий план или концепция, используемая для создания системы, такой как здание или информационная система, или "абстрактное описание системы, ее структуры, компонентов и их взаимосвязей". Для каждой такой системы, существует ряд стандартов, которых, при создании данных систем, компании или организации должны придерживаться.

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

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

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

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

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

     Критерии  «хорошей» архитектуры 

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

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

     Существуют  различные уровни архитектурных решений:

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

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

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

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

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

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

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

     Такими  элементами являются временные интервалы, которые должна охватывать "достаточно хорошая" архитектура

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

     Gartner рекомендует 15% усилий и внимания  уделять существующей сегодня  в организации архитектуре, 70% –  архитектуре, которую предполагается  реализовать в ближайшем будущем,  и еще 15% усилий – архитектуре,  как она видится в отдаленной  перспективе.

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

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

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

     Рис. 1.  Стратегическое окно возможностей для "достаточно хорошей" архитектуры 

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

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

     Необходимо  также учитывать еще один временной  горизонт, который называется "стратегическое окно возможностей":

     Тактическое окно – 9 месяцев.

     Скользящее  окно оперативных возможностей – 18 месяцев.

     Стратегическое  окно – 30 месяцев.

     Интересно отметить, что за прошедшие между  двумя публикациями Gartner 4 года рекомендуемая  продолжительность среднесрочного горизонта планирования сократилась  с 2-3 лет до 18 месяцев, а стратегического  горизонта – с 3-5 лет до 30 месяцев. Очевидно, что это связано с  влиянием происходящего глобального  ускорения бизнес-процессов и  постоянного развития информационных технологий.

     Архитектура должна приносить пользу, прежде всего, с точки зрения достаточно короткого, 9-месячного промежутка времени. Окно оперативных возможностей должно постоянно  перемещаться и соответствовать  интервалу примерно в 18 месяцев. Это  тот период времени, который связан с нашим понятием "архитектура  завтрашнего дня". Стратегическое окно должно быть не более 30 месяцев  и соответствовать принятому  в компании горизонту стратегического  планирования.

     Третья  метрика связана с распределением усилий на различных фазах жизненного цикла архитектуры. Управление, руководство  и надзор над процессом создания архитектуры должны занимать примерно 40% всех усилий по созданию архитектуры. Вторым по "значимости" аспектом проекта – порядка 30% усилий – является собственно разработка моделей, стратегий, решений и их документирование, то, что обычно понимается под понятием "построение, разработка архитектуры". Примерно по 15% усилий рекомендуется сосредоточить на обеспечении восприятия предложенных решений со стороны руководства и бизнес-подразделений – то есть "продаже" идеи внутри организации, а также на проведение оценки и сравнительного анализа с лучшими практиками или доступными аналогами.