Полная версия

Главная arrow Информатика arrow Архитектура предприятия (продвинутый уровень).

  • Увеличить шрифт
  • Уменьшить шрифт


<<   СОДЕРЖАНИЕ ПОСМОТРЕТЬ ОРИГИНАЛ   >>

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

ВВЕДЕНИЕ

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

  • - модель Захмана;
  • - методология TOGAF;
  • - методология FEAF;
  • - методология COBIT;
  • - методики крупных аналитических фирм Garther, MetaGroup и т.д.

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

МОДЕЛЬ ЗАХМАНА

Модель Захмана основана на структурированном описании классической архитектуры и обеспечивает общий словарь и набор перспектив, или структур, для описания современных сложных корпоративных систем [12.8, 12.9, 12.10, 12.13]. В своих работах Дж. Захман определил архитектуру предприятия как «набор описательных представлений (моделей), которые применимы для описания предприятия в соответствии с требованиями управленческого персонала (качество) и которые могут развиваться в течение определенного периода (динамичность)».

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

Основная идея заключается в том, чтобы обеспечить возможность последовательного описания каждого отдельного аспекта системы в координации со всеми остальными. Таблица, составленная по данной методике, имеет пять строк и шесть столбцов. В результате специалист имеет модель: простую для понимания специалистами любых направлений; целостную по отношению ко всему предприятию; независимую от каких-либо инструментов (рис. 5.1).

Модель Захмана для архитектуры предприятия [12.8]

Рис. 5.1. Модель Захмана для архитектуры предприятия [12.8]

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

Аналогично, в применении к деятельности предприятия верхняя строка «Контекст» соответствует уровню интересов высшего руководетва и собрания акционеров. Второй уровень соответствует интересам бизнес-менеджеров и владельцев процессов. Третий уровень - тот, на котором бизнес-менеджеры, бизнес-аналитики и менеджеры, отвечающие за ИТ, должны работать вместе. Уровни с четвертого и далее описывают детали, которые представляют интерес для ИТ- менеджеров, проектировщиков, разработчиков.

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

  • • используемые данные (ЧТО?);
  • • процессы и функции (КАК?);
  • • места выполнения этих процессов (ГДЕ?);
  • • организации и персоналии-участники (КТО?);
  • • управляющие события (КОГДА?);
  • • цели и ограничения, определяющие работу системы (ЗАЧЕМ?).

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

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

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

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

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

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

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

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

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

К достоинствам модели Захмана можно отнести следующее:

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

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

 
<<   СОДЕРЖАНИЕ ПОСМОТРЕТЬ ОРИГИНАЛ   >>