Основные модели и инструменты описания бизнес-архитектуры

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

Модели бывают различных типов: модели процессов/потоков работ, функциональные модели, организационные модели, модели данных/ресурсов, временные модели типа диаграмм Ганта, модели причинно-следственных связей. Факт заключается в том, что нет "одной, самой лучшей" модели для описания бизнес-процессов. Можно провести аналогию с графиками, которые используются для иллюстраций. Круговая диаграмма с сегментами, пропорциональными по размеру проценту чего-либо целого, отлично подходит для определенных задач, но ее нельзя использовать для иллюстрации и анализа всех типов данных (например, изменений каких-то данных во времени). Точно также при анализе бизнес-процессов выбранный метод моделирования должен отражать цели анализа. Оптимизация процесса по времени и четкий анализ взаимодействия между участниками процесса могут потребовать разных моделей.

Для автоматизации моделирования процессов сложился специальный класс программных продуктов. Наиболее известными являются такие продукты, как ARIS, Software Architeсt, BPWin (новое название – AllFusion Process Modeler), хотя в большом количестве случаев стандартных графических пакетов типа Microsoft Visio, текстового редактора и электронной таблицы бывает достаточно. В данном курсе мы не будем останавливаться на сравнительном анализе этих и других средств, и отсылаем читателя к специализированным публикациям.

Основное внимание при разработке Бизнес-архитектуры должно уделяться "картине в целом". Целью Бизнес-архитектуры не является детальное описание деятельности предприятия. Модели, включенные в Бизнес-архитектуру, должны давать необходимый минимум сведений о ключевых функциях, процессах, бизнес-событиях и потоках информации, достаточный для процесса принятия решений, поиска новых возможностей для инноваций. Дальнейшая детализация выполняется с использованием таких инструментов, как:

· декомпозиция функций/процессов;

· анализ бизнес-событий;

· моделирование местоположений выполнения функций/процессов;

· модель интеграции функций/процессов.

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

· задать границы анализа рассмотрением наиболее критически важных функций бизнеса;

· идентифицировать основные процессы, обеспечивающие выполнение функций организации;

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

· идентифицировать пересечения и излишние функции/процессы.

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

Таблица 2. Компоненты декомпозиции функций/процессов
Основная область анализа	Результаты (артефакты) анализа	Основные вопросы
· Определить границы каждой бизнес-функции · Понять состав подпроцессов каждой бизнес-функции · Дать основу для увязывания архитектуры информации, приложений и технологической архитектуры с бизнес-функциями	· Подпроцессы основных бизнес-функций · Идентификация излишних и малополезных, неэффективных активностей · Требования к прикладным системам и информации	· Каковы основные функции организации? · Какие функции не несут в себе ценности? · Какие функции пересекаются с другими бизнес-функциями?

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

Таблица 3. Компоненты анализа бизнес-событий
Основная область анализа	Результаты (артефакты) анализа	Основные вопросы
· Обеспечить понимание ограниченного набора основных бизнес-событий · Анализ возможностей по оптимизации бизнес-процессов · Повышение эффективности операции, улучшение взаимодействия с клиентами,…	· Основные инициаторы и участники бизнес-событий · Партнеры · Идентификация критически важных артефактов, создающихся и используемых в процессе обработки события · Проверка возможностей по новациям · Новые формы ведения бизнеса	· Кто является инициатором бизнес-события? · Как событие обрабатывается в рамках расширенного предприятия (партнеры и пр.)? · Кто является основными участниками события? · Возможны ли инновации, которые связаны с событием и требуются бизнесом?

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

Таблица 4. Компоненты модели местоположений
Основная область анализа	Результаты (артефакты) анализа	Основные вопросы
· Обеспечить понимание того, где выполняются функции и процессы · Понимание требований, накладываемых географическим расположением на решения, касающиеся бизнес- и технологической архитектуры · Понимание требований со стороны технологической архитектуры к географическому расположению функций	· Распределение функций по местоположениям · Связи между бизнес-функциями · Требования к технологической архитектуре и архитектуре прикладных систем · Возможности по организационным изменениям	· Где выполняются основные функции? · Какие функции связаны между собой? · Существуют ли возможности по консолидации и рационализации?

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

Таблица 5. Компоненты модели интеграции
Основная область анализа	Результаты (артефакты) анализа	Основные вопросы
· Обеспечить понимание ключевых внутренних и внешних точек интеграции · Информационные потоки между участниками бизнес-событий · Понимание основных интерфейсов прикладных систем · Понимание требований к технологической архитектуре с точки зрения интеграции	· Потоки информации, которые требуются для реализации различных шаблонов бизнес-процессов · Связи между функциями бизнеса · Требования к архитектуре информации, приложениям и технологической архитектуре · Возможности для организационных изменений	· Какая информация является критической для новых шаблонов реализации бизнес-процессов? · Какие потоки информации существуют между различными точками соединения моделей бизнес-событий? · Каковы требования с точки зрения времени?

После того как модели созданы, на их основе можно выполнять различные методы анализа:

· Анализ цепочек создания добавочной стоимости (А нужно ли вообще выполнять этот шаг?)

· Динамическое моделирование (Как эта модель выполнения бизнес-функций будет себя вести при различных значениях на входе и доступных ресурсах, и как со временем будет меняться поведение процесса?)

· Анализ пересечений и непокрытых областей (Gap- overlap analysis) (Будет ли наша бизнес-архитектура иметь избыточные элементы, и есть ли в ней "пробелы"?)

· Соотнесение затрат с активностями (Activity-based costing) (На каких процессах, каналах продаж и заказчиках мы реально зарабатываем или теряем деньги?)

· Обучение (Как эти бизнес-процессы соотносятся с другими?)

· Общая стоимость владения (Сколько стоит этот процесс?)

· Возврат инвестиций (ROI) (Будет ли достигнут возврат инвестиций в данный бизнес-процесс и когда?)

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

Мы уже отмечали, что показатели эффективности являются важной составляющей бизнес-архитектуры. Например, в методике FEAF Федеральной Архитектуры США имеется отдельная, явно выделенная модель показателей эффективности.

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

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

В связи с развитием принципов сервис-ориентированной архитектуры и появлением технологически нейтрального, платформенно-независимого языка описания и выполнения бизнес-процессов BPEL (Business Process Execution Language) появилась возможность не только моделировать бизнес-процессы, но и делать их целиком или частично доступными другим системам и организациям в виде сервисов. К этому можно добавить также возможности еще одного стандарта XML Metadata Interchange (XMI) для обмена (экспорта/импорта) данных практически в любые интеграционные продукты. В совокупности это дает возможность создавать модели и репозитории бизнес-процессов для их эффективной интеграции.

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

Архитектура информации