Как составить модель захмана

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

В модели Захмана архитектура предприятия
рассматривается, как «набор описательных
представлений (моделей), которые применимы
для описания Предприятия в соответствии
с требованиями управленческого персонала
(качество) и которые могут развиваться
в течение определенного периода
(динамичность)».

Архитектура в модели Захмана рассматривается
с точки зрения различных заинтересованных
лиц, где «архитектурное представление»
— это ячейка таблицы, соответствующие
пересечению определенного столбца и
строки. Таким образом, мы можем говорить
не об одной определенной архитектуре
предприятия, а о нескольких различных
представлениях архитектуры, зависящих
от предъявляемых требований.

Методика впервые была опубликована в
1987 году Джоном Захманам как схема
развития информационных технологий на
предприятии для обеспечения взаимосвязи
между информационными системами и
требованиями бизнеса. Методика создает
контекст описания различных архитектурных
представлений в соответствии с
требованиями заказчика в виде нескольких
различных аспектов (Рисунок 2.6.).

В современном виде модель Захмана была
представлена в 1992 году и впоследствии
послужила основой для создания множества
других моделей и методик, ориентированных
на разработку архитектуры, как предприятий,
так и информационных систем (Рисунок
2.7.).

Рисунок
2.6. Zachman Framework (1987)

Рисунок
2.7. Zachman Framework (1992)

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

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

Данные (DATA) — что?Уровень описывает любые формы
предоставления информации необходимой
для эффективного функционирования
предприятия.

Функции (FUNCTION)
– как?Описывает набор бизнес-процессов,
обеспечивающих функционирование
предприятия.

Место (NETWORK) –
где?Определяет географическое
расположение объектов и сетевую
организацию предприятия.

Люди (PEOPLE) — кто?Определяет участников процесса, описывает
распределение ответственности и функции
работников.

Время (TIME) — когда?Описывает временные характеристики.
Время может быть абсолютным или
относительным, отражать взаимосвязь
процессов.

Мотивация (MOTIVATION)
— почему? Определяет направление
развития бизнес-цели и стратегии.

Строки в таблице соответствуют уровню
абстракции, в соответствии с которым
описывается предприятие.

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

• Данные: определяется список важных
  понятий и объектов.

• Функции: список основных бизнес-процессов.

• Место: территориальное расположение
  производственных подразделений.

• Люди: список ключевых бизнес подразделений
  организации.

• Время: важнейшие события, календарный
  план.

• Мотивация: бизнес-цели и стратегии
  предприятия.

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

• Данные: концептуальная модель данных.

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

• Место: логистика процессов.

• Люди: модель потока работ (workflow).

• Время: мастер – план реализации.

• Мотивация: бизнес-план.

Системная модель (SYSTEM
MODEL)– описывает
логическую модель построения предприятия
и соответствует точке зрения системного
архитектора, проецирует взгляд бизнеса
(заказчика) на информационные системы.
На этом уровне бизнес-процессы
рассматриваются с точки зрения
информационных систем, дается
детализированное описание данных и
правила их преобразования.

• Данные: логические модели данных.

• Функции: архитектура приложений.

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

• Люди: архитектура интерфейса пользователя.

• Время: структура процессов.

• Мотивация: роли и модели бизнес-правил.

Технологическая модель (TECHNOLOGY
MODEL)– обеспечивает
привязку архитектуры к программно
аппаратным средствам с точки зрения
проектировщика. На этом уровне
рассматривается физическая модель и
описывается взгляд проектировщика на
выбор технологий реализации.

• Данные: физическая модель данных.

• Функции: архитектура информационных
  систем.

• Место: технологическая архитектура.

• Люди: архитектура представления.

• Время: структура управления.

• Мотивация: описание правил бизнес —
  логики.

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

• Данные: спецификации форматов данных.

• Функции: код программных компонентов.

• Место: спецификации архитектуры сети.

• Люди: определение ролей и прав доступа.

• Время: определение сроков.

• Мотивация: реализация бизнес — логики.

