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

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

На практике находят применение и другие средства описания архитектуры предприятия. Помимо неоднократно упоминавшейся нами методики Федеральной архитектуры США 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.

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

Рис. 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):

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

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

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

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

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

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

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

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

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

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