Домены (предметные области) архитектуры

Элементы архитектуры предприятия

Почувствовавши себя на воле,...они (жители города Глупова) вздумали строить башню, с таким расчетом, чтоб верхний ее конец непременно упирался в небеса. Но так как архитекторов у них не было, а плотники были неученые и не всегда трезвые, то довели башню до половины и бросили.

М. Е. Салтыков-Щедрин. "История одного города"

Домены (предметные области) архитектуры

Обычно в составе архитектуры выделяют от четырех до семи основных представлений (предметных областей или доменов) [4.1],[4.2], [4.3], [4.4]. Эти области последовательно покрывают архитектурные аспекты, отталкиваясь от потребностей функционирования организации (бизнеса) и обеспечивая весь набор технологий для реализации конкретного решения бизнес-проблемы. Ниже перечислены представления (домены) архитектуры:

· Бизнес-архитектура. Описывает деятельность организации с точки зрения ее ключевых бизнес-процессов.

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

· Архитектура приложений. Определяет, какие приложения используются и должны использоваться для управления данными и поддержки бизнес-функций (например, модели приложений).

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

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

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

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

· Сетевая архитектура. Определяет описания, правила, стандарты, которые связаны с сетевыми и коммуникационными технологиями, используемыми в организации.

· Архитектура безопасности и т.д.

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

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

Рис. 5.1. Области, входящие в понятие Архитектуры предприятия

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

17. Роль стандартов в архитектуре информационных систем.

Применение стандартов играет важную роль в архитектуре информационных систем – прежде всего потому, что стандарты обеспечивают возможность взаимодействия различных компонент между собой. Чем более сложной, распределенной и тиражируемой является система, тем эта определяющая и консолидирующая роль стандартов становится все более актуальной. Стандарты есть общепринятые документы, формализующие лучшие практики. Строго говоря, принято различать стандарты де-юре, т.е. разработанные и поддерживаемые официальными органами по стандартизации, такими как Международная организация по стандартизации – ISO, и стандарты де-факто, основанные на существующем широком распространении технологии, методологии или продукта (например, использование MS Windows в качестве операционной системы для персональных компьютеров).

С другой стороны, можно выделять два класса – "технологические" и "рамочные" стандарты. Технологические стандарты определяют особенности реализации тех или иных протоколов, интерфейсов, языков программирования и т.п. Типичным примером являются спецификации WWW консорциума W3C. В составе описания ИТ-архитектуры предприятия обычно приводятся ссылки на используемые стандарты такого типа.

Для наших задач, связанных с разработкой архитектуры предприятия, наибольший интерес будут представлять такие "рамочные" стандарты, как уже упоминавшийся ISO 15704, а также ISO 15288 и, частично, ISO 12207. Помимо указанных, при разработке архитектуры предприятия достаточно широко используется порядка 30-ти дополнительных "поддерживающих" стандартов системной и программной инженерии. Например, стандарт ISO 14258 определяет концепции и правила для моделирования Предприятия и т.п. Эти стандарты являются рамочными (Framework) в том плане, что они задают общие требования к реализации процессов, связанных с разработкой и поддержкой жизненного цикла систем. Они обычно используются как методологическая основа для организации этих процессов с необходимой конкретизацией для каждого данного предприятия или области деятельности.

Если стандарт ISO 12207 был разработан для определения жизненного цикла только программного обеспечения, то ISO /IEC 15288 определяет жизненный цикл "более общей" системы. В применении к нашему контексту такой системой может являться совокупность информационных систем предприятия в целом.

В соответствии со стандартом ISO /IEC 15288 жизненный цикл систем охватывает " дерево " процессов, показанное на рис. 7.6.

Рис. 7.6. Структура активностей стандарта ISO 15288

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

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

Использование профилей направлено прежде всего на снижение трудоемкости и стоимости разработки проектов информационных систем и повышение качества их реализации за счет использования уже апробированных решений. При этом сами профили можно условно разделить на два класса – профили, описывающие собственно программные или архитектурные решения на основе ISO 15288, и профили, регламентирующие процессы жизненного цикла программных систем, такие как разработка, тестирование, сопровождение и т.п. Обычно для этого класса за основу берется стандарт ISO 12207.

Важным преимуществом использования архитектурных профилей является ориентация на использование модели открытых систем. Основные рекомендации по разработке таких профилей окружения открытых систем приведены в документе IEEE 1003.23, доступном по адресу http://www.enterprise-architecture.info. Создаваемые профили могут быть использованы как для детализации собственно ИТ-архитектуры, так и для формализации процесса ее разработки. Обычно в состав такого профиля включаются следующие разделы:

· требования со стороны бизнеса, функциональной архитектуры, конечных пользователей, управления информационной системой;

· применяемые формальные, перспективные и де-факто стандарты;

· стратегии и планы миграции.

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

В составе интерфейсов выделяются отдельные сервисы информационных систем (ИС-сервисы). ИС-сервисы представляют собой сервисы достаточно высокого уровня (например, управление информацией или статистический анализ данных), которые могут быть объединены в группы – системные, коммуникационные, информационные и взаимодействия с пользователями. ИС-сервисы формулируются в бизнес-терминах, например, "статистическая обработка данных". Реализация этих сервисов осуществляется на основе взаимодействия "более элементарных" ИТ-сервисов, описываемых в терминах протоколов, программных интерфейсов и компонент. Примерами таких сервисов могут являться печать или управление транзакциями.

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

Более подробная информация по стандартам для открытых систем приведена, например, в [4.31],[4.32]. Важно отметить, что такой подход может быть полезным даже в том случае, когда конкретная информационная система не полностью удовлетворяет принципу открытости.

Детальное обсуждение многих вопросов, связанных со стандартами, включая аспекты применения международных стандартов в России, их сравнение с существующими стандартами серий ГОСТ 34, ГОСТ Р и других, можно найти в материалах конференций по стандартам [4.33] и на сайте http://www.fostas.ru.

http://www.intuit.ru/studies/courses/995/152/lecture/4234?page=5