Работающая организация (FUNCTIONING
ENTERPRISE)— описывает
реальную структуру предприятия и
позволяет соотнести с желаемое состояние
с вынесенными изменениями. Этот уровень
текущей архитектуры предприятия, то
есть набор документов, описывающих их
текущее состояние.

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

Основными достоинствами модели Захмана
является:

• Простота понимания.

• Целостность в отношении предприятия.

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

• Использование нетехнических понятий.

• Независимость от различных инструментов.

Методика Захмана, является одной из
первых появившихся методик. Она не
потеряла свою актуальность в настоящее
время и постоянно используется, как
основа для методологий различных
аналитических и коммерческих компаний.

3.2. META
Group

Одна из наиболее интересных методик
описания архитектуры предприятия была
представлена компанией METAGroupв документеEnterpriseArchitectureDeskReferenceв 2002 году. В силу
своей простоты данная методика послужила
основой различным аналитическим
компаниям для разработки собственных
уникальных архитектурных концепций.

В настоящий момент компания METAGroupкуплена компаниейGartner, а названная методика
описания архитектуры предприятия, в
свою очередь, была заложена в основуGartnerEnterpriseArchitectureFramework.

Под архитектурой предприятия в методике
METAGroupпонимается структурированное описание
информационных технологий предприятия
и поддерживаемые ими бизнес-процессы.

Аналитики METAGroupтрадиционно рассматривают архитектуру
информационных технологий, как элемент
ключевых процессов управления всего
предприятия (Рисунок 2.8).

Рисунок 2.8.
Ключевые процессы управления

Первый уровень в иерархии ключевых
процессов управления занимает процесс
выработки стратегии и планирования
(StrategyandPlanning), обеспечивающий
выработку стратегических целей и задач
в рамках всего предприятия. Разработка
ИТ стратегии является частным случаем
данного процесса.

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

Третий уровень является детализацией
непосредственно архитектуры предприятия,
в которой выделяются следующие четыре
основных слоя (Рисунок 2.9):

• EnterpriseBusinessArchitecture(EBA)
  – бизнес-архитектура, описывающая
  бизнес — цели и бизнес — драйверы
  предприятия, бизнес-процессы и
  организационную структуру, каналы
  взаимодействия и продаж.

• EnterpriseInformationArchitecture(EIA)
  – информационная архитектура, описывает
  информационные потоки данных и сервисы.

• EnterpriseSolutionArchitecture(ESA)
  – архитектура приложений, описывает
  приложения, имеющиеся в компании, их
  компоненты и интерфейсы.

• EnterpriseTechnicalArchitecture(ETA)
  – техническая архитектура, описывает
  компоненты инфраструктуры, технологические
  системы. Данный слой также включает в
  себя ИТ стандарты.

Рисунок
3.9.
META Group Framework

Видение общих
требований (CRV — Common
requirements Vision) и принципы
концептуальной архитектуры
(CA – Conceptual Architecture) являются
объединяющим элементом
для всех
четырех слоев
архитектуры предприятия.

Разработка общих требований (CRV)
и концептуальной архитектуры (CA)
является первым шагом в процессе
построения архитектуры предприятия.
Жизненный цикл архитектурного процесса
развивается по спирали, а эти два
документа являются стержнем, вокруг
которого строится архитектура предприятия
(Рисунок 2.10).

Рисунок 2.10.
Жизненный цикл архитектуры предприятия

Аналитики METAGroupиспользуя классический подход к
жизненному циклу, выделяют текущее
состояние архитектуры (as-is)
и будущее состояние архитектуры (futurestate). Переход из текущего
состояния в будущее осуществляется за
счет реализации проектов (Рисунок).
Каждый новый проект вносит изменения
в один или несколько слоев архитектуры
(EBA,EIA,ESA,ETA), и, таким образом,
жизненный цикл архитектуры предприятия
переходит на свой очередной, новый,
виток развития.

Особое внимание в методике MetaGroupуделяется процессу
разработки архитектуры предприятия и
его интеграции с другими ключевыми
процессами управления предприятием
(Рисунок 2.11).

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

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

Рисунок 2.11.
Архитектурный процесс META Group

Другими словами, целевая архитектура
является будущей моделью предприятия
и включает в себя следующие процессы:

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

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

