Опубликован: 07.05.2007 | Доступ: свободный | Студентов: 10942 / 2843 | Оценка: 4.16 / 3.71 | Длительность: 23:54:00
ISBN: 978-5-9556-0045-1
Специальности: Руководитель
Лекция 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".

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

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

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