| | Элементы архитектуры предприятия
Домены (предметные области) архитектуры
Обычно в составе архитектуры выделяют от четырех до семи основных представлений (предметных областей или доменов) [4.1], [4.2], [4.3], [4.4]. Эти области последовательно покрывают архитектурные аспекты, отталкиваясь от потребностей функционирования организации (бизнеса) и обеспечивая весь набор технологий для реализации конкретного решения бизнес-проблемы. Ниже перечислены представления (домены) архитектуры:
- Бизнес-архитектура. Описывает деятельность организации с точки зрения ее ключевых бизнес-процессов.
- Архитектура информации (данных). Определяет, какие данные необходимы для поддержания бизнес-процессов (например, модель данных), а также для обеспечения стабильности и возможности долговременного использования этих данных в прикладных системах.
- Архитектура приложений. Определяет, какие приложения используются и должны использоваться для управления данными и поддержки бизнес-функций (например, модели приложений).
- Технологическая архитектура (инфраструктура или системная архитектура). Определяет, какие обеспечивающие технологии (аппаратное и системное программное обеспечение, сети и коммуникации) необходимы для создания среды работы приложений, которые, в свою очередь, управляют данными и обеспечивают бизнес-функции. Эта среда должна обеспечивать работу прикладных систем на заданном уровне предоставления сервисов своим пользователям.
В зависимости от конкретных потребностей организации и актуальности решения тех или иных проблем можно выделить и другие представления архитектуры, например:
- Архитектура интеграции. Определяет инфраструктуру для интеграции различных приложений и данных. Например, в проектах в области "электронного правительства", когда имеется большое количество государственных информационных систем различных ведомств, возникает настоятельная потребность создания самостоятельной инфраструктуры интеграции (архитектура интеграции), с целью предоставления государством интегрированных услуг гражданам и бизнесу по принципу "одного окна".
- Архитектура общих сервисов. Примерами их являются такие сервисы, как электронная почта, каталоги, общие механизмы безопасности (идентификации, аутентификации, авторизации). То есть, это достаточно большое количество прикладных систем, которые носят "горизонтальный характер".
- Сетевая архитектура. Определяет описания, правила, стандарты, которые связаны с сетевыми и коммуникационными технологиями, используемыми в организации.
- Архитектура безопасности и т.д.
В частности, архитектуры интеграции и общих сервисов особенно актуальны для распределенной среды органов государственного управления, поэтому эти домены там, как правило, выделяются особо.
Сетевая архитектура сама по себе представляет достаточно обширную предметную область, в которой выделяется домен, связанный с сетевыми технологиями (доступ, пересылка данных, маршрутизация, коммутация и т.д.) и домен, связанный с коммуникациями (передача голоса и видео, удаленный доступ, мобильные вычисления и т.д.). Но большинство методик рассматривает эти предметные области как часть более обширных доменов, таких как архитектура приложений и технологическая архитектура, выделяя их в отдельные домены более низкого уровня на последующих этапах детального описания архитектуры предприятия.
Рис. 5.1. Области, входящие в понятие Архитектуры предприятия
Как отдельную область, очень часто выделяют архитектуру процессов управления информационными технологиями (архитектуру операций), т.е. архитектура предприятия является неполной без архитектуры управления и эксплуатации информационных технологий, т.е. структур управления и наборов процессов, которые поддерживают и обеспечивают как инфраструктуру и прикладные системы, так и непосредственно архитектурный процесс.
| |
В качестве примера возьмем он-лайновую систему выполнения заказов некоторого гипотетического магазина. Для описания требований к системе, ее проектирования и разработки можно рассматривать динамические и статические модели на различных уровнях абстракции: уровень контекста, концептуальный, логический, физический уровни.
Рассмотрим вначале концептуальный уровень абстракции. Динамическая модель для этого уровня должна отражать взаимодействия между клиентом и магазином. При этом сама проектируемая система выступает как один из акторов процесса в качестве "черного ящика". Клиент и сотрудник(и) магазина выступают как внешние по отношению к системе акторы. Весь процесс рассматривается с точки зрения клиента и сотрудника. Клиент осуществляет заказ через Интернет. Оплата выполняется с помощью кредитной карты. Заказ посылается по указанному адресу. Уведомление о выполнении заказа посылается по электронной почте. Модель на самом высоком уровне описывает бизнес-процессы продавца и содержит простой сценарий использования (use case), описывающий взаимодействия между системой и акторами. Рисунок 5.5 иллюстрирует такую концептуальную динамическую модель и содержит простую нотацию сценария использования для этого бизнес-взаимодействия.
Рис. 5.5. Динамическая концептуальная модель процесса закупки товара
Статическая модель на этом уровне абстракции отражает структуру классов и связи между объектами, необходимость в которых становится очевидной при анализе динамической модели. Другими словами, она отвечает на вопрос "Какие объекты должен понимать клиент для того, чтобы выполнить транзакцию, связанную с покупкой?" Рисунок 5.6 показывает диаграмму классов, которая является статической концептуальной моделью.
Рис. 5.6. Статическая модель процесса закупки товара в магазине
Клиент является конкретной реализацией класса Человек. Связи между клиентом и магазином обеспечены наличием Учетной записи клиента. Все Заказы ассоциированы с Учетной записью. Заказ ассоциирован со всеми приобретаемыми Элементами заказа. Каждый элемент заказа является специфическим Продуктом, где Продукт сам по себе является классом. Наконец, каждый Платеж ассоциирован с некоторым Заказом.
Вообще говоря, современное состояние индустрии информационных технологий в области моделирования можно охарактеризовать как "время больших перемен". С одной стороны, такая некоммерческая организация как Object Management Group (OMG) находится в процессе реализации ряда инициатив, которые имеют непосредственное влияние на развитие технологий моделирования предприятия и его информационных систем. Эта организация выдвинула концепцию архитектуры, основанной на моделях (MDA – Model-Driven Architecture, см. лекции 7), развивает язык моделирования систем Unified Modelling Language (UML). При этом основная идея состоит в автоматизированном (насколько это возможно) процессе создания кода прикладных систем на основе разработанных моделей.
Однако это не единственный подход к процессам моделирования. Его недостатком является то, что он, во-первых, пока не дает в руки разработчиков реального инструмента построения кода систем из моделей. Во-вторых, всегда существует разрыв между моделями и реально работающими системами: постоянные изменения в информационных системах в реальности не находят отражения в изменениях моделей, поскольку эти два процесса не так жестко связаны. В результате, многие разработчики систем смотрят на моделирование как на бесполезный процесс, поскольку все меняется, как только начинается практическая разработка информационных систем.
Решая более прагматичные задачи моделирования в интересах разработчиков систем, компания Microsoft, участвуя в работе OMG, в то же время выдвинула свою инициативу, связанную с моделированием информационных систем. Она основана на использовании языков DSL (Domain Specific Languages). Идея состоит в создании некоторого числа компактных, как правило, декларативных языков, предназначенных для описания различных предметных областей. Стратегия Microsoft состоит в использовании этих языков в рамках своих средств разработки (Visual Studio).
Примерами таких языков является язык описания бизнес-сущностей Business Entity DSL (например, "клиент", "заказ"), язык описания бизнес-процессов Business Process DSL (бизнес-активности, роли, зависимости), язык описания логической архитектуры систем Logical Systems Architecture DSL (описание конфигураций центров обработки данных), язык для описания web-сервисов Web Services DSL. При этом информация об одной модели может использоваться для создания другой модели. Примерами могут служить взаимодействие между моделями бизнес-сущностей и бизнес-процессов или между моделями web-сервисов и логическими серверами, на которых они будут размещены.
В результате у разработчика системы, который использует соответствующие средства, имеется возможность одновременно видеть модели системы и код, который их реализует. Между ними всегда обеспечивается соответствие. При этом то, что раньше было "необязательной" работой (создание моделей), становится просто неотъемлемой частью процесса разработки. Более подробно это изложено, в частности в [4.7].
Возможным ограничением этого подхода является то, что создание таких моделей есть достаточно "техническая" работа, и вряд ли можно ожидать непосредственного участия бизнес-руководителя в их разработке. Просто этот подход ориентирован, в основном, на создание моделей системной архитектуры, т.е. на несколько иную аудиторию и круг задач.
Подводя итог этому краткому обсуждению вопросов моделирования в рамках архитектуры предприятия, можно сказать следующее:
- Нет и не стоит в ближайшее время ожидать одной, универсальной технологии создания моделей.
- Имеется достаточно большое количество методик и средств моделирования, которые могут успешно применяться для разработки моделей различных доменов Архитектуры предприятия.
|
