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

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

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

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

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

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

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

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

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

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

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

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

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

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