ОБЗОР МОДЕЛЕЙ И МЕТОДИК ПОСТРОЕНИЯ АРХИТЕКТУРЫ ПРЕДПРИЯТИЙ

ОБЗОР МОДЕЛЕЙ И МЕТОДИК ПОСТРОЕНИЯ АРХИТЕКТУРЫ ПРЕДПРИЯТИЯ

Модель Захмана

Дж. Захман (John A. Zachman) сделал наиболее значимый вклад в развитие концепции архитектуры предприятия. Модель Захмана (Zachman Framework for Enterprise Architecture) постоянно эволюционирует и является основой, на базе которой многие организации создают свои собственные методики описания информационной инфраструктуры предприятия. Модель Захмана послужила основой для создания целого ряда методик и моделей описания архитектуры предприятия:

  • • Федеральной архитектуры США (FEAF, Federal Enterprise Architecture Framework);
  • • методики описания архитектуры Open Group (TOGAF, The Open Group Architecture Framework);
  • • методики описания архитектуры Министерства обороны США (DoDAF, Department of Defence Architecture Framework) и др.

Первая версия модели Захмана была опубликована 1987 г. и предназначалась большей частью для ИТ-систем. Эта версия модели в течение 1992-1996 гг. была расширена и обобщена в разрезе описания архитектур сложных производственных систем любого типа, найдя применение во многих компаниях, входящих в список 2000 крупнейших корпораций мира (General Motors, Bank of America и др.) [1].

Модель Захмана3 основана на классических методологиях построения архитектуры предприятия. Модель обеспечивает общий словарь и набор перспектив, или структур, для описания современных сложных корпоративных систем. Дж. Захман определяет архитектуру предприятия как набор описательных представлений (моделей), применимых для описания предприятия в соответствии с требованиями управленческого персонала и способных развиваться в течение определенного периода. Термин «архитектура» здесь не случаен, он подчеркивает существующую аналогию между внутренней структурой абстрактного объекта — предприятия — и сложным искусственным объектом, таким как здание или орбитальная международная космическая станция (МКС) [1].

Модель Захмана преследует две основные цели:

  • 1) логически разбить все описание архитектуры на отдельные разделы для упрощения их формирования и восприятия;
  • 2) обеспечить возможность рассмотрения целостной архитектуры с выделенных точек зрения или соответствующих уровней абстракции.

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

Основная идея заключается в том, чтобы обеспечить возможность последовательного описания каждого отдельного аспекта системы в координации со всеми остальными. Собственно модель представляется в виде таблицы (табл. 4.1).

5 По глубине подхода и значимости модели, скорее, должен был быть применен перевод оригинала «framework» как «методики» [1].

Таблица 4.1

Данные ЧТО?

Функции КАК?

Сеть ГДЕ?

Организации КТО?

Расписание КОГДА?

Стратегии ПОЧЕМУ?

Планировщик (1-й уровень)

Список важных понятий и объектов

Список основных бизнес-процессов

Список мест нахождения

Список организаций, важных для бизнеса

Список важных событий

Список бизнес-целей и стратегий

Сфера действия (контекст)

Владелец, менеджер (2-й уровень)

Концептуальная модель данных

Модель бизнес-процессов

Схема логистики

Модель потока работ (workflow)

Календарный план реализации

Бизнес-план

Концептуальная модель предприятия

Конструктор, архитектор (3-й уровень)

Логические модели данных

Архитектура приложений

Модель распределенной архитектуры

Архитектура интерфейса пользователя

Структура процессов

Конкретизация ролей и бизнес-правил

Системная (логическая) модель

Проектировщик

(4-й уровень)

Физическая модель данных

Системный проект

Технологическая архитектура

Архитектура презентации

Структуры управления

Реализация ролей и бизиес-правил

Т ехнологическая (физическая) модель

Разработчик (5-й уровень)

Описание структуры данных

Программный код

Сетевая архитектура

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

Определение временных привязок

Реализация бизнес-логистики

Детали реализации

Пользователь

