Опубликован: 02.09.2009 | Уровень: для всех | Доступ: свободно
Лекция 2:

Построение архитектуры организации

Конкурирующая среда GERAM ( Generalised Enterprise Reference Architecture and Methodology ) определяет комплекс концепций, методов и моделей, необходимых для проектирования и сопровождения современной организации (любого типа) в течении всего времени ее существования. GERAM обеспечивает поддержку всех вышепредставленных элементов среды моделирования архитектуры, базируясь при этом на:

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

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

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

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

Так основными недостатками семейство IDEF являются:

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

ARIS в целом преодолевает перечисленные недостатки IDEF, однако его методология по сути является методологией-оболочкой: нет четко описанных регламентов действий, не предлагается уникального подхода к проблеме моделирования архитектуры организации. Сам язык включает более 100 типов моделей, 90% из которых для целей архитектурного моделирования практически никогда не используются, инструментальная поддержка осуществляется продуктом той же компании – разработчика методологии. Этот продукт имеет цену, на порядок превышающую стоимость инструментов аналогичного класса для аналогичных платформ, и огромные трудозатраты на его разработку, что вряд ли позволит создать когда-либо конкурирующий инструментарий, поддерживающий данный язык.

Одной из последних разработок в данной области является создание специального языка, ориентированного на моделирование бизнес-процессов BPML (Business Process Modeling Language). Этот язык обеспечивает построение абстрактной исполняемой модели взаимодействующих процессов на основе концепции конечного автомата (машины конечных состояний). BPML представляет бизнес-процессы посредством объединения описания взаимодействий управляющих потоков, потоков данных и потоков событий с дополнительными ортогональными средствами моделирования бизнес-правил, ролей, контекста взаимодействия. Он поддерживает синхронные и асинхронные распределенные транзакции, поэтому может быть использован как исполняемая модель для встраивания существующих приложений в качестве процессных компонент внутрь е-бизнес-процессов.

Собственно бизнес-процессы описываются с использованием BPMN (Business Process Modeling Notation), обеспечивающего графическую нотацию для описания процессов BPD (Business Process Diagram), а также внутренние связи между элементами нотации и внешние связи с конструкциями других компонентов BPML (в частности, с конструкциями BPEL4WS - Business Process Execution Language for Web Services ). Отметим, что BPMN обеспечивает моделирование не только бизнес-процессов, но и веб-сервисов как между организациями, так и между подразделениями организации.

BPD-диаграммы моделирует события бизнес-процессов организации, концентрируя основное внимание на том, где процессы выполняются и где события имеют место. Эти диаграммы включают следующие основные объекты:

  1. события перед запуском процесса;
  2. активности (бизнес-процессы, бизнес-функции, бизнес-операции);
  3. конечные результаты выполнения процесса;
  4. информационные объекты (данные, документы и т.п. - все, что обновляется при выполнении процесса), привязанные к потокам;
  5. специальные узлы (шлюзы) для моделирования ветвлений;
  6. специальные объекты (плавательные дорожки и бассейны), используемые для уточнения модели и демонстрации того, в какой организационной единице происходит событие или процесс, с целью визуального разделения обработки потоков по организациям и организационным единицам (например, организация – бассейн, организационные единицы – дорожки).

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

Этапы моделирования с использованием BPML определяются методологией BEM ( Business Enterprise Modeling ) и включают:

  1. Определение бизнес-целей и требований:
    1. определение направлений бизнеса (включая миссию, цели, критические факторы успеха, критические бизнес-результаты, видение, ключевые бизнес-политики), установление целей деятельности организации и преобразование их в цели бизнес-процессов, достижение которых должно обеспечиться в результате их проектирования;
    2. построение набора матриц, покрывающих все аспекты бизнес-моделирования, но предшествующих детальному анализу (например, выражение бизнес-целей через организационные цели, формулирование стимулов достижения требуемого бизнес-поведения, увязка с приложениями, обеспечивающими достижение целей);
    3. выявление требований различных типов (функциональных, системных, технологических) из различных источников (документы, интервью и т.п.) и их документирование.
  2. Моделирование бизнеса с позиции менеджера: построение концептуальных потоковых бизнес-диаграмм с использованием графических образов (пиктограмм) для представления бизнес-объектов и событий.
  3. Моделирование бизнес-процессов с помощью BPMN
  4. Моделирование бизнес-функций с помощью диаграмм функциональной иерархии (дерева функций) с дополнительным использованием перекрестных ссылок по процессам (либо с помощью таблиц, либо напрямую на диаграмме).
  5. Моделирование организационно-штатной структуры (кто что делает, кто перед кем отчитывается, как принимаются и исполняются решения и т.д.) с использованием:
    1. логических схем организационно-штатной структуры ( Logical Organizational Chart ) сверху-вниз по организационным единицам;
    2. логических схем принятия решений ( Logical Decision Chart ) на основе двух типов объектов: организационных единиц и потоков движения решений.
  6. Отображение бизнес-моделей в приложения с использованием DFD-технологии.

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

