
- •Тема 1. Понятие и общее представление об архитектуре предприятия.
- •Тема 2. Основные цели создания архитектуры предприятия.
- •Тема 3. Общие методические принципы создания архитектуры.
- •Тема 4. Формирование архитектуры в процессе детализации.
- •4.1. Подходы при построении архитектуры.
- •4.2. Компоненты архитектуры предприятия.
- •Тема 5. Комплексная архитектура предприятия. Модельные и организационные подходы.
- •5.1. Матрица согласованных моделей в архитектурах.
- •5.2. Примеры заполнения ячеек схемы Захмана.
- •5.3. Схема «3д-предприятие».
- •5.4. Требования к «3д-модели».
Тема 5. Комплексная архитектура предприятия. Модельные и организационные подходы.
С целью дальнейшей проработки архитектурных слоев целесообразно переходить на другое, более детальное, представление архитектуры. В качестве такого представления предлагается использовать схему архитектуры предприятия Дж. Захмана, которая в 90-х годах стала стандартом де-факто.
Схема Дж. Захмана версии 1987, 1992, 2000 гг. отличается более гармоничным и комплексным учетом архитектурно существенных факторов, начиная со слоев бизнес - архитектуры.
В то же время она не навязывает конкретных инструментальных особенностей при формировании моделей.
Благодаря этому схема архитектуры предприятия Дж. Захмана может использоваться в качестве референсной модели для разработки адаптированных методических материалов для конкретных предприятий. Здесь под референсной понимается ссылочная, рамочная эталонная модель.
Свойство моделей, описаний, проектов, имеющих статус стандартизованного образца, характеризует их как шаблоны, которые могут быть использованы в разработках различных конкретных систем.
Однако эта схема, как и изложенные выше схемы архитектурных слоев, обладает недостатками с точки зрения представления динамики развития предприятия и его ИС. Этот недостаток преодолевается расширенной схемой Захмана – схема и подход «3Д-предприятие» (опубликована в 2000 году).
При описании процесса разработки и использовании архитектуры конкретного предприятия рассматривается схема движения от архитектуры «как есть» к архитектуре «как должно быть».
Вышесказанное имеет особое значение для предприятия, включенного в программу трансформации.
5.1. Матрица согласованных моделей в архитектурах.
Сложные системы характеризуются выполняемыми процессами (функциями), структурой и поведением во времени. Для адекватного моделирования этих аспектов в автоматизированных информационных системах различают организационные, функциональные, информационные и поведенческие модели пересекающиеся друг с другом.
Функциональная модель системы описывает совокупность выполняемых системой функций, характеризует морфологию системы (ее построение)- состав функциональных подсистем, их взаимосвязи.
Информационная модель отражает отношения между элементами системы в виде структур данных (состав и взаимосвязи).
Поведенческая (событийная) модель описывает информационные процессы (динамику функционирования). В ней фигурируют такие категории, как состояние системы, событие, переход из одного состояния в другое, условия перехода, последовательность событий.
Организационная модель описывает подразделения из которых состоит предприятие.
Все эти модели должны быть соединены в единую систему понятным и непротиворечивым образом. Поэтому даже вопросов «простого» согласования компонентов системы достаточно для того, чтобы прилагать специальные усилия на уровне формирования архитектуры.
Идея такого согласования состоит в том, что его надо начинать с самых главных характеристик предприятия, рассматривая важнейшие содержательные аспекты. В идеальном случае согласование начинают с конструирования системы управления предприятием, а именно с создания сбалансированной системы целей и планов. В эту сбалансированную систему целей и планов входят: миссия предприятия, стратегические цели, индикаторы достижения целей и их целевые значения; мероприятия по достижению целей, включая архитектуру информационной системы и информационно-технологическую платформу, а также обновленные бизнес – процессы и оргструктуры; система мотивации работников и планы их профессионального обучения и т.д. Согласование проводят на явно изложенных описаниях предприятия, которые позволяют видеть все существенные взаимосвязи, т.е. на его моделях.
Суть этого метода сводится к формализованному представлению предприятия в виде матрицы (Таблица 1).
Строки таблицы отражают уровни представления системы, к ним относятся уровни моделирования, уровни решения проектных задач. Более детально это следующие представления:
бизнес среда системы,
концептуальная модель,
логическая модель,
технологическая, «физическая модель»,
детальная реализация (часто поблочная),
представление пользователя (эксплуатация).
Выделенные аспекты, столбцы таблицы, фактически отражают разделы обеспечения системы:
информационное обеспечение (данные),
функциональное обеспечение (функции),
коммуникационное обеспечение (сеть),
организационное обеспечение (структура организации) и т.д.
Описанные разделы обеспечения и уровни представления схемы Захмана являются классификацией сущностей предприятия и его информационной системы.
В строках этой матрицы описываются модели предметной (проблемной) области с позиции различных категорий участников процесса проектирования, к которым относятся представители будущих пользователей системы (заказчиков), проектировщики (консультанты), участвующие в процессе получения и формирования знаний о проблемной области и формулирующие требования к ИС; разработчики и эксплуатационщики ИС.
Проектировщики вместе с заказчиками должны формировать модели предметной (проблемной) области, отражающие содержательную сторону функционирования системы, при этом проектировщики закладывают технологические требования к реализации системы, скрытые от взгляда пользователей.
Таблица 1. Матрица согласованных моделей в архитектурах.
|
Виды моделей и их реализация |
Цели (почему?)
Дерево целей |
Люди (кто?) Архитектура организации |
Функции (как?) Архитек-тура прило-жений |
Объекты-данные (что?) Архитек- тура данных |
Коммуникации (где?) Архитек- тура технологи-ческая |
Время события (когда?) |
1 |
Укрупненная модель организации (планировщик, пользователь) |
Список целей и задач |
Список организаций (подразделе- ний) |
Список процесс-сов |
Список сущностей |
Список узлов |
Список основных событий |
2 |
Концептуальная модель организации (проектировщик, пользователь) |
Стратегичес-кая модель: цель – стратегия. |
Структурные модели: подразделе-ния – работа |
Функцио-нальные модели: процесс – ресурс. |
Информацион-но-логические модели: ER-диаг-раммы |
Модель топологии узлов |
Модель корпоратив-ных событий |
3 |
Системная модель ИС (консультант-проектировщик) |
Критерии достижения целей |
Роли персонала |
Диаграммы потоков данных |
Логическая модель данных |
Логическая модель сетей организации |
Модель системных событий |
4 |
Технологическая модель (разработчик ИС) |
Модель «состояние-действие» |
Модель интерфейса |
Модель приложе- ний |
Модель внутреннего представления |
Физическая модель коммуникаций |
Модель технических событий |
5 |
Компоненты (разработчик ИС, субподрядчик) |
Шаг/задача |
Пользователь – транзакция |
Програм- мные модули |
Базы данных |
Протоколы |
Компонент-ные события |
6 |
Функционирую-щая система (эксплуатацион-щики) |
Варианты исполнения |
Сеансы работы |
Проце- дуры |
Ограничения целостности |
Клиент – сервер |
Операцион-ные события |
На основе модели требований разработчики ИС проводят технологическую детализацию проекта и его последующую реализацию. На основе сформированной рабочей документации и полученного конечного продукта системы эксплуатационщики осуществляют поддержку функционирования системы в новых условиях.
Архитектуры рассматривают систему в разрезе одних и тех же аспектов, но под разными углами зрения.
В качестве основных аспектов построения архитектур рассматриваются следующие:
– цели, бизнес-правила (мотивация того, почему функционирует система);
– объекты (что проходит преобразования);
– функции (как осуществляется преобразование в процессе);
– участники (субъекты) процесса (кто осуществляет процесс);
– место (где выполняется процесс);
– время (временные требования к выполнению процесса, событиям).
В двух первых строках представлены модели, относящиеся к точке зрения будущих пользователей системы, третья строка соответствует взгляду консультанта-проектировщика, четвертая и пятая строки – точке зрения разработчика ИС, шестая строка – точке зрения эксплуатационных служб.
Подход на основе архитектур Д.А. Захмана не определяет собственно методы построения моделей проблемной области, тем не менее, развитые методологии моделирования предметных областей предполагают реализацию принципов последовательной детализации абстрактных категорий: целей, объектов, функций, организационных единиц и т.д. на уровнях определения требований к системе, их спецификации и реализации.