Модель Захмана: основные элементы, характеристика компонентов.
Модель Захмана основана на дисциплине классической архитектуры и обеспечивает общий словарь и набор перспектив, или структур (framework), для описания современных сложных корпоративных систем. В своей работе Дж. Захман определил Архитектуру предприятия как "набор описательных представлений (моделей), которые применимы для описания Предприятия в соответствии с требованиями управленческого персонала (качество) и которые могут развиваться в течение определенного периода (динамичность)".
Основная идея заключается в том, чтобы обеспечить возможность последовательного описания каждого отдельного аспекта системы в координации со всеми остальными. Для любой достаточно сложной системы общее число связей, условий и правил обычно превосходит возможности для одновременного рассмотрения. В то же время отдельное, в отрыве от других, рассмотрение каждого аспекта системы чаще всего приводит к неоптимальным решениям, как в плане производительности, так и стоимости реализации.
Рис. 8.2. Модель Захмана
На каждом из этих уровней участники, вообще говоря, рассматривают одни и те же категории вопросов, соответствующих столбцам в таблице, – только с различным уровнем абстракции и детализации. В содержание этих колонок входят:
используемые данные (что?)
процессы и функции (как?)
места выполнения этих процессов (где?)
организации и персоналии–участники (кто?)
управляющие события (когда?)
цели и ограничения, определяющие работу системы (зачем?)
Основные правила заполнения таблицы следующие:
каждая клетка таблицы независима от других, вместе они образуют функционально полное пространство для описания системы ("базис");
порядок следования колонок несущественен;
каждая клетка содержит соответствующее описание аспекта реализации системы в виде определенной модели или, возможно, простого описания (текстового документа);
базовые модели для каждой из колонок являются уникальными;
соответствующие модели в клетках каждого ряда в совокупности образуют полное описание системы с выбранной перспективы;
заполнение клеток должно проводиться последовательно "сверху вниз", попытка пропуска одного из рядов является, скорее, "шаманством" (в том плане, что нельзя создать хорошо работающую систему, "перепрыгнув" определенные уровни ее описания на этапе проектирования).
Первая строка соответствует уровню планирования бизнеса в целом ( бизнес-модель ). На этом уровне вводятся достаточно общие основные понятия, определяющие бизнес – например, продукты и услуги, клиенты, расположение объектов бизнеса, а также формулируется бизнес-стратегия (колонка 6 – мотивация). Фактически, данная строка определяет контекст всех последующих строк.
Вторая строка ( концептуальная модель ) предназначена для определения в терминах бизнеса структуры организации, ключевых и вспомогательных бизнес-процессов.
Третий уровень ( логическая модель ) соответствует рассмотрению с точки зрения Системного Архитектора. Здесь бизнес-процессы описываются уже в терминах информационных систем, включая различные типы данных, правила их преобразования и обработки для выполнения определенных на уровне 2 бизнес-функций.
На четвертом уровне – технологической или физической модели – осуществляется привязка данных и операций над ними к выбранным технологиям реализации. Например, здесь может быть определен выбор реляционной СУБД, или средств работы с неструктурированными данными, или объектно-ориентированной среды.
Пятый уровень соответствует детальной реализации системы, включая конкретные модели оборудования, топологию сети, производителя и версию СУБД, средства разработки и собственно готовый программный код. Многие из работ на данном уровне часто выполняются субподрядчиками.
Последний, шестой уровень описывает работающую систему. На этом уровне могут быть введены, в том числе, такие объекты, как инструкции для работы c системой, фактические базы данных, работа службы HelpDesk. Надо заметить, что в исходной работе Захмана содержание этого уровня не детализируется. При развитии модели, как будет показано ниже, отмечены возможности рассмотрения аспектов функционирования работающей системы с точки зрения, например, конечного пользователя или эксплуатирующих служб.
Рассмотрим теперь, как осуществляется последовательная детализация отдельных аспектов описания системы, для чего обратим внимание на различные колонки таблицы. Напомним, что порядок расположения колонок в таблице, вообще говоря, произволен.
Так, первая колонка отвечает на вопрос "ЧТО?" и определяет используемые в системе данные. На верхнем уровне достаточным будет простое перечисление основных объектов, используемых в бизнесе. На втором уровне данные объекты объединяются в семантическую модель высокого уровня и обычно описываются в виде диаграммы "сущности-связи" (E-R диаграммы) с отражением основных связей и наиболее существенных бизнес-ограничений. На третьем уровне эта модель приводится к нормализованной форме, определяются все атрибуты и ключи. Четвертый уровень представляет собой физическую модель данных в системе (в объектно-ориентированном подходе – иерархию классов). Следующий уровень содержит описание модели на языке управления данными для формирования таблиц, готовые библиотеки классов, табличные пространства СУБД. Наконец, последний уровень может описывать фактические наборы данных, в том числе такие характеристики, как журналы доступа, размеры реально занимаемого дискового пространства, статистику обращений и т.п. Конечно, можно отметить определенное несовершенство данной модели при использовании объектно-ориентированного подхода – фактически модель предписывает раздельное рассмотрение данных (свойств) и функций (методов) классов.
Колонка функций (ответ на вопрос "КАК?") предназначена для последовательной детализации описания того, как миссия предприятия реализуется на уровне отдельных операций. В частности, на первом уровне достаточным будет простое перечисление бизнес-процессов. Второй уровень будет содержать модель бизнес-процессов, которая впоследствии детализируется в операции над данными и архитектуру приложений (уровень 3), методы классов (уровень 4), программный код (уровень 5) и, наконец, исполняемые модули. При этом, начиная с 4-го уровня, рассмотрение ведется уже не в рамках Предприятия в целом, а по отдельным подсистемам или приложениям.
Следующая колонка (вопрос "ГДЕ?") определяет пространственное распределение компонент системы и сетевую организацию. На уровне планирования бизнеса здесь достаточно определить расположение всех производственных объектов. На следующем уровне эти объекты объединяются в модель со связями, характеризующими взаимодействие между собой, – будь то обмен информацией или поставки товаров. На третьем уровне системной архитектуры осуществляется привязка компонент информационной системы к узлам сети. Четвертый уровень служит для определения физической реализации в терминах аппаратных платформ, системного программного обеспечения, а также средств промежуточного уровня (так называемое "middleware"), используемых для интеграции различных компонент информационной системы между собой. Типичным примером могут являться брокеры запросов или средства обмена сообщениями. На пятом уровне определяются используемые протоколы и спецификации каналов связи. Последний уровень описывает функционирование реализованной сети.
Колонка таблицы, отвечающая на вопрос "КТО?", определяет участников процесса. На уровне планирования бизнеса здесь представлен список подразделений предприятия и выполняемые ими функции. На следующем уровне приводится полная организационная диаграмма, а также могут быть определены общие требования к информационной безопасности. Далее последовательно определяются участники бизнес-процессов и их роли (в RUP используются диаграммы событий и описание вариантов использования), требования к интерфейсам пользователя и правила доступа к отдельным объектам, физическая их реализация на уровне кода или операторов определения доступа к таблицам в СУБД. Последний уровень описывает обученных пользователей системы.
Пятая колонка отвечает на вопрос "КОГДА?" и определяет временные характеристики бизнес-процессов и работы системы. Опять-таки детализация осуществляется сверху вниз, начиная от календарного плана (уровень 1) и основных параметров, характеризующих выполнение бизнес-процессов, – например, требование ко времени оформления сделки (уровень 2). На третьем уровне определяются события, вызывающие изменение состояния информационных объектов и инициацию операций над ними. На следующем уровне эти события транслируются в программные вызовы (триггеры) или передаваемые сообщения. Пятый уровень определяет физическую реализацию обработки таких событий. Наконец, на 6-м уровне – фактическая история функционирования системы.
Последняя колонка ("ПОЧЕМУ?" или "ЗАЧЕМ?") служит для определения мотивации и задает порядок перехода от задач бизнеса к требованиям и элементам информационных систем. Исходной точкой является бизнес-стратегия, которая затем последовательно транслируется в бизнес-план, затем в правила и ограничения для реализации бизнес-процессов, а на уровне 4 – в соответствующие приложения, необходимые для включения в состав информационных систем и, в дальнейшем, в их физическую реализацию.
Такая модель описания в целом полезна для идентификации возможных ограничений. Эти ограничения могут "распространяться" как от верхних уровней к нижним (например, указание руководства компании о выборе тех или иных средств, продуктов или принципов работы), так и в обратном направлении – например, возможности существующих технологий беспроводной связи в значительной степени определяют спектр предлагаемых услуг и организацию бизнес-процессов у провайдеров этих услуг.
Важным принципом предложенной модели является необходимость последовательного перехода при углублении детализации рассмотрения. Пропуск отдельных элементов, например, прямой переход от описания модели бизнес-процесса к физической реализации системы требует "привлечения магии" и почти всегда приводит к неудаче. На практике это часто случается при попытке разработки программы на основании только устного описания требований пользователя.
Основными характеристиками данной модели Захмана являются следующие:
простота для понимания как техническими, так и нетехническими специалистами;
целостность в отношении предприятия, то есть каждая проблема может быть соотнесена с предприятием в целом;
поддержка обсуждений сложных вопросов с использованием относительно небольшого количества нетехнических понятий;
возможность применения для планирования, позволяющего лучше принимать решения за счет того, что решение никогда не будет выноситься "в пустоте" (в отрыве от остальных аспектов деятельности предприятия);
применимость для решения задач, то есть возможность работать с абстракциями и сущностями, выделяя и изолируя отдельные параметры системы без потери восприятия Предприятия как целого;
нейтральность, то есть независимость от каких-либо инструментов; благодаря этому каждый инструмент и методология могут быть отображены на данную модель и могут явно показать, что они делают и чего они не делают.
Созданная модель архитектуры служила простым, но мощным инструментом по применению системного подхода для планирования работ по созданию и использованию информационных систем и их стыковки. Захман писал, что схема архитектуры позволяет концентрироваться на отдельных аспектах системы и в то же время не терять ощущения общего контекста или "холистической" перспективы (то есть, взгляда на предприятие в целом). Он подчеркивал, что именно потеря такой перспективы, в частности, разработка систем субподрядчиками, находящимися "вне контекста", уже около пятидесяти лет составляет причину появления неинтегрируемых и не поддерживающих предприятие должным образом систем, которые к тому же весьма дорого заменять.
Баланс между сущностью реализации отдельных ячеек и интегрированным взглядом на систему поддерживается моделью Захмана за счет того, что она:
облегчает понимание и общение людей, имеющих разные роли в процессах создания, развития и использования системы;
ясно определяет фокус внимания на (относительно) независимых параметрах для целей анализа;
но в то же время обеспечивает поддержку контекстных взаимосвязей, важных для сохранения целостности системы.
Методология разработки модели Захмана
См. вопрос 9
- Вопросы к экзамену по дисциплине корпоративные ис (для гр. А -16-07) весна 2012
- Хозяйственная деятельность предприятий
- Задачи управления предприятием.
- Информационные ресурсы предприятия.
- Автоматизация управления бизнес-процессами.
- Назначение и свойства корпоративных ис.
- Системный подход к информатизации процессов управления.
- Структура кис, характеристика его компонентов.
- Обязательные требования к информационным системам
- Корпоративная информационная система как комплекс ис
- Методологии анализа бизнес – процессов в кис.
- Модель Захмана: основные элементы, характеристика компонентов.
- Классификация ис.
- Этапы проектирования кис.
- Особенности типового проектирования кис.
- Назначение и функции кис erp-систем.
- Функциональность и назначение crm-систем.
- Функциональность mrp-систем
- Назначение и функциональность mrpii – систем.
- Специфика формирования требований к кис.
- Архитектура кис и её виды.
- Многозвенная архитектура кис.
- Методы построения распределенных ис в архитектуре клиент-сервер.
- Стандарты открытых информационных систем
- Сетевые протоколы взаимодействия открытых систем osi.
- Удаленный вызов процедур и объектов.
- Основные компоненты технологии corba
- Обзор архитектуры
- Сравнительный анализ технологий dcom, corba.
- Особенности Интранет/Интранет-технологии построения кис.
- Основные свойства распределенных бд (по Дейту).
- Тиражирование (репликация) в распределенных ис.
- Методы управление распределенными транзакциями.
- Обеспечение отказоустойчивости
- Способы управления транзакциями в распределенных ис. Механизм двухфазной фиксации транзакций.
- Internet-технология как клиент – серверная технология. Понятие Web-сервиса, Web-приложения и Web-сайта.
- Компоненты и протоколы Web-сервиса.
- Olap-технологии в кис: назначение. Классификация задач olap в кис.
- Свойства olap-систем.
- Основные элементы многомерной модели данных. Пример.
- Основные операции над многомерной моделью данных. Примеры.
- Способы реализации olap-систем Реализации olap
- Эволюция доступа к источникам данных: ado. Net, Entity Framework
- Назначение и общая характеристика .Net-технологии.
- Архитектура Web-приложения в asp.Net
- Технология ado.Net, специфика доступа к удаленным данным.
- Объектная модель ado.Net. Характеристика и назначение основных объектов. Примеры
- Технология asp.Net. Методы доступа к удаленным данным.
- Подключение к источнику данных
- Объектная модель asp.Net. Характеристика и назначение основных объектов. Примеры.
- Компоненты asp. Примеры использования для доступа к различным источникам данных.
- Общая характеристика рынка программных продуктов кис.
- Анализ рынка программных продуктов кис
- Общая характеристика программных продуктов для кис компании Oracle
- Что такое лицензия Oracle.
- Лицензия на обновление программного обеспечения Oracle и поддержку (Software Update License & Support)
- Продление поддержки (Support Renewals)
- Лицензионные метрики (License Metrics)
- Многоядерные процессоры (Multi-core Processors)
- Общая характеристика программных продуктов для кис компании sap
- .Общая характеристика программных продуктов для кис компании baan
- Общая характеристика программных продуктов для кис компании Парус
- Общая характеристика программных продуктов для кис компании 1с: предприятие