NASCIO. Модели 4+1 и SAM. Методики Microsoft и другие. Выбор оптимальной методики

В частности, в составе собственно бизнес-архитектуры предлагается выделить несколько бизнес-областей (доменов). Это разделение может производиться как по функциональному (например, образование /здравоохранение /социальное обеспечение), так и по некоторому "тематическому" признаку (например; услуги гражданам/взаимодействие с другими органами власти/внутренние процессы) или географическому признаку. В составе этих бизнес-доменов выделяются отдельные архитектурные компоненты, рассмотрение которых может вестись с различных "перспектив", соответствующих столбцам в модели Захмана и с фокусом на двух верхних уровнях (строках) этой модели. В руководстве указывается на возможную целесообразность объединения таких перспектив, как "Кто?" и "Зачем?", вообще говоря, различных с точки зрения модели Захмана, в одну общую – "Стратегический бизнес". Важно отметить, что одни и те же выбранные перспективы должны будут применяться ко всем бизнес-областям.

Для каждой бизнес-области в описании определяются существенные принципы, лучшие практики и существующие тенденции. Далее, в составе бизнес-области формируются подчиненные документы, описывающие ее компоненты, которые фактически соответствуют отдельным ячейкам в верхних двух уровнях модели Захмана. Таким образом, в состав компонент могут входить, например, описание ролей (должностей) и их ответственности в организации, важные с точки зрения предприятия события и циклы деятельности, расположения офисов и т.п. Важным атрибутом описания является индикация типа состояния компоненты, т.е. относится ли это описание к существующему или целевому состоянию. Здесь прослеживается некая аналогия с подходом группы Зиндера и выделением "стратегического времени", хотя и в ограниченной интерпретации из всего двух состояний.

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

Представленный ранее в предыдущей версии руководства в рамках общей ИТ-архитектуры домен "Информация" в новой версии выделен в отдельную архитектуру информации. В ее составе определяются следующие элементы:

Кроме того, как и в случае бизнес-архитектуры, здесь явно выделяются Gap-компоненты.

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

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

Для описания конкретного решения используются три типа шаблонов:

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

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

Модель "4+1" представления архитектуры

Достаточно важную роль в развитии подходов к описанию архитектуры предприятия сыграла модель "4+1" (точнее "The 4+1 View Model of Architecture"), которая была предложена Филиппом Кручтеном (Philippe Kruchten) из компании Rational еще в 1995 году [5.19]. Данная методика позиционировалась, прежде всего, как способ описания архитектуры систем, основанных на активном использовании программного обеспечения, хотя идеи, заложенные в эту методику, могут использоваться и в более широком контексте архитектуры предприятия – что, собственно, и произошло на практике.

Модель предлагает простой и понятный способ описания архитектуры сложных систем, который состоит в использовании пяти различных категорий или представлений (views). Четырьмя основными представлениями в этой методике являются следующие:

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

Основной целью логического представления в данной методике является описание функциональных требований: что система должна выполнять в терминах конечных пользователей. Для этого представления используются различные абстрактные конструкции, такие как объекты и классы объектов. Для их иллюстрирования могут применяться диаграммы классов (в нотации языка UML) либо, например, диаграммы "сущность-связь", если в разработке приложения доминируют данные.

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

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

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

Сценарии объединяют все представления вместе. Сценарии использования описываются как последовательность взаимодействия объектов и процессов. Они отражают наиболее важные требования, которым должна удовлетворять система. Это представление в каком-то смысле является избыточным и пересекается с четырьмя предыдущими, но оно важно по следующим причинам:

Стратегическая модель архитектуры SAM

Методика Стратегическая модель архитектуры SAM (Strategic Architecture Model) является интересным инструментом анализа и документирования архитектуры предприятия и связанных с ней доменов. Краткое описание этой методики в контексте ее применения для создания бизнес-шаблонов архитектуры можно найти в [5.20], а более подробную информацию – на сайте http://www.systems-advisors.com или в [5.21]. Мы сочли необходимым включить ее в наш обзор, поскольку она содержит ряд оригинальных моментов, которые отличают ее от того, что мы встречали в остальных подходах. Кроме того, эта методика активно и успешно применяется, в частности, консультантами Microsoft во внутренних и внешних проектах и помогает в создании документов, которые передаются заказчикам и партнерам в ходе работы. Сама методика была разработана английской консалтинговой компанией Systems Advisers Ltd.

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

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

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

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

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