• Разработка общих требований (Common
  requirements Vision) включает в себя анализ
  тенденций развития внешней для
  предприятия среды, включая технологические
  тенденции, бизнес — стратегии, требования
  бизнеса к информационным системам и
  технологической архитектуре.

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

• Архитектурное моделирование (ArchitectureModeling) – обеспечивает
  построение моделей, описывающих
  функционирование предприятия в
  соответствии с требованиями,
  сформированными в других процессах.

Фаза 3.Управление портфелем (PortfolioManagement) обеспечивает
реализацию проектов, переводящих
предприятие из текущего состояния в
будущее.

• Документирование текущего состояния
  (Document Current Assent) или, другими словами,
  разработка текущей архитектуры
  обеспечивает документирование любых
  изменений происходящих с архитектурой
  предприятия, вне зависимости от их
  уровня.

• Проведение GAP анализа (GAP Analysis). GAPанализ обеспечивает сравнение между
  текущей архитектурой и целевой
  архитектурой. В ходе анализа выявляется
  несоответствия и вырабатывается список
  изменений, которые необходимо провести
  для их устранения.

• План миграции (Migration Planning) – состоит в
  разработке плана реализации,
  обеспечивающего миграцию в сторону
  желаемого состояния архитектуры. Список
  изменений, необходимых для реализации
  появляется при GAPанализе.

• Планирование реализации (Implementation
  Planning) обеспечивает внесение в архитектуру
  предприятия необходимых изменений в
  соответствии с планом миграции. После
  внесения изменений в архитектуру
  предприятия информация документируется
  и отображается в текущей архитектуре.

3.3. Gartner

Современная методика аналитической
компании GartnerGroupпоявилась на свет после объединения с
компаниейMETAGroupи является результатом многолетних
работ в области архитектуры предприятия
(EnterpriseArchitecture).
Основу методики
составляет работа
«Enterprise Architecture Desk Reference» компании
META Group.

С точки зрения аналитиков Gartnerархитектура предприятия является
«структурированным описанием
информационных технологий предприятия
и его бизнес-процессов».

Методология Gartnerбыла
выбрана в качестве основы для построения
архитектуры предприятия в ОАО Вымпелком.
В связи с этим, ниже мы рассмотрим
элементы этой методологии более подробно.
Выбор данной методологии обусловлен
простотой ее внедрения на предприятии
и возможностью использования отдельных
архитектурных элементов для оптимизации
функционировании компании.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #

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

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

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

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

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

Правила построения модели следующие:

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

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

«Построение архитектурной модели Захмана» 👇

Построение архитектурной модели Захмана

Рассмотрим алгоритм построения модели:

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

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

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

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

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

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

Значительный вклад в развитие концепции архитектуры предприятия был сделан Дж. Захманом (John A. Zachman). С момента публикации «модель Захмана для описания архитектуры предприятия» прошла определенную эволюцию в своем развитии и стала основой, на базе которой многие организации создавали свои собственные методики описания информационной инфраструктуры предприятия. С 1987 года, когда была предложена первая версия этой модели, расширенная впоследствии в работах 1992-96 гг., она была использована достаточно большим количеством крупных компаний, входящих в список 2000 крупнейших корпораций мира, такими, например, как General Motors, Bank of America и др. Модель Захмана также послужила основой для создания целого ряда других методик и моделей описания архитектуры предприятия, таких как Федеральная Архитектура США (FEAF – Federal Enterprise Architecture Framework), Методика описания архитектуры Open Group (TOGAF – The Open Group Architecture Framework), Методика описания
архитектуры министерства обороны США (DoDAF – Department of Defence Architecture Framework). Отметим, что в данном случае в исторически сложившемся переводе названия на русский язык используется именно термин «модель», отражающий прежде всего четкую формальную структуру предложенной Захманом конструкции, хотя по глубине подхода и значимости, скорее, должен был быть применен перевод оригинала «framework» как «методики».