(6-й уровень)

Фактические базы данных

Исполняемый код и инструкции к функциям

Описание взаимодействия в сети

Обученный персонал

Список фактических бизнес-событий

Работающие правила

Оценка функционирования

Модель Захмана

Перспективы (строки в таблице) соответствуют различным уровням управления предприятием, если речь идет об архитектуре предприятия или использовании ИС:

  • первый уровень соответствует уровню интересов высшего руководства и собрания акционеров. В применении к деятельности предприятия — это верхняя строка таблицы, представляющая, по сути, контекст модели. В данной строке демонстрируется планирование бизнеса в целом (бизнес-модель). На этом уровне вводятся достаточно общие основные понятия, определяющие бизнес (например, продукты и услуги, клиенты, расположение объектов бизнеса), а также формулируется бизнес-стратегия (колонка «Стратегия»). Данная строка определяет контекст всех последующих строк;
  • второй уровень соответствует интересам бизнес-менед-жеров и владельцев процессов, на нем определяется концептуальная модель, которая предназначена для описания в терминах бизнеса структуры организации, ключевых и вспомогательных бизнес-процессов. Две верхние строки соответствуют наиболее общим представлениям и достаточно широко описывают существующее окружение, планы и цели;
  • третий уровень — уровень, на котором происходит организация «командной» работы бизнес-менеджеров, бизнес-ана-литиков и менеджеров, отвечающих за разработку ИТ. Это уровень логической модели, здесь бизнес-процессы описываются уже в терминах информационных систем, включая различные типы данных, правила их преобразования и обработки для выполнения определенных на втором уровне бизнес-функций;
  • четвертый уровень и последующие описывают детали, представляющие интерес для ИТ-менеджеров, проектировщиков, разработчиков. На нем определяется технологическая модель, включающая физическую модель и детали реализации, т. е. осуществляется привязка данных и операций над ними к выбранным технологиям реализации. Например, здесь может быть определен выбор реляционной СУБД, средств работы с неструктурированными данными и/или объектно-ориентированной среды;
  • пятый уровень соответствует детальной реализации системы, включая конкретные модели оборудования, топологию сети, производителя и версию СУБД, средства разработки и собственно готовый программный код. Многие из работ на данном уровне часто выполняются субподрядчиками;
  • шестой уровень описывает работающую систему. На этом уровне могут быть введены такие объекты, как инструкции для работы с системой, фактические базы данных.

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

Колонка «Данные» (ответ на вопрос «ЧТО?») определяет используемые в системе данные. На верхнем уровне достаточным будет простое перечисление основных объектов, используемых в бизнесе. На втором уровне данные (объекты) объединяются в семантическую модель высокого уровня и обычно описываются в виде диаграммы «сущности-связи» с отражением основных связей и наиболее существенных бизнес-ограничений. На третьем уровне эта модель приводится к нормализованной форме, определяются все атрибуты и ключи. Четвертый уровень представляет собой физическую модель данных в системе (в объектно-ориентированном подходе — иерархию классов). Пятый уровень содержит описание модели на языке управления данными для формирования таблиц, готовые библиотеки классов, табличные пространства СУБД. Шестой уровень может описывать фактические наборы данных, в том числе такие характеристики, как журналы доступа, размеры реально занимаемого дискового пространства, статистика обращений и т. п. Можно отметить определенное несовершенство данной модели при использовании объектно-ориентированного подхода — фактически модель предписывает раздельное рассмотрение данных (свойств) и функций (методов) классов.

Колонка «Функции» (ответ на вопрос «КАК?») предназначена для описания последовательной детализации способов реализации миссии предприятия на уровне отдельных операций. На первом уровне достаточным будет простое перечисление бизнес-процессов. Второй уровень будет содержать модель биз-нес-процессов, которая впоследствии детализируется на третьем уровне в операции над данными и архитектуру приложений; на четвертом уровне — в методы классов; на пятом уровне содержится программный код и, наконец, исполняемые модули — на шестом уровне. При этом, начиная с четвертого уровня, рассмотрение ведется уже не в рамках предприятия в целом, а по отдельным подсистемам или приложениям.

