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

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

Аннотация: Рассмотрены модели описания NASCIO, "4+1", SAM, Microsoft и др
Ключевые слова: architecture, toolkit, CIO, цикла, ПО, структурная схема, архитектура, деление, разделы, предметной области, домен, управление активами, change management, business continuity, управление данными, data management, информация, компонент, designer, RFC, ЭЦП, базы данных, права доступа, средства защиты информации, очередь, процесс управления, governance, аналогия, GIS, программное обеспечение промежуточного слоя, целый, права, model, модель проектирования, представление, диаграммы классов, UML, сущность-связь, производительность, интеграция, устойчивость, надежность, масштабируемость, сеть, SAM, architectural model, microsoft, e-advising, операции, механизмы, отношение, опыт, бизнес-процессы, инфраструктура, member, офис, кластеризация, SOA, MDA, объединение, инкапсуляция, IBM, SAP, microsoft solutions framework, MSF, system architecture, management, шаблон проектирования, технологическая модель, знание, journal, COM, корпорация, деятельность, risk management, разработка информационных систем, software project, unified, Интернет, Data, DDC, data center, EDC, enterprise data, IDC, программное обеспечение, Command, control, communications, computational intelligence, surveillance, AND, department, анализ, gig, global, information, Grid, целостность, тип данных, представление архитектуры, контекст, reference model, OPEN, distributed processing, ISO, парадигма, электронное правительство, distribution, физический ресурс, координация, репозиторий, безопасность, функция, embedded, customer, application, functional, conceptualization, интерфейс, СУБД, исполнитель, open group, доминирующее положение, отслеживание связей, IEEE 1471, метамодель

NASCIO Architecture Toolkit

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

Для наших целей сравнительного анализа интересно проследить эволюцию данного подхода, поэтому вначале мы рассмотрим основные идеи, заложенные в версию 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
  • нормализация данных
  • стандарты предприятия на именования таблиц и атрибутов
Грета Березовская
Грета Березовская
Александр Медов
Александр Медов

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

Денис Бочаров
Денис Бочаров
Россия
Анна Небеснюк
Анна Небеснюк
Россия, Софрино-1, Майская средняя, 2012