Модель Захмана основана на дисциплине классической архитектуры и обеспечивает общий словарь и набор перспектив, или структур (framework), для описания современных сложных корпоративных систем. По большому счету, наше приведенное выше в
«Архитектура предприятия: основные определения»
,
«Интегрированная концепция и уровни абстракции»
описание Архитектуры предприятия следовало, как будет видно далее, принципам, заложенным в модели Захмана. Мы построили некоторую «матрицу» со строками в виде различных уровней абстракции (перспективами) и набором столбцов в виде представлений (областей) архитектуры (см. рис. 4.4), которая в какой-то степени является частью более сложной матрицы, используемой для описания архитектуры в Модели Захмана.

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

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

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

Исторически модель Захмана впервые была создана именно для ИТ-систем [5.4]. Этот подход в последующей работе [5.3] был обобщен для рассмотрения не только ИТ-систем, но и для описания предприятия в целом, так что предложенная модель, вообще говоря, может использоваться как средство для описания архитектур сложных производственных систем любого типа.

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

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

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

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

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

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

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

Сам Захман в своем интервью он-лайновому журналу «Enterprise Architect Online» без ложной скромности сравнил свою модель с периодической таблицей элементов Менделеева и назвал ее «периодической таблицей описательных представлений предприятия или двумерной системой, схемой классификации» [5.5]. Это действительно ко многому обязывающее сравнение, но Захман привел следующие аргументы в его пользу: «Вопросы что, как, где, кто, когда и зачем существуют тысячи лет. И они будут существовать еще тысячи лет. Требования к системам, процесс проектирования, производства или концептуальный, логический и физический уровень описания также существуют в течение тысяч лет и будут существовать еще тысячи лет. Логическая структура классификации, схема – неизменны».

В конце концов, как отмечает Захман, коммерческие предприятия и государственные организации должны понимать, что путь к эффективным информационным системам требует систематических подходов в проектировании (engineering). Если вы, например, занимаетесь большими проектами, связанными с интеграцией государственных информационных систем, то «…назначить одного ответственного человека – это еще не решение проблемы. Никакого чуда просто так не произойдет. В какой-то момент вы поймете, что настоящий процесс проектирования должен быть реализован для того, чтобы интегрировать эти объекты».

Мадорская Ю.М.

Схема Захмана  [2] – одна из первых работ в области разработки архитектурных каркасов информационных систем.

Схема Захмана является наиболее полным архитектурным каркасом и определяет общие свойства информационных систем на том уровне, когда они еще не зависят от парадигмы проектирования, технологии и средств разработки. Она систематизирует знания об архитектуре информационной системы, охватывая все аспекты проектирования за счет использования системы шести универсальных вопросов «Что? Кто? Где? Когда? Как? Почему?».

Захман адаптировал эти вопросы к проектированию информационных систем и уточнил срезы проектирования.

Срезы Что и Как отдаются для описания Данных и Функций информационной системы — объективному ядру систем этого класса.

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

Следующие срезы — это Место и Время, соответствующие вопросам Где и Когда. Анализ информационной системы по этим срезам позволяет сформулировать нефункциональные требования, без учета которых можно попасть в просак и не достигнуть поставленных целей.

Интересно, что Захман не включил в исходную версию схемы три среза: «люди», «время», «мотивация» — они появились только во втором, расширенном варианте [5]. Захман был обеспокоен тем, что люди не захотят принять то, что это такие же опорные срезы проектирования, как и остальные. Сравните это с современной ситуацией — большинство методологий управления проектами фокусируются именно на Людях и Мотивации.

После того как основные ракурсы проектирования установлены, схема Захмана раскладывает знания об информационной системе по шести слоям, которые ведут нас от целей бизнеса, ради которой затевается разработка ИС, к конкретной технологии их достижения. Чем ниже уровень — тем сильнее зависимость от решений, принятых ранее.

Итак, уровни:

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

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

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

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

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

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

Движение в сторону проработки связей между ячейками исходной схемы имеет важное значение. Хотя все ячейки имеют самостоятельную ценность — они не могут существовать обособленно. Для каждого требования к ИС, соответствующего какой-либо ячейке, должны быть определены связи с требованиями из других ячеек. Например, бизнес-процесс (КАК) всегда работает с данными (ЧТО), и мы не сможем спроектировать систему, описав структуру бизнес-процессов отдельно от данных, которые они используют. И, конечно, эти связи хотелось бы понимать уже на уровне архитектурного каркаса.

