Опубликован: 07.05.2007 | Уровень: специалист | Доступ: платный
Лекция 9:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Грета Березовская
Грета Березовская
Александр Медов
Александр Медов

Здравствуйте,при покупке печатной формы сертификата,будут ли выданы обе печатные сторны?

Константин Андреев
Константин Андреев
Россия, Петрозаводск, Петрозаводский государственный университет, 2001
Станислав Кравченко
Станислав Кравченко
Россия, Москва, МЭГУ, 2006