Решением данной проблемы занимается рабочая группа, созданная компаниями – производителями языков моделирования, целью деятельности которой является создание унифицированного языка моделирования UEML (Unified Enterprise Modeling Language) с четко определенными синтаксисом, семантикой и правилами взаимоотношений (отображений) между различными языками моделирования архитектуры организаций. Проект UEML включает разработку:

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

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

Таблица 2.2.
Вендор Продукт Сайт
Casewise Corporate Modeler http://www.casewise.com
Computas Metis http://www.computas.com
IDS Scheer Aris http://www.ids-scheer.com
Mega Mega Suite http://www.mega.com
Popkin System Architect http://www.popkin.com
Proforma Corp. ProVision http://www.proformacorp.com
Ptech Enterprise Framework http://vwww.ptechinc.com

Среди инструментов построения архитектуры одним из наиболее продвинутых является Casewise Corporate Modeler, признанный в 2004г. лучшим инструментом для управления архитектурой организации по рейтингу META Group.

В основе инструмента лежит методология Casewise Framework, базирующаяся на модифицированной схеме (матрице) Захмана, столбцы которой характеризуют различные аспекты ЕА (мотивации, процессы, люди, местоположения, данные, время), а строки соответствуют уровням абстракции моделирования (бизнес, организация, системы, технологии, детали). При этом методология позволяет расширять предложенную схему, в частности, может быть увеличено количество уровней абстракции. Дополнительно на начальном этапе могут использоваться модели "Инициация проекта" и "Определение стандартов моделирования", определяющие, соответственно, цели, задачи, факторы успеха, ключевые роли и документы, а также нотации моделирования (типы диаграмм и их синтаксис, типы и категории объектов и т.п.).

Основными графическими нотациями являются организационные диаграммы (организационно-штатная структура и ее связи с бизнес-слоем и ИТ-слоем), диаграммы потоков данных (функциональные модели), диаграммы "сущность-связь" (информационные модели), диаграммы динамики процессов (модели поведения), а также матрицы межобъектных связей. В качестве расширений могут использоваться нотации языков IDEF0 и UML, а также нотация BPMN (Business Process Modeling Notation) – основа современного языка моделирования бизнес-процессов BPML (Business Process Modeling Language), являющего в настоящее время стандартом де-факто в рассматриваемой области.

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

  1. Perfomance Reference Model;
  2. Business Reference Model;
  3. Service Component Reference Model;
  4. Data&Information Reference Model;
  5. Technical Reference Model.

Также имеется референсная модель процессов ITIL ( IT Infrastructure Library ), описывающая предоставляемые ИТ-услуги, включая техническую поддержку, управление приложениями, безопасностью, а также планирование и мониторинг внедрения ITIL. Соответствующие диаграммы отражают все компоненты ИТ-инфраструктуры: ресурсы, базы данных, приложения и оборудование.

Еще одной референсной моделью является eTOM ( The Enchanced Telecom Operation Map ) - модель деятельности телекоммуникационных компаний, воплощающая собой весь опыт мирового сообщества, накопленный в этой отрасли. Модель eTOM применяется в качестве основы организации работ при проектировании и оптимизации архитектур телекоммуникационных компаний, она может быть интегрирована с моделью ITIL.

Одним из достоинств методологии является возможность интеграции не только бизнес-слоя и ИТ-слоя, но и стратегического слоя архитектуры. Для этой цели предлагаются методики и инструменты управления ИТ-инфраструктурой организации (IT Architecture Accelerator) и ее стратегией на основе системы сбалансированных показателей (Balanced Scorecard Accelerator). Так, например, с помощью IT Architecture Accelerator можно управлять проектом реализации ИТ-стратегии: осуществлять оценку проектов, устанавливать их приоритеты по степени срочности, важности и стратегической значимости, планировать сроки и осуществлять контроль за их реализацией.

В качестве репозитария, непосредственно реализующего интеграцию, используется как собственная база данных DP4 Corporate Modeler Suite, так и другие СУБД - Oracle, MS SQL.

В заключении отметим, что решения Casewise обладают возможностью интеграции с инструментом управления требованиями IBM-Rational RequsitePro, объектно-ориентированными инструментами разработки IBM-Rational Rose, инструментами моделирования баз данных Oracle Designer, Sybase PowerDesigner и ERWin.

Надежда Артюх
Надежда Артюх
Что из себя представляет итоговая работа?
Олег Антонов
Олег Антонов
Добрый день. Является ли выдаваемый сертификат или диплом, документом государственного образца?
Андрей Прокопов
Андрей Прокопов
Россия
Алексей Мендрин
Алексей Мендрин
Украина