В своей статье о расширенной  схеме [3] Захман подчеркивает важность описания связей между моделями различных слоев. Это необходимо, чтобы сохранить представление  о системе в целом и о контексте ее использования в ходе всех циклов проектирования. Фактически, он говорит о необходимости обеспечения сквозной трассировки требований и расширенная схема — это и есть попытка разработать модель такой трассировки.

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

Интересно отметить, что в 2008 году Захман в своей публикации «Точное определение схемы Захмана» определяет свою схему как онтологию [4]. Возможно это дань моде, а возможно необходимо, чтобы точнее классифицировать работу и выделить ее из серии  новых архитектурных каркасов, которые стали включать не таксономию архитектуры, а процесс по ее разработке. Сам автор мотивирует это тем, что процессы, основанные на онтологической структуре, будут более предсказуемы и будут выдавать повторяемые результаты. Заметим, что сама схема при этом не изменена.

Хотите сослаться на эту статью? Используйте правильную ссылку:

Литература

[11] Данилин А. Архитектура и стратегия  / А. Данилин,  А. Слюсаренко. –  М. Интернет-Ун-т Информ. Технологий,  2005. – 504 с.

[2] Zachman J. A. A framework for information systems architecture. // IBM Syst. J. 26, 3, 1987. – P.  276-292.

[3] Zachman J. A., Sowa J. F. Extending and formalizing the framework for information systems architecture // IBM Systems Journal, 1992, 31, №3. – P.  590-561.

[4] Zachman J. A. John Zachman’s Concise Definition of the The Zachman Framework. Zachman International. 2008. URL: http://www.zachmaninternational.com/concise%20definition.pdf

[5] Zachman P. The Zachman Framework Evolution. 2009 URL:  https://www.cob.unt.edu/itds/faculty/becker/BCIS5520/Readings/The%20Zachman%20Framework%E2%84%A2%20Evolution.pdf

Что такое архитектура предприятия, и почему Захман ошибся?

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

Известная модель Захмана пытается ответить на вопрос, что такое архитектура предприятия, и рассказывает о том, как она должна моделироваться. Основой этой модели являются вопросы, на которые предлагается ответить: кто, когда, где, почему и как совершает что-то над чем-то. Кажется, что это логичный фреймворк для описания архитектуры предприятия, и многие думают, что так оно и есть.

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

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

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

Получается, что, задавая вроде бы логичные вопросы, я в лучшем случае получаю несколько ответов, а в худшем, не получаю их вообще. Если взять предельный случай, когда у нас есть полностью роботизированное предприятие, на котором вообще нет людей, то ответом на вопрос «кто?» будет — «никто». В результате мы вообще ничего не можем сказать об этом предприятии! Правда, есть один выход из этой ситуации, немного лукавый, – надо лишь воспользоваться мифическим сознанием и одушевить роботов. Тогда, одушевив неодушевленное, мы сможем ответить на вопрос: кто? Робот. Почему? Потому что так устроен этот робот, или потому что программист его так запрограммировал. На второй вопрос мы снова получаем странные ответы. Почему же так получилось, и какие вопросы на самом деле стоит задавать? Я попытаюсь кратко изложить свое мнение на этот счет, рассказав о тех логических ошибках, которые я нашел в модели Захмана.

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

Как же на самом деле происходит проектирование предприятия и какие артефакты при этом возникают? Прежде чем проектировать предприятие, строится модель требований к нему. Модель требований формируется на основе требований, которые предъявлены к этому предприятию со стороны всех его участников, контрагентов и стейкхолдеров. Аналог в ИТ — требования к программному продукту. Далее на основе этих требований строится модель процессов предприятия с необходимой степенью детализации. Аналогом в ИТ будет перечень функций программного продукта. Далее строится модель функциональных объектов, или, говоря специализированным языком, технических мест, которые должны участвовать в перечисленных ранее процессах. Аналогом в ИТ будет описание процедур, и объяснение какие процедуры в каких функциях участвуют. Далее подбираются те единицы оборудования, которые могут выполнять роли перечисленных технических мест. Аналог в ИТ — это программный код.