Колонка «Сеть» (ответ на вопрос «ГДЕ?») определяет пространственное распределение компонентов системы и сетевую организацию. На уровне планирования бизнеса достаточно определить расположение всех производственных объектов. На втором уровне эти объекты объединяются в модель со связями, характеризующими взаимодействие между собой, — будь то обмен информацией или поставки товаров. На третьем уровне системной архитектуры осуществляется привязка компонентов информационной системы к узлам сети. Четвертый уровень служит для определения физической реализации в терминах аппаратных платформ и системного программного обеспечения, используемых для интеграции различных компонентов ИС между собой. Типичным примером могут являться брокеры запросов или средства обмена сообщениями. На пятом уровне определяются используемые протоколы и спецификации каналов связи. На шестом уровне описывается функционирование реализованной сети.

Колонка «Организации» (ответ на вопрос «КТО?») определяет участников процесса. На уровне планирования бизнеса здесь представлен список подразделений предприятия и выполняемые ими функции. На втором уровне приводится полная организационная диаграмма, а также могут быть определены общие требования к информационной безопасности. Далее последовательно определяются участники бизнес-процессов и их роли (уровень 3), требования к интерфейсам пользователя и правила доступа к отдельным объектам (уровень 4), их физическая реализация на уровне кода или операторов определения доступа к таблицам в СУБД (уровень 5). Шестой уровень описывает обученных пользователей системы.

Колонка «Расписание» (ответ на вопрос «КОГДА?») определяет временные характеристики бизнес-процессов и работы системы. Детализация осуществляется сверху вниз, начиная от списка важных событий (уровень 7) и календарного плана (уровень 2), характеризующих выполнение процессов (например, требование ко времени оформления сделки). На третьем уровне определяются события, вызывающие изменение состояния информационных объектов и инициацию операций над ними (диаграммы зависимостей, последовательностей). На четвертом уровне эти события транслируются в программные вызовы (триггеры) или передаваемые сообщения (диаграмма потоков управления). Пятый уровень определяет физическую реализацию обработки таких событий (определения интервалов, временные диаграммы), шестой уровень представляет историю функционирования системы.

Колонка «Стратегии» (ответ на вопрос «ПОЧЕМУ?») служит для определения мотивации и задает порядок перехода от задач бизнеса к требованиям и элементам ИС. Исходной точкой является бизнес-стратегия (уровень 7), транслируемая последовательно в бизнес-план (уровень 2), правила и ограничения для реализации бизнес-процессов (уровень 3), соответствующие приложения, необходимые для включения в состав ИС и в дальнейшем в их физическую реализацию (четвертый уровень).

Таблица заполняется по следующим правилам:

  • • каждая клетка таблицы независима от других, вместе они образуют функционально полное пространство для описания системы («базис»);
  • • каждая клетка содержит соответствующее описание аспекта реализации системы в виде определенной модели или, возможно, простого описания (текстового документа);
  • • порядок следования колонок несущественен;
  • • базовые модели для каждой колонки уникальны;
  • • модели в клетках каждого ряда в совокупности образуют полное описание системы с выбранной перспективы;
  • • заполнение клеток должно проводиться последовательно «сверху вниз».

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

Существуют специализированные продукты, например Popkin Software Architect, которые фактически основаны на модели Захмана и позволяют достаточно эффективно управлять созданием моделей и артефактов описания архитектуры предприятия.

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

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

Следует отметить, что предложенный вариант развития исходного подхода Захмана не является единственно возможным.

Существует большое количество модельных схем, которые в той или иной мере используют данный подход, хотя визуальное представление модели в целом может достаточно сильно отличаться. Примерами таких схем являются модели Extended Enterprise Architecture Framework (E2AF) [28] и 4-доменной архитектуры (Four Domains architecture, FDA) [29].

 
Посмотреть оригинал
< Пред   СОДЕРЖАНИЕ ОРИГИНАЛ   След >