NASCIO Architecture Toolkit

Набор шаблонов IT Architecture Toolkit, разработанный американской ассоциацией CIO, первоначально позиционировался как специализированное средство для документирования ИТ-архитектуры организации. Основное преимущество его использования заключается в построении иерархической системы описаний элементов, удобной для поддержания жизненного цикла документа, т.е. в форме, предполагающей его возможные изменения в будущем по мере изменения требований бизнеса и совершенствования технологий. Однако в версии 3.0, опубликованной в октябре 2004 года, предмет его рассмотрения уже охватывает и область бизнес-архитектуры, так что он может рассматриваться наряду с другими универсальными рамочными моделями. Другим весьма полезным обстоятельством является большое количество реальных примеров из практики отдельных американских штатов и федеральных организаций.

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

· области или домены (Domains) ИТ-архитектуры;

· дисциплины;

· технологические дисциплины;

· продуктовые компоненты;

· документы соответствия.

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

· управление приложениями;

· управление данными;

· управление информацией;

· интеграция;

· управление пользователями и доступ;

· сети и коммуникации;

· платформы;

· управление системами;

· информационная безопасность и т.п.

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

Например, в домен Управление системами входят, в том числе, следующие дисциплины:

· Управление активами (Asset management).

· Управление изменениями (Change management).

· Управление событиями (Event Management).

· Поддержка пользователей (HelpDesk).

· Обеспечение непрерывности бизнеса (Business continuity) и др.

Технологические дисциплины – это технические дисциплины, которые поддерживают функциональные технологические разделы архитектуры. В качестве примера (см. табл. 9.3 ниже) можно привести Дисциплину " Управление данными" (Data Management), которая является частью Области " Информация". Дисциплина " Управление Данными" может включать в себя такие Технологические Области, как:

· реляционные СУБД;

· плоские файловые системы;

· настольные базы данных;

· модели данных.

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

Продуктовые компоненты включают протоколы, продукты (семейства продуктов) и конфигурации, которые специфичны для каждой технологической области. Примерами Продуктовых Компонент, которые могут быть идентифицированы в рамках технологической области " Модели Данных", являются такие продукты, как ERWin, Visio и Designer 2000. Документация для каждой компоненты включает оценочные критерии, которые были использованы для включения продуктовой компоненты в общую технологическую архитектуру.

Документы Соответствия определяют руководства, стандарты и регулирующие документы, которые связаны с Дисциплинами, Технологическими дисциплинами и/или Продуктовыми компонентами. Они предписывают необходимость соблюдения тех или иных международных рекомендаций (RFC), стандартов, законодательных актов – например, по применению сертифицированных средств ЭЦП, внутренних инструкций и т.п.

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

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

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

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

Пример приведен в табл. 9.2.

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

В версии 3.0 набор включает в себя как процесс управления ИТ (IT Governance), так и следующие 4 взаимосвязанные архитектуры:

· бизнес-архитектуру;

· архитектуру информации;

· технологическую архитектуру (практически соответствует всей ИТ-архитектуре, рассмотренной в версии 2);

· архитектуру решений (Solution Architecture), поэтому структура модели частично изменилась.

Таблица 9.2. Пример иерархии описания архитектуры в соответствии с рекомендациями NASCIO
Область (Домен)	Дисциплина	Технологическая дисциплина	Продуктовые компоненты	Документы Соответствия
Информация	Управление Данными	· реляционные СУБД	· MS SQL · Oracle · DB2	· стандарты предприятия на именование хранимых процедур
· плоские файловые системы		· квоты на использование общего дискового пространства
· настольные БД	· MS Access	· стандарты предприятия по защите БД Access
· модели Данных	· ERWin · MS Visio · Designer 2000	· нормализация данных · стандарты предприятия на именования таблиц и атрибутов

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

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

Таблица 9.3. Области и Дисциплины
Область	Дисциплины
Информация	· Управление данными (Data Management) · Управление Знаниями · Геоинформационные системы (GIS) · Хранение данных
Приложения	· Управление Средствами Разработки Приложений · Электронные средства совместной работы
Интеграция	· Функциональная интеграция · Программное обеспечение промежуточного слоя (связующее ПО)
Доступ	· Доступ · Branding: например, рекомендации по внешнему виду web-сайта госорганизации · Доступность
Сеть	· Физическая сеть · Управление сетью
Платформа	· Платформа: аппаратное обеспечение (серверы, настольные системы, системы хранения) · Управление конфигурациями: стандарты на операционные системы, утилиты, конфигурации аппаратного обеспечения
Системное Управление	· Управление активами · Управление изменениями · Управление событиями · Управление инцидентами и проблемами · Непрерывность бизнеса (Business Continuity)
Частная информация	· Профилирование · Персонифицирование · Обеспечение защиты частной информации
Безопасность	· Корпоративная Безопасность · Безопасность · Безопасность серверов

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

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

· основные информационные сущности (information subject areas), такие как, например, Гражданин/Услуга/Платеж, которые специфичны для деятельности данной организации;

· процессы обработки информации, описывающие, в частности, каким образом, кем и в каком порядке используется, например, сущность " Гражданин";

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

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

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

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

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

· " обзор" (scope) – определяет область проекта, цели и подход;

· " требования" – содержит формализованные требования к решению, сгруппированные по типу, т.е. бизнес-требования, функциональные, по безопасности и т.п. В этой части организация шаблона схожа с разделом отечественного стандарта ГОСТ 34.698-90 " Техническое задание на АС";

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

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

· документирование;

· рецензирование;

· информирование;

· изменение;

· проверка соответствия;

· поддержка актуальности;

· организация и управление разработкой архитектуры, включая построение системы " IT Governance".

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

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

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

Рис. 9.1. Модель " 4+1"

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

· Логическое представление. Является объектной моделью проектирования (в том случае, если используется объектно-ориентированная модель проектирования).

· Процессное представление. Описывает вопросы параллельного исполнения и синхронизации процессов.

· Физическое представление. Описывает размещение программных компонент системы на аппаратных платформах и аспекты, связанные с физическим расположением системы.

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

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

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

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

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

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

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

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

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