1.2Сущность модели Дж. А. Захмана
Модель (методика) Захмана является одной из ранних попыток связать характеристики информационной системы с бизнес-задачами предприятия. Джон А. Захман (John A. Zachman) предложил простую, но концептуально мощную схему, показывающую различные уровни представления архитектуры ИС, различные виды ее обеспечения, а также их основные взаимосвязи.
Этот метод хорошо известен в мировой практике. Суть его сводится к формализованному представлению модели предприятия в виде матрицы. Модель Захмана основана на дисциплине классической архитектуры и обеспечивает общий словарь и набор перспектив, или структур (framework), для описания современных сложных корпоративных систем.
Само понятие «архитектура предприятия» впервые появилось в 1987 г. в статье Дж.А. Захмана «Структура архитектуры информационных систем», опубликованной в журнале IBM Systems Journal [5]. В этой статье автор изложил свое видение архитектур предприятий и связанных с ними проблем, которое задало направление развития на последующие десятилетия.
Видение Захмана заключалось в том, что для обеспечения высокой ценности и гибкости бизнеса необходим целостный подход к архитектуре систем, в рамках которого каждая существенная проблема рассматривается с разных точек зрения. Такой подход к созданию архитектуры систем представляет собой то, что Захман изначально называл «архитектурной структурой ИС», а впоследствии – «структурой архитектуры предприятия».
«Структура» Захмана, скорее, представляет собой классификацию для упорядочения элементов архитектуры (проектной документации, спецификации и моделей). Причем классификация ведется в двух направлениях: с одной стороны, учитываются заинтересованные лица (например, владелец бизнеса и строитель), с другой – конкретная проблема, которую необходимо устранить (например, проблема с данными и функциональностью).
Захман изначально проводил аналогию между построением ИС и строительной отраслью. В строительстве элементы архитектуры (архитектурные артефакты) неявным образом организованы в двумерную структуру.
Первым измерением являются различные «игроки». В случае строительства здания такими игроками являются владелец (оплачивает проект), строитель (координирует процесс постройки) и архитектор-планировщик (обеспечивает соблюдение строительных норм и правил).
Каждому игроку необходима полная информация о будущем здании и процессе его постройки, однако понятие полноты для каждого игрока свое. Владелец заинтересован в полном описании функциональности и эстетики здания. Строитель заинтересован в полном описании строительных материалов и этапов строительства. При этом владельца не интересуют гвозди в стенах, а строителя не интересует, виден ли из окон спальни восход солнца.
Вторым измерением классификации являются описательные аспекты: кто, что, где, когда, как и почему. Второе измерение не зависит от первого. И строитель, и владелец должны знать «что», но это «что» для владельца отличается от «что» для строителя.
В первой статье и последующей работе в 1992 г. [11] Захман предложил шесть описательных аспектов (данные, функция, сеть, люди, время и мотивация) и шесть игроков (планировщик, владелец, проектировщик, строитель, субподрядчик и предприятие). Эти два измерения можно представить в виде таблицы или матрицы, как показано на рис. .
|
ЧТО
|
КАК
|
ГДЕ
|
КТО
|
КОГДА
|
ЗАЧЕМ
|
|
Планировщик
|
Перечень важных понятий и объектов
|
Перечень основных бизнес-процессов
|
Территориальное расположение
|
Ключевые организации
|
Важнейшие события
|
Бизнес-цели и стратегии
|
Сфера действия (контекст)
|
Владелец, менеджер
|
Концептуальная модель данных
|
Модель бизнес-процессов
|
Схема логистики
|
Модель потока работ (workflow)
|
Мастер-план реализации
|
Бизнес-план
|
Модель предприятия
|
Конструктор, архитектор
|
Логическая модель данных
|
Архитектура приложения
|
Модель распределенной архитектуры
|
Архитектура интерфейса пользователя
|
Структура процессов
|
Роли и модели бищнес-правил
|
Модель ИС
|
Проектировщик
|
Физическая модель данных
|
Системный проект
|
Технологическая архитектура
|
Архитектура презентации
|
Структуры управления
|
Описание бизнес-правил
|
Физическая модель ИС
|
Разработчик
|
Описание структуры данных
|
Программный код
|
Сетевая архитектура
|
Архитектура безопасности
|
Определение временны́х привязок
|
Реализация бизнес-логики
|
Детали реализации
|
|
Данные
|
Работающие программы
|
Сеть
|
Реальные люди, организации
|
Бизнес-события
|
Работающие бизнес-стратегии
|
Работающее предприятие
|
|
Данные
|
Функции
|
Дислокация, сеть
|
Люди
|
Время
|
Мотивация
|
|
Рис. . Модель Захмана в виде матрицы
Например, с точки зрения владельца бизнеса, «данные» – это объекты, важные для бизнеса. Они могут включать сведения как о самих объектах, например, о клиентах и продукции, так и об отношениях между ними, например, о демографических группах и складских запасах. В разговоре о данных с владельцем бизнеса следует использовать именно этот язык.
С точки зрения разработчика БД, «данные» – это связанные друг с другом таблицы, их строки и столбцы. В разговоре о данных с разработчиком БД следует говорить не о демографических группах клиентов, а о реляционных таблицах, запросах и связях «один-ко-многим».
Ни одна из этих точек зрения не является более важной или детализированной, чем другая. Они обе важны для целостного понимания архитектуры системы.
Основные правила заполнения таблицы следующие:
каждая клетка таблицы независима от других, вместе они образуют функционально полное пространство для описания системы ("базис");
порядок следования колонок несущественен;
каждая клетка содержит соответствующее описание аспекта реализации системы в виде определенной модели (диаграммы) или простого текста;
базовые модели для каждой из колонок являются уникальными;
все модели в каждой строке в совокупности образуют полное описание системы с выбранной перспективы;
заполнение клеток должно проводиться последовательно сверху вниз, пропускать строки нельзя.
Первая строка соответствует уровню планирования бизнеса в целом (бизнес-модель). На этом уровне вводятся достаточно общие основные понятия, определяющие бизнес – например, продукты и услуги, клиенты, расположение объектов бизнеса, а также формулируется бизнес-стратегия (колонка 6 – мотивация). Фактически, данная строка определяет контекст всех последующих строк.
Вторая строка (концептуальная модель) предназначена для определения в терминах бизнеса структуры организации, ключевых и вспомогательных бизнес-процессов.
Третий уровень (логическая модель) соответствует рассмотрению с точки зрения Системного Архитектора. Здесь бизнес-процессы описываются уже в терминах информационных систем, включая различные типы данных, правила их преобразования и обработки для выполнения определенных на уровне 2 бизнес-функций.
На четвертом уровне – технологической или физической модели – осуществляется привязка данных и операций над ними к выбранным технологиям реализации. Например, здесь может быть определен выбор реляционной СУБД, или средств работы с неструктурированными данными, или объектно-ориентированной среды.
Пятый уровень соответствует детальной реализации системы, включая конкретные модели оборудования, топологию сети, производителя и версию СУБД, средства разработки и собственно готовый программный код. Многие из работ на данном уровне часто выполняются субподрядчиками.
Последний, шестой уровень описывает работающую систему. На этом уровне могут быть введены, в том числе, такие объекты, как инструкции для работы с системой, фактические базы данных, работа службы HelpDesk. Необхиодимо заметить, что в исходной работе Захмана содержание этого уровня не детализируется.
Каждый из столбцов матрицы отвечает на один из поставленных выше вопросов.
ЧТО? – данные (data), любые формы представления информации, критически важной для бизнеса, в данном случае это основной субъект таблицы. Важно, что данные описываются во взаимосвязи между собой.
КАК? – функции (function), операции, выполняемые над субъектом, выделение и передача знаний. Это функциональное описание системы, здесь представлено то, как организация работает, как устроен поток работ, как используются данные.
ГДЕ? – сеть (network), расположение субъекта. Это, в конечном итоге, описание информационных потоков предприятия.
КТО? – люди (people), распределение ответственности и функции работников. Человек рассматривается в роли носителя и распорядителя знаний.
КОГДА? – время (time), может быть абсолютным или относительным, отражающим взаимосвязанность процессов.
ЗАЧЕМ – мотивация (motivation), ключевой вопрос бизнес цели и стратегия.
Первая колонка отвечает на вопрос "ЧТО?" и определяет используемые в системе данные. На верхнем уровне достаточным будет простое перечисление основных объектов, используемых в бизнесе. На втором уровне данные объекты объединяются в семантическую модель высокого уровня и обычно описываются в виде диаграммы «сущность-связь» (ER-модель) с отражением основных связей и наиболее существенных бизнес-ограничений. На третьем уровне эта модель приводится к нормализованной форме, определяются все атрибуты и ключи. Четвертый уровень представляет собой физическую модель данных в системе (в объектно-ориентированном подходе – иерархию классов). Следующий уровень содержит описание модели на языке управления данными для формирования таблиц, готовые библиотеки классов, табличные пространства СУБД. Наконец, последний уровень может описывать фактические наборы данных, в том числе такие характеристики, как журналы доступа, размеры реально занимаемого дискового пространства, статистику обращений и т.п.
Колонка функций (ответ на вопрос "КАК?") предназначена для последовательной детализации описания того, как миссия предприятия реализуется на уровне отдельных операций. В частности, на первом уровне достаточным будет простое перечисление бизнес-процессов. Второй уровень будет содержать модель бизнес-процессов, которая впоследствии детализируется в операции над данными и архитектуру приложений (уровень 3), методы классов (уровень 4), программный код (уровень 5) и, наконец, исполняемые модули. При этом, начиная с 4-го уровня, рассмотрение ведется уже не в рамках предприятия в целом, а по отдельным подсистемам или приложениям.
Следующая колонка (вопрос "ГДЕ?") определяет пространственное распределение компонентов системы и сетевую организацию. На уровне планирования бизнеса здесь достаточно определить расположение всех производственных объектов. На следующем уровне эти объекты объединяются в модель со связями, характеризующими взаимодействие между собой, – будь то обмен информацией или поставки товаров. На третьем уровне системной архитектуры осуществляется привязка компонент информационной системы к узлам сети. Четвертый уровень служит для определения физической реализации в терминах аппаратных платформ, системного программного обеспечения, а также средств промежуточного уровня (так называемое "middleware"), используемых для интеграции различных компонент информационной системы между собой. Типичным примером могут являться брокеры запросов или средства обмена сообщениями. На пятом уровне определяются используемые протоколы и спецификации каналов связи. Последний уровень описывает функционирование реализованной сети.
Колонка таблицы, отвечающая на вопрос "КТО?", определяет участников процесса. На уровне планирования бизнеса здесь представлен список подразделений предприятия и выполняемые ими функции. На следующем уровне приводится полная организационная диаграмма, а также могут быть определены общие требования к информационной безопасности. Далее последовательно определяются участники бизнес-процессов и их роли (описание вариантов использования), требования к интерфейсам пользователя и правила доступа к отдельным объектам, физическая их реализация на уровне кода или операторов определения доступа к таблицам в СУБД. Последний уровень описывает обученных пользователей системы.
Пятая колонка отвечает на вопрос "КОГДА?" и определяет временные характеристики бизнес-процессов и работы системы. Опять-таки детализация осуществляется сверху вниз, начиная от календарного плана (уровень 1) и основных параметров, характеризующих выполнение бизнес-процессов, – например, требование ко времени оформления сделки (уровень 2). На третьем уровне определяются события, вызывающие изменение состояния информационных объектов и инициацию операций над ними. На следующем уровне эти события транслируются в программные вызовы (триггеры) или передаваемые сообщения. Пятый уровень определяет физическую реализацию обработки таких событий. Наконец, на 6-м уровне – фактическая история функционирования системы.
Последняя колонка ("ПОЧЕМУ?" или "ЗАЧЕМ?") служит для определения мотивации и задает порядок перехода от задач бизнеса к требованиям и элементам информационных систем. Исходной точкой является бизнес-стратегия, которая затем последовательно транслируется в бизнес-план, затем в правила и ограничения для реализации бизнес-процессов, а на уровне 4 – в соответствующие приложения, необходимые для включения в состав информационных систем и, в дальнейшем, в их физическую реализацию.
Такая модель описания в целом полезна для идентификации возможных ограничений. Эти ограничения могут распространяться как от верхних уровней к нижним (например, указание руководства компании о выборе тех или иных средств, продуктов или принципов работы), так и в обратном направлении – например, возможности существующих технологий беспроводной связи в значительной степени определяют спектр предлагаемых услуг и организацию бизнес-процессов у провайдеров этих услуг.
Важным принципом предложенной модели является необходимость последовательного перехода при углублении детализации рассмотрения. Пропуск отдельных элементов, например, прямой переход от описания модели бизнес-процесса к физической реализации системы требует «телепатии» и почти всегда приводит к неудаче. На практике это часто случается при попытке разработки программы на основании только устного описания требований пользователя.
|