Внутри каждой области интересов сохраняется информация о какой-то определенной предметной области, что обеспечивает простоту сопровождения и извлечения этой информации. Обычно применяется одна или более иерархическая структура, которые напоминают ящик с файлами. Минимальный объем информации, относящейся к какой-либо сфере, называется элементом (member). Например, элементами сферы "Местоположение" могут быть "Головной офис", "Офис продаж в санкт-Петербурге", "Завод в Волоколамске" и т.д. Другими примерами элементов различных сфер являются:

В принципе, наименования сфер говорят сами за себя. Отметим только, что под бизнес-компонентами понимается совокупность данных и тех бизнес-функций, которые создают, читают, обновляют и удаляют эти данные. Группировка всех функций, создающих и обновляющих одни и те же элементы данных с помощью процесса под названием "коммутативная кластеризация" позволяет определить неизбыточное количество "строительных блоков" – компонент – которые могут использоваться для построения систем и приложений, поддерживающих определенные бизнес-процессы. Компоненты являются важными конструкциями в современных подходах к разработке систем. Достаточно вспомнить про сервис-ориентированную архитектуру SOA и архитектуру MDA, основанную на моделях. Объединение (инкапсуляция) функциональности и данных позволяет на практике добиться повторного и многократного использования элементов систем и дает возможность замены одних элементов другими. Компоненты предлагают "сервисы", которые могут использоваться в совокупности с другими сервисами, предлагаемыми другими компонентами в рамках сервис-ориентированной архитектуры.

Важное замечание, отраженное на нашем рисунке, состоит в том, что можно выделить три категории сфер:

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

Архитектурные концепции и методики Microsoft

Крупные компании-поставщики инфраструктурных информационных технологий, такие как Microsoft, IBM, SAP и другие могут "позволить себе роскошь" создания собственных методик разработки архитектуры информационных систем предприятия – конечно, с учетом своей области специализации. В то же время – это в какой-то степени и обязанность таких компаний, поскольку спектр предлагаемых ими технологий покрывает существенную часть архитектуры предприятия в целом, и специалистам нужны соответствующие практические рекомендации непосредственно от поставщиков.

Взгляды компании Microsoft на архитектуру информационных систем достаточно подробно изложены в [5.22]. Эти подходы в большей степени сфокусированы на процессах разработки конкретных программных прикладных систем и создании технологической инфраструктуры, включая центры обработки данных различного масштаба и уровня надежности. Как практически и во всех других методиках, здесь выделяются четыре представления (домена) в архитектуре: бизнес-архитектура, архитектура информации, прикладные системы и технологическая архитектура. Эти представления рассматриваются на различных уровнях абстракции: концептуальном, логическом и физическом. Помимо этого, явно выделяются процессы разработки прикладных систем, организация процессов эксплуатации технологической инфраструктуры и создание соответствующих шаблонов, которые могут использоваться как при разработке архитектуры систем, так и при ее создании.

При этом компания Microsoft выработала достаточно подробные методики, покрывающие различные аспекты архитектуры и, прежде всего, процессы разработки систем и создания инфраструктуры и процессы эксплуатации систем и инфраструктуры. В частности, это такие методики, как Microsoft Solutions Framework (MSF), Microsoft Operations Framework (MOF), Microsoft Systems Architecture (MSA) и Microsoft Solutions for Management (MSM), которые мы рассмотрим ниже.

Эти четыре взаимодополняющие методики Microsoft дают специалистам рекомендации, касающиеся следующих четырех основных вопросов:

Как мы увидим, методики MSF и MSA в большей степени относятся к процессу разработки архитектуры прикладных систем и инфраструктуры соответственно, а методики MOF и MSM – к архитектуре системного управления, т.е. вопросам управления и эксплуатации.

При этом MOF и MSF нацелены на различные, но связанные между собой фазы жизненного цикла ИТ-решений так, как показано на рис. 9.3.

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

То есть в идеале для каждой перспективы используется какой-то один тип моделей так, как это показано на рисунке. Но в реальности могут использоваться и несколько различных моделей для описания каждой из перспектив, т.е. концептуальной, логической и физической архитектур системы.

Рисунок 9.5 показывает взаимосвязи между различными перспективами в описании архитектуры, используемыми шаблонами проектирования, а также примерно отображает соответствие между методиками Microsoft и соответствующими элементами архитектуры.

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

Первый тип руководств – это архитектурные концепции, такие, например, как сервис-ориентированные подходы к проектированию архитектуры. Эти концепции обеспечивают следующее:

Второй набор руководств, которыми могут пользоваться системные архитекторы – это архитектурные шаблоны, о которых уже шла речь в лекциях 5-7 и которые основаны на практическом опыте большого количества успешно реализованных проектов создания распределенных прикладных систем; они явились следствием использования описанных выше архитектурных концепций. Эти шаблоны содержат в себе лучшие практики проектирования распределенных приложений и средства по минимизации рисков неудач проектов, поскольку рекомендуют хорошо апробированные модели (см. рис. 9.6).

Эти два типа руководств – архитектурные концепции и шаблоны – могут присутствовать и использоваться на различных уровнях проектирования архитектуры прикладной системы:

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

Поэтому помимо методик MSF, MOF, MSA и MSM компанией опубликованы подробные руководства по разработке архитектуры систем [5.23], а также шаблоны, которые могут применяться при проектировании корпоративных информационных систем [5.24]. Эти документы можно найти в открытом доступе на следующих web-страницах Microsoft, которые посвящены вопросам архитектуры: http://msdn.microsoft.com/architecture; http://msdn.microsoft.com/practices; http://www.microsoft.com/resources/practices. Читателям можно также посоветовать электронный журнал Microsoft Architecture Journal (http://msdn.microsoft.com/architecture/journ/).

Корпорация Microsoft при построении любых информационных систем (не только с использованием архитектур, платформ и продуктов Microsoft) рекомендует применять методику разработки приложений, получившую название Microsoft Solutions Framework (MSF). Одно из важных достоинств методологии MSF, которая во многом опирается на представления о современной программной архитектуре, состоит в том, что в результате следования дисциплине, принципам и методам, заложенным в ее основу, решения получаются комплексными, интеграционными, работоспособными, с ясно определенными приоритетами.

В таком контексте MSF как методика разработки архитектуры предприятия – это инструмент, который гарантирует, что деятельность подразделений информационных технологий будет ориентирована именно на бизнес-потребности.

Компоненты, составляющие основу методики MSF, могут применяться по отдельности или в совокупности для увеличения вероятности успеха в следующих областях:

Если кратко, то MSF содержит руководства по планированию, разработке, тестированию и внедрению решений. Модель архитектуры предприятия в рамках MSF характеризуется четырьмя задачами:

Компонентами MSF являются:

