Методология Захмана описания архитектуры предприятия

• Используемые термины

архитектор — лицо, отвечающее за проектирование архитектуры и создание архитектурного описания

архитектурный артефакт — конкретный документ, отчет, аналитический отчет, модель или любой другой компонент архитектурного описания

архитектурное описание — набор объектов (артефактов), предназначенных для документирования архитектуры

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

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

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

Термин "модель" отражает, прежде всего, четкую формальную структуру предложенной Захманом конструкции.

Предложенная Захманом модель архитектуры предприятия направлена на достижение двух основных целей:

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

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

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

Модель Захмана представляется в виде таблицы, имеющей пять строк и шесть столбцов, и приведена на рисунке 2.1.

Строки в таблице соответствуют различному уровню управления предприятием и использования ИТ- системы.

Две верхние строки описывают бизнес-архитектуру предприятия, последующие - системную архитектуру (ИТ-архитектуру).

Верхняя строка соответствует общему описанию рассматриваемого вида бизнеса, определяет миссию и стратегию предприятия.

Модель архитектуры предприятия по Захману (схема Захмана)

Рисунок 2.1 - Модель архитектуры предприятия по Захману (схема Захмана)

Вторая строка выражает интересы и видение производства владельцем предприятия.

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

Четвертая и пятая строки раскрывают содержание архитектуры данных и технической архитектуры. На этих уровнях описываются детали, которые представляют интерес для ИТ-менеджеров, проектировщиков, разработчиков.

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

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

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

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

Первая строка соответствует уровню планирования бизнеса в целом. На этом уровне вводятся достаточно общие основные понятия, определяющие бизнес - например, продукты и услуги, клиенты, расположение объектов бизнеса, а также формулируется бизнес-стратегия (столбец 6 - мотивация). Данная строка определяет контекст всех последующих строк.

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

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

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

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

Далее поясняется последовательная детализация отдельных аспектов описания системы.

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

Колонка функций (ответ на вопрос "КАК?") предназначена для последовательной детализации описания того, как миссия предприятия реализуется на уровне отдельных операций. В частности, на первом уровне достаточным будет простое перечисление бизнес-процессов. Второй уровень будет содержать модель бизнес-процессов, которая впоследствии детализируется в операции над данными и архитектуру приложений (уровень 3), методы классов (уровень 4), программный код (уровень 5) и, наконец, исполняемые модули. При этом, начиная с 4-го уровня, рассмотрение ведется уже не в рамках Предприятия в целом, а по отдельным подсистемам или приложениям.

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

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

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

Последняя колонка "ЗАЧЕМ?" служит для определения мотивации и задает порядок перехода от задач бизнеса к требованиям и элементам информационных систем. Исходной точкой является бизнес-стратегия, которая затем последовательно транслируется в бизнес-план, затем в правила и ограничения для реализации бизнес-процессов, а на уровне 4 - в соответствующие приложения, необходимые для отображения бизнес-стратегии в составе информационных систем и, в дальнейшем, в их физической реализации.

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

Основными характеристиками модели Захмана являются следующие:

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

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

Другим ограничением модели является отсутствие рассмотрения системы в динамике.

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