Предприятие – это функциональный объект, который создан удовлетворяющим определенным требованиям. В этом смысле предприятие ничем не отличается от такого объекта, как часы, или производственная линия. Часто вместо термина функциональный объект можно услышать термин техническое место. Техническое место отличается от единицы оборудования тем, что единица оборудования выполняет роль технического места. Например, трансформатор выполняет роль преобразователя напряжения, при этом в разное время разные трансформаторы могут выполнять роль одного и того же преобразователя. Еще одним примером технического места является должность, отдел, подразделение, штат. Например, токарь участвует в функции изготовления деталей. Это — техническое место, роль которого в разное время могут выполнять разные единицы оборудования (физические лица). О сложностях моделирования технических мест и единиц оборудования я кратко написал в статье Моделирование активов предприятия: современные стандарты и практика.

При моделировании технических мест, мы описываем процессы и участников этих процессов. Замечу, что именно участников, а не исполнителей, — трансформатор не может преобразовывать напряжение, потому что он не является одушевленным существом. Об этом я писал в прошлой статье Моделирование активности и мифологическое сознание. Если все же сказать, что трансформатор «преобразует» напряжение, то это – метонимия, которая раскрывается так: трансформатор, исполняет роль преобразователя напряжения, который (преобразователь) участвует в процессе преобразования напряжения. О метонимии можно прочитать в книге «Метафоры, которыми мы живем», авторы: Джордж Лакофф, Марк Джонсон. Другой распространенной метонимией будет высказывание: «компьютер решает задачи». Те же, кто действительно считают, что трансформатор, или компьютер что-то делает на самом деле, одушевляют неодушевленное, пользуясь мифическим сознанием.

Заметим, что до сего момента мы ни слова не сказали о целях, об исполнителях и причинно-следственных связях. Мы лишь говорили о требованиях, о функциях и участниках этих функций – технических местах. Цели остались на этапе формирования требований к предприятию и далее они не пошли. Мы можем знать эти цели, а можем не знать, — для модели предприятия это не имеет никакого значения. Модель предприятия отвечает на вопрос: как мы удовлетворяем требования, а не то, откуда взялись эти требования. Исполнителей тоже нет, потому что нам не надо пользоваться теорией деятельности, чтобы описать участников активности. Мы не строим причинно-следственные связи. Если же надо построить модель причинно-следственных связей, то это еще одна дополнительная модель. Это знания, которыми пользуются технологи при проектировании предприятия, и я не видел, чтобы кто-то строил такие модели. Это — отраслевые знания, и учат им в институтах по много лет. Смоделировать, почему летит самолет – нереально трудно, и никто этого не делает. Просто моделируют полет самолета.

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

Как я сказал ранее, модель Захмана скорее про деятельность. При этом было бы неплохо, если бы модель Захмана использовалась по назначению, — как способ описания деятельности. Это давало бы возможность анализировать мотивы и заинтересованность людей в их работе, но беда в том, что эта модель используется неверно. Например, на вопрос «почему токарь точит деталь?» можно получить ответ: «она нужна в сборочном цехе». Но необходимость ее в сборочном цехе не отвечает на вопрос, почему токарь точит деталь. Ответ был не на поставленный вопрос, а на какой-то другой. Например, для такого ответа правильным был бы вопрос: в каком процессе, или в какой операции должна участвовать выточенная деталь? Или на каком рабочем месте она нужна? Вы видите, что это совсем не вопрос «почему?». Кроме того, меня сильно смущает наделение Захманом компьютера или информационной системы способностью что-то делать. Скорее всего, он не одушевляет их, но использует метонимию в моделировании, что на мой взгляд, недопустимо.

Правильными вопросами будут: Какие существуют требования к предприятию? Какие процессы протекают на предприятии? Какие технические места в каких процессах участвуют? Какие единицы оборудования выполняют роли каких технических мест и когда?

Собственно, все. С наступающим, и до новых встреч!