Разработка информационных систем с помощью MSF ведется в соответствии с концепцией "приоритета архитектуры", впервые предложенной в книге Уолкера Ройса "Управление программными проектами: унифицированный метод" ("Software Project Management: A Unified Framework" // Addison-Wesley, 1998). Она означает, что все три составляющие ИТ-проектов – планирование, создание и сопровождение системы – базируются на четко определенной высокоуровневой архитектуре, что эта архитектура сформирована до того, как начата разработка, и, наконец, что именно эта архитектура и определяет направление работы. Прежде чем применять подобный подход к конкретным приложениям, необходимо полностью определить архитектуру на уровне предприятия. Информация по MSF доступна в Интернет по адресу http://www.microsoft.com/msf, а на русском языке по адресу http://www.microsoft.com/rus/msdn.

Методика Microsoft Systems Architecture (MSA) относится к той части архитектуры предприятия, которая называется Технологической архитектурой. Задачей методики является стандартизация подходов к строительству центров обработки данных (Data Centers), которые лежат в основе любой корпоративной информационной системы. Методика MSA призвана помочь ИТ-подразделениям предприятий создать такие решения, которые отвечали бы шести основным требованиям: безопасности, надежности, доступности, быстродействию, управляемости и простоте технической поддержки. Залогом эффективности применения MSA на практике служит то, что все входящие в состав этого решения рекомендации появились на свет в результате тщательного тестирования описываемых конфигураций программного и аппаратного обеспечения в лабораторных условиях, моделировавших самые непростые ситуации из числа возможных в повседневной практике эксплуатации информационных систем.

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

MSA описывает следующие конфигурации инфраструктуры:

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

MSA предоставляет следующие документы для специалистов, решивших воспользоваться этой методикой:

Все это находится в свободном доступе по адресу http://www.microsoft.com/systemsarchitecture.

Другие архитектурные методики

На практике находят применение и другие средства описания архитектуры предприятия. Помимо неоднократно упоминавшейся нами методики Федеральной архитектуры США FEAF, в частности, могут быть полезными многочисленные примеры как шаблонов, так и готовых документов, определенные в методиках TEAF и С4ISR.

TEAF (http://www.ustreas.gov/) – архитектура Казначейства США, которая построена на основе федеральной архитектуры государственных организаций (FEAF), но проработана существенно глубже, чем первая, в силу того, что предназначается для отдельной организации. В состав TEAF включены шаблоны документов для большинства рассматриваемых областей.

C4ISR (http://www.defenselink.mil/) – архитектура, разработанная в 1996-98 гг. в Министерстве обороны США, содержит, помимо шаблонов, еще и значительное количество интересных примеров, хотя и немного устаревших. C4ISR (Command, Control, Communications, Computers, Intelligence, Surveillance and Reconnaissance) можно перевести как "Командование, Управление, Коммуникации, Компьютеры, Информация, Наблюдение и разведка".

С декабря 2003 года ее заменила так называемая рамочная архитектура Министерства Обороны или DoDAF (Department of Defence Architecture Framework – см. http://www.defenselink.mil/nii/doc/DoDAF_v1_Memo.pdf).

DoDAF содержит правила, руководства и продукты (документы или артефакты), которые должны использоваться при разработке и описании архитектуры различных систем, используемых военными ведомствами США. Все это, по мнению разработчиков, должно улучшить возможности информационных технологий с точки зрения быстрой мобилизации на выполнение военных операций и улучшить разработку соответствующих систем. Способность методики обеспечивать сравнение, анализ и интеграцию архитектур систем, используемых как в различных функциональных подразделениях, так и в географически распределенной организационной среде, является важным аспектом. Приведем только одну цифру, показывающую масштаб проблем, для решения которых предназначена методика: в Министерстве обороны США эксплуатируется около 28 тысяч различных систем!!!

Объем и, главное, содержание этих документов поражают особенно наряду с фактом их публичности. Это действительно весьма интересный материал, который представляет огромную пользу для всех специалистов, занимающихся вопросами информационных технологий в крупных (и не только военных) организациях. В то же время специалистам военной отрасли, наверное, будет полезно оценить стратегические цели в области создания так называемой Глобальной информационной сети (GIG – Global Information Grid), которая предназначена для поддержки боевых операций и деятельности в условиях мирного времени.

На рисунке 9.7 приведена структура основных представлений, используемых в DoDAF.

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

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

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

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

Есть определенные аспекты, имеющие отношение ко всем трем представлениям архитектуры. Эти общие аспекты отражаются с помощью общих для всех представлений продуктов (описаний – текстовых и графических). Такие продукты предоставляют информацию, относящуюся к архитектуре в целом, которая не подпадает под область ответственности отдельного представления. Они задают масштаб, границы (охват) и контекст архитектуры. Охват включает предметную область и временные рамки для архитектуры. Контекст архитектуры включает такие аспекты, как: доктрины, тактика и процедуры; связанные с ними цели и видение; концепция операций; сценарии; условия внешней среды.

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

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

Еще одной достаточно важной методикой является Справочная Модель Открытых Распределенных Вычислений (RM-ODP – Reference Model of Open Distributed Processing), принятая Международной организацией стандартизации ISO в качестве стандартов в четырех частях X.901, X.902, X.903 и X.904 [5.25].

В основе этой модели лежат принципы анализа систем в разрезе нескольких представлений и объектно-ориентированная парадигма создания систем. Заметим, что это методика – одна из наиболее полных с точки зрения набора различных представлений, которые могут применяться для описания архитектуры системы, и она используется, в частности, при описании архитектуры электронного правительства Германии.

Важными для этой модели понятиями являются представления, функции и средства обеспечения прозрачности распространения (distribution transparencies).

В целом модель определяет пять представлений (viewpoints):

Кроме представлений, RM-ODP содержит так называемые функции. Всего выделено четыре функции: управление, координация, репозиторий и безопасность.

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

RM-ODP выделяет восемь так называемых средств обеспечения прозрачности распространения: прозрачность доступа, сбоев, местоположения, миграции, сохранения, перераспределения, репликации и транзакций. Более подробную информацию можно найти по ссылке [5.25].

Eще одним интересным примером описания архитектуры является модель CAFCR [5.26], которая была разработана в компании Philips. Строго говоря, она относится не к моделям архитектуры предприятия, а первоначально предназначалась для разработки архитектур встроенных (embedded) систем, но позднее с успехом применялась и для более сложных комплексов – вплоть до глобальных систем управления автомобильным движением. Мы уже отмечали, что при исследовании таких "частных" архитектур выявляется достаточно много общих элементов, представляющих интерес и для более глобальных проблем архитектуры предприятия.

Аббревиатура СAFCR образована из названий пяти основных Представлений модели (Customer Objectives – Задачи Заказчика, Application – Приложения, Functional – Функциональность, Conceptual – Концепция и Realization – Реализация). Первые два представления помогают ответить на вопрос, "зачем" создается система. Функциональное представление описывает, "что" должна система выполнять. Интересно отметить, что, несмотря на название, в данное представление входят также и нефункциональные требования, такие как, например, требуемый интерфейс пользователя или выбор используемой СУБД. Наконец, последние два представления отвечают на вопрос, "как" должно осуществляться функционирование системы. При этом концептуальное представление изменяется со временем значительно слабее, чем представление, описывающее реализацию. Заметим, что принцип организации этих представлений в целом соответствует выбору столбцов в модели Захмана.

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

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

Заметим, что другой проект компании Philips, названный "Гауди" в честь великого испанского архитектора (это еще раз подчеркивает аналогию между традиционной архитектурой и архитектурой информационных систем), имеет еще более амбициозные цели – сформулировать рекомендации по созданию хорошей архитектуры и разработать систему подготовки архитекторов, которые смогут создавать такие системы [5.27]. Понятно, что в данном случае определяющими являются именно определения критериев "хорошей архитектуры", которые должны включать как объективные показатели, так и субъективное восприятие системы или продукта.

Выбор "оптимальной" методики

Краткое сравнение различных методик

Отметим еще раз, что, несмотря на формальное наличие стандартов в области описания архитектуры (ISO, IEEE, The Open Group и т.д.), ни одна из известных методик не имеет доминирующего положения в плане своего использования. Например, опрос, который в 2003 году проводила организация под названием Институт разработки корпоративной архитектуры (Institute for Enterprise Architecture Developments), показал, что примерно 32% организаций использовали свои собственные методики, 20% использовали модель Захмана, остальные методики упоминались не более 5-6% респондентами, хотя выборка и не являлась достаточно представительной.

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

Модель Захмана упоминается чаще всего. Она имеет безусловную ценность для архитекторов, хотя и с явными ограничениями. Она определяет матрицу 6х6, которая задает исчерпывающую схему классификации элементов описания архитектуры и покрывает все аспекты моделирования. Однако для многих клеток этой матрицы корпоративные архитекторы определяют, в лучшем случае, шаблоны проектирования, а не продукты описания архитектуры в полном смысле этого слова. Например, в клетке на пересечении столбца "ЧТО" и строки "Физический уровень" определение архитектуры заканчивается стандартным сервером приложений. Есть также некоторые относящиеся к описанию архитектуры документы, которые непонятно куда помещать с точки зрения классификации матрицы Захмана (например, общую стратегию развития прикладных систем на ближайшие годы). С другой стороны, верхние уровни модели Захмана обеспечивают весьма полезную структуру для совместного обсуждения проблем архитектуры предприятия с бизнес-руководством.

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

Методика Федеральной архитектуры правительства США FEAF, разработка которой началась в конце 1990-х годов, содержит хороший обзор видения и принципов архитектуры предприятия. Документы, содержащие общее описание методики FEAF, имеют ссылки на некоторые остальные методики, например, Захмана. Методика FAEF содержит четыре представления (бизнес, информация, приложения, инфраструктура) и пять справочных моделей для их описания. Сильной ее стороной является детальная проработка каждого из представлений. Интересен и аспект, связанный с показателями эффективности (часть бизнес-архитектуры), а также отслеживанием связей между этими показателями и использованием информационных технологий.

Методика TEAF казначейства США построена на основе и с учетом FEAF, но многие аспекты в ней проработаны гораздо более детально. TEAF содержит много хороших примеров архитектурных принципов и документов, создаваемых в результате работы над архитектурой. Методика предлагает упрощенную матрицу для категоризации документов и моделей описания архитектуры (4 x 4 вместо 6 x 6, как у Захмана) и содержит указания о том, какие модели к каким ячейкам таблицы имеют отношение.

Методика C4ISR (DoDAF) Министерства обороны США аналогична TEAF в том плане, что является очень детальной и содержит большое количество примеров моделей и документов, используемых для описания архитектуры. Однако она идет дальше TEAF в том плане, что приводит большое количество фактических примеров этих моделей и документов (а не только шаблоны). Наличие в этой методике большого количества примеров и детальный характер всех описаний делает ее отличным учебным пособием и примером для определения того, что такое архитектура предприятия и какие с ней связаны документы и описания.

Методика RM-ODP, на которую также ссылаются как на ISO/IEC 10746, имеет много общего с IEEE 1471 в плане определения метамодели архитектуры, но идет гораздо дальше в отношении определений и документировании специфических принципов. Наиболее сильной областью использования является разработка программных систем, образовательные цели и определение архитектурных терминов.

Методика NASCIO национальной ассоциации государственных CIO содержит описания и образцы процессов, используемых для управления архитектурой и жизненным циклом архитектуры, а также форматы и примеры документов с описанием технологической архитектуры.

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

Детальные описания методики META Group, так же как и Gartner, отсутствуют в публичном доступе, но они содержат очень подробные описания различных представлений архитектуры и документов, включая шаблоны этих документов, которые должны создаваться в процессе работы над созданием архитектуры (видение общих требований, концептуальная архитектура, бизнес-архитектура и т.д.). Детально описана сама организация архитектурного процесса и его связь с остальными аспектами управления ИТ, в частности, с управлением корпоративными проектами.

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

Сильными сторонами архитектурных методик Microsoft является их практическая близость к предметной области разработки архитектуры и эксплуатации сложных программных систем. В плане описания представлений об архитектуре это в какой-то степени подмножество подхода Захмана. Хорошо отражены организационные моменты, такие как работа команд и пр. Документы находятся в публичном доступе, что также является положительным аспектом.

В таблице 9.4 приведены сильные стороны некоторых из перечисленных нами моделей по степени детализации и определенности.

Сопоставление возможностей различных моделей описания архитектуры

Модель	IEEE POSIX 1003.23	Модель Захмана	TOGAF	FEAF	Методики Gartner	Методики META Group	NASCIO Toolkit	Методики Microsoft
Характеристика
Иерархический подход, возможность cвязи с бизнес-стратегией
Поддержка различных уровней абстракции
Формальный язык и система обозначений
Описание процесса разработки архитектуры
Рекомендации по управлению архитектурой

Рекомендации, касающиеся использования методик

В данном разделе мы приводим заключительные рекомендации, которые являются определенной компиляцией идей из рассмотренных выше описаний отдельных методик.

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

Следующая рекомендация состоит в интеграции всего того лучшего, что имеется в методиках относительно управления и надзора за архитектурой (governance), выстраиванием процессов, принятием принципов и документов (моделей), описывающих архитектуру. Особенно важно изучить примеры моделей и документов (артефактов), описывающих архитектуру, поскольку именно они должны предъявляться в качестве практических результатов работы. Не следует рассматривать предлагаемый набор артефактов как догму, напротив, он может быть адаптирован под конкретные особенности. То есть приоритеты должны быть расставлены в соответствии с практическими потребностями в тех или иных элементах описания архитектуры, а не исходя из академической точности. Здесь более важна связь этих отобранных вами элементов описания архитектуры между собой, с методикой в целом, с процессами управления и контроля над архитектурой и процессом разработки прикладных систем.

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

Мы еще вернемся к этим вопросам в лекциях 10-12, посвященных практической организации процесса разработки архитектуры.