Уровни абстракции (перспективы) в описании архитектуры предприятия

 

Понятие перспективы используется в искусстве для определения направления на изображаемый объект – например, вид здания с площади или из окна соседнего небоскреба. Помимо чисто "геометрического" направления, понятие перспективы может быть обобщено для отображения различного уровня восприятия объекта – например, описание и восприятие одного и того же здания с точки зрения туриста, осматривающего окрестности, постоянного жильца или пожарного может быть существенно различным, в соответствии с их опытом и отношением к предмету. Этот же термин достаточно широко применяется и при разработке программных систем.

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

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

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

Ниже приведены примеры вопросов, на которые должен давать ответ уровень контекста:

· Каких целей хочет добиться организация?

· Почему организация занимается таким бизнесом: видение, миссия и цели?

· Каковы тенденции в индустрии, в которой работает организация?

· Как организация расположена и где она работает географически?

· Каковы факторы, определяющие достижение высоких результатов в бизнесе (value drivers)?

· Каковы на самом высоком уровне классы информации, которыми оперирует организация?

· Каковы функции этого бизнеса?

· В каких областях сосредоточена ключевая компетенция организации?

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

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

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

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

· Какие области бизнеса должны быть поддержаны информационными технологиями?

· Какая общая бизнес-архитектура (например, "фронт-офис", "мид-офис", "бэк-офис") будет использоваться?

· Как системы будут соотноситься с организационными структурами и бизнес-архитектурой, насколько информационные системы отдельных департаментов будут консолидированы в единый набор ключевых прикладных систем?

· Как выглядят бизнес-процессы, которые обеспечивают создание продуктов и оказание услуг?

· Какая информация требуется для каждого бизнес-процесса и как эта информация может повторно использоваться?

· Организован ли бизнес организации в централизованном или децентрализованном виде?

· Какой уровень делегирования полномочий должны обеспечивать системы?

· Какие существуют общие принципы по использованию технологий, характерные для индустрии, в которой работает организация, и типы оказываемых услуг?

· Какие вопросы по надзору и руководству использованием технологий должны быть рассмотрены на данном этапе?

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

В качестве методов, которые используются для построения бизнес-моделей на этапе концептуального проектирования, могут быть, например, такие инструменты языка UML как Варианты Использования (Use Cases), диаграммы деятельности и другие методы проектирования процессов.

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

На этом уровне даются ответы на следующие вопросы:

· Какие приложения необходимы для поддержки бизнес-процессов?

· Кто является основными пользователями и заинтересованными сторонами в реализации данных прикладных систем?

· Как выглядят нормализованные модели данных для этих приложений?

· Какие прикладные системы нужны для управления данными: создания, чтения, внесения изменений и удаления данных?

· Какие нужны технологии для реализации этих прикладных систем?

· Как будет выглядеть распределенная архитектура прикладных систем?

· Какие стандарты должны быть приняты организацией?

Логический уровень описывает решение в виде набора сервисов или компонент в независимой от технологической реализации форме. Это включает четкое определение интерфейсов (или так называемых контрактов), связанных с интеграцией и совместной работой этих сервисов и компонент. Поскольку этот уровень описания архитектуры не зависит от конкретных продуктов реализации, он остается относительно стабильным. Он может меняться, чтобы отражать инициированные "сверху-вниз" изменения, включая новые фундаментальные бизнес-модели (например, переориентация на модель обслуживания, основанную на потребностях клиента), а также отражать изменения, инициированные в направлении "снизу-вверх", такие как возможности, открывающиеся в связи с использованием новых технологий (например, применение CRM-системы для управления отношениями с клиентами). Изменения могут быть связаны с новыми технологическими парадигмами и концепциями, такими, например, как сервис-ориентированная архитектура или Grid-вычисления. При подобном подходе влияние изменений на уровне бизнеса или технологий могут быть оценены в явной и последовательной манере.

Ключевыми вопросами, которые должны быть решены на данном уровне абстракции, являются следующие:

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

· Как логические компоненты будут распределены между различными системами (будут ли эти компоненты реализованы в виде web-сервисов)?

· Как единый брокер или шина интеграции будет обеспечивать различные бизнес-системы, или как средства обеспечения совместной работы будут использоваться помимо баз данных и средств интеграции для того, чтобы обеспечить работу виртуальных групп сотрудников?

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

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

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

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

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

Примеры вопросов, на которые отвечают на данном уровне абстракции, следующие:

· Каковы функциональные спецификации каждой прикладной системы?

· Будет ли организация разрабатывать специализированные приложения или покупать стандартные?

· Каковы критерии выбора и как будут оцениваться различные инициативы по реализации систем?

· Как данные будут представлены на физическом уровне?

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

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

Уровень реализации, самый нижний уровень или перспектива в описании архитектуры системы формулируется уже разработчиками системы в терминах использования тех или иных продуктов конкретных поставщиков.

На уровнях физической архитектуры и уровне реализации для ускорения цикла разработки, повышения качества разрабатываемых систем (за счет использования проверенных решений) и уменьшения рисков проекта могут использоваться такие концепции и архитектурные модели, как, например, Microsoft Systems Architecture (MSA).

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

Таблица 4.1. Пример рассмотрения системы на различных уровнях абстракции

Перспектива (уровень абстракции)	Уровень детализации
Контекст	· Компания представляется в виде "черного ящика" и является центральным "действующим лицом" (фактором). · Бизнес моделируется с точки зрения внешних для бизнеса факторов. · Моделируются только бизнес-взаимодействия, средства игнорируются.
Концептуальный	· Моделируются потоки работ бизнес-процессов, идентифицированных на концептуальном уровне. · Система, реализующая процессы, является центральным актором в форме "черного ящика". · Бизнес-процессы моделируются с точки зрения внешних для системы факторов. Рассматриваются средства коммуникаций, используемые для выполнения транзакций.
Логический	· Моделируется внутренняя архитектура системы. · Основные компоненты системы являются основными факторами. · Поведение системы моделируется с точки зрения внутренних для системы "черных ящиков".
Физический	· Моделируется физическая структура реализации системы.