ЛЕКЦИЯ 3. ЭЛЕМЕНТЫ БИЗНЕС-АРХИТЕКТУРЫ И ИТ-АРХИТЕКТУРЫ АРХИТЕКТУРА ИНФОРМАЦИОННЫХ СИСТЕМ

РЕКОМЕНДУЕМАЯ ЛИТЕРАТУРА Б. Я. Советов, А. И. Водяхо, В. А. Дубенецкий, В. В. Цехановский. Архитектура информационных систем: учебник для студ. учреждений высш. проф. образования. - М. : Издательский центр «Академия», А.В. Данилин, А.И. Слюсаренко. Архитектура предприятия. М: ИНТУИТ,

ДОМЕНЫ (ПРЕДМЕТНЫЕ ОБЛАСТИ) АРХИТЕКТУРЫ Обычно в составе архитектуры выделяют от четырех до семи основных представлений (предметных областей или доменов): Бизнес-архитектура. Описывает деятельность организации с точки зрения ее ключевых бизнес-процессов. ИТ-архитектура. Обеспечивает достижение бизнес-целей посредством использования программной инфраструктуры, ориентированной на реализацию наиболее важных бизнес-приложений; Архитектура информации (данных). Определяет, какие данные необходимы для поддержания бизнес-процессов (например, модель данных), а также для обеспечения стабильности и возможности долговременного использования этих данных в прикладных системах. Архитектура приложений. Определяет, какие приложения используются и должны использоваться для управления данными и поддержки бизнес-функций (например, модели приложений). Технологическая архитектура (инфраструктура или системная архитектура). Определяет, какие обеспечивающие технологии (аппаратное и системное программное обеспечение, сети и коммуникации) необходимы для создания среды работы приложений, которые, в свою очередь, управляют данными и обеспечивают бизнес- функции. Эта среда должна обеспечивать работу прикладных систем на заданном уровне предоставления сервисов своим пользователям.

АРХИТЕКТУРА ИНФОРМАЦИОННОЙ СИСТЕМЫ Бизнес- архитектура ИТ-архитектура Архитектура данных Архитектура приложений Технологическая архитектура

ИНЫЕ ПРЕДСТАВЛЕНИЯ АРХИТЕКТУРЫ В зависимости от конкретных потребностей организации и актуальности решения тех или иных проблем можно выделить дополнительные представления архитектуры, например: Архитектура интеграции. Определяет инфраструктуру для интеграции различных приложений и данных. Например, в проектах в области "электронного правительства", когда имеется большое количество государственных информационных систем различных ведомств, возникает настоятельная потребность создания самостоятельной инфраструктуры интеграции (архитектура интеграции), с целью предоставления государством интегрированных услуг гражданам и бизнесу по принципу "одного окна". Архитектура общих сервисов. Примерами их являются такие сервисы, как электронная почта, каталоги, общие механизмы безопасности (идентификации, аутентификации, авторизации). То есть, это достаточно большое количество прикладных систем, которые носят "горизонтальный характер". Сетевая архитектура. Определяет описания, правила, стандарты, которые связаны с сетевыми и коммуникационными технологиями, используемыми в организации. Архитектура безопасности и т.д.

МОДЕЛЬ ОПИСАНИЯ СТРАТЕГИИ И АРХИТЕКТУРЫ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ

ЭЛЕМЕНТЫ ОПИСАНИЯ СТРАТЕГИИ И АРХИТЕКТУРЫ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ Миссия и видение. Руководящие принципы. Утверждения, описывающие принципы и ключевые элементы философии использования информационных технологий. Цели, задачи и стратегии. Архитектура информационных технологий.

ЭЛЕМЕНТЫ ОПИСАНИЯ БИЗНЕС – АРХИТЕКТУРЫ И АРХИТЕКТУРЫ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ Политики (правила). Политики являются общими утверждениями, которые задают направления и цели, связанные с инициативами в области ИТ. Они носят, как правило, достаточно высокоуровневый и общий характер и обеспечивают скоординированный процесс планирования, закупку критически важных технологий, эффективную разработку систем и эффективное использование информационных технологий и ресурсов. ИТ-стандарты. Стандарты – это обязательные к использованию утверждения, касающиеся используемых технологий, продуктов и/или услуг. Они должны быть достаточно полными и в то же время определять разумный минимум требований, обязательных для использования. Процедуры. Процедуры – это инструкции, описывающие, как выполняются политики и стандарты. Процедуры устанавливают и описывают процессы, которые выполняются на регулярной основе. Руководства или рекомендации. Руководства и рекомендации – это описания лучших практик или приемлемых подходов к практической реализации политик и процедур. Руководства могут стать стандартами.

ПОЛИТИКИ, СТАНДАРТЫ И ПРОЦЕДУРЫ

ЭВОЛЮЦИЯ КОНТЕНТА АРХИТЕКТУРЫ ПРЕДПРИЯТИЯ Когда организация находится в самом начале процесса разработки своей архитектуры, то, как правило, нет полной ясности и согласия по поводу используемых моделей и даже разбиения архитектуры на представления (домены). Будущие состояния архитектуры должны описываться с использованием соответствующих моделей, описывающих отдельные представления (домены) будущей архитектуры.

ПРИМЕРЫ ОБЩИХ ПРИНЦИПОВ, СВЯЗАННЫХ С АРХИТЕКТУРОЙ В ЦЕЛОМ Все подразделения должны использовать в своей работе архитектуру, разработанную для организации в целом. Функциональное руководство и руководство в области ИТ должно основываться на едином видении. Архитектура должна обеспечивать решение вопросов бесперебойного выполнения организациями своих функций, безопасности и восстановления в случае катастрофических событий. Функциональные (бизнес-) требования должны формировать архитектуру. Архитектура должна обеспечивать совместимость и взаимодействие. Архитектура должна быть расширяемой, масштабируемой и адаптивной. Архитектура должна быть инструментом реализации изменений. Архитектура должна уменьшать сложность интеграции и способствовать улучшению качества бизнес-процессов. Тенденции рынка должны учитываться при проектировании технологической архитектуры.

ПРИМЕРЫ ДЕКЛАРИРУЕМЫХ ПРИНЦИПОВ В ОБЛАСТИ ИТ-ИНФРАСТРУКТУРЫ Инфраструктура должна быть основана на использовании технологий, поддерживающих открытые стандарты. Инфраструктура (совместно с принципами управления данными и разработки приложений) должна обеспечивать взаимодействие систем.

ПРИМЕРЫ ПРИНЦИПОВ В ОБЛАСТИ УПРАВЛЕНИЯ ДАННЫМИ: Информация является ценным ресурсом, который передан в управление менеджерам, и этим ресурсом необходимо соответствующим образом управлять. Бизнес-структуры (отделы, департаменты), являющиеся владельцами данных, отвечают за целостность и распространение данных. Данные уровня отдельных бизнес-структур должны быть явно описаны и доступны всем остальным бизнес-структурам. Верхний уровень собирает только самый необходимый минимум данных и стремятся уменьшить нагрузку на тех, кто должен предоставлять данные. Данные вводятся в информационные системы один раз, и тут же выполняется проверка их корректности.

ПРИМЕРЫ ПРИНЦИПОВ, СВЯЗАННЫХ С ПРИКЛАДНЫМИ СИСТЕМАМИ: Прикладные системы разрабатываются на основе стандартной, единой методологии. Все структурные подразделения используют общие методы представления информации пользователям в своих приложениях и координируют работы по созданию пользовательского интерфейса межфункциональных систем. Создание межфункциональных прикладных систем приветствуется. Руководство заранее планирует процесс замены устаревших прикладных систем.

ПРИМЕРЫ ПРИНЦИПОВ, СВЯЗАННЫХ С УПРАВЛЕНИЕМ И КОНТРОЛЕМ: Единая архитектура, соответствующие стандарты и руководства используются всеми структурными подразделениями в процессе принятия решений о своих информационных системах. Стандарты пересматриваются регулярно не реже одного раза в два года с участием представителей структурных подразделений. Руководство структурных подразделений стремится к кооперации и партнерству с другими структурными подразделениями в области информационных технологий.

СТАНДАРТЫ АРХИТЕКТУРЫ ПРЕДПРИЯТИЯ Стандарты содержат обязательные и факультативные (необязательные) требования, которые обеспечивают единство в подходах к проектированию и созданию систем.

РАЗРАБОТКА И ПРИМЕНЕНИЕ СТАНДАРТОВ При разработке и использовании стандартов следует учитывать нижеперечисленные аспекты: Уделять основное внимание стандартам, которые обеспечивают эффективное использование базовых технологий. Прежде всего, это технологии, на которых построены многие системы и которые стали индустриальными стандартами. Примерами таких технологий для организаций являются XML,.NET, Java. Определять стандарты процессов. Примерами являются процессы бизнес- моделирования, методы разработки систем, тестирования, интеграции. Внимание к интерфейсам. Понимание интерфейсов является основой для интеграции систем. Тесное взаимодействуйте с бизнес-подразделениями. Например, разработка основанных на XML стандартов на электронные сообщения невозможна без участия специалистов в конкретных предметных областях. Стандарты должны включать списки конкретных версий технологий, интерфейсов программирования (API), утилит и т.д. Примерами могут быть версии систем управления базами данных, версии XML и т.п. Стандарты должны включать способы проверки на соответствие (верификация). Стандарты должны содержать описание того, как организован процесс их поддержки. Стандарты должны периодически пересматриваться и обновляться.

РУКОВОДСТВА (РЕКОМЕНДАЦИИ) Руководства (рекомендации) обеспечивают помощь в разработке и создании систем, давая примеры лучших практик и конкретные руководства по выполнению чего-либо: Руководства не заменяют техническую документацию, но рассматривают некоторые проблемы в контексте конкретной организации. Хорошие руководства сфокусированы на конкретных проблемах, общих для большинства разработчиков систем. Это включает, например, интеграцию приложений с использованием соответствующих систем интеграции корпоративных приложений, создание "горизонтальных" порталов, контроль версий. Тематика руководств может быть связана как с технологиями и их использованием, так и с процессами. Например, весьма полезными могут стать руководства, описывающие процессы создания конфигурации систем, построения версии системы или процесс контроля качества. Наиболее эффективные руководства, как правило, короткие и специфичные.

МОДЕЛЬ СИСТЕМЫ Модель содержит конкретные данные, определяющие характеристики системы. Данные используются как некоторое представление реальной системы в целях ее концептуального осмысления, описания процессов обмена информацией с этой системой, понимания того, как система работает с точки зрения конечных пользователей.

КРИТЕРИИ КЛАССИФИКАЦИИ МОДЕЛЕЙ формальные (использующие общепринятые правила, нотации и средства) и неформальные ; количественные – позволяющие производить численные оценки и проверки, и качественные, предназначенные для понимания поведения и структуры системы; описательные – предназначенные только для восприятия человеком, или исполняемые, позволяющие исследовать их поведение и использовать полученные результаты для выводов об исходной системе.

ПРИМЕРЫ КАЧЕСТВЕННЫХ И ОПИСАТЕЛЬНЫХ МОДЕЛЕЙ ПРИМЕРЫ КАЧЕСТВЕННЫХ И ОПИСАТЕЛЬНЫХ МОДЕЛЕЙ Текстовые модели, использующие либо одну из формальных грамматик, либо обычный текст. Визуальные модели, представляемые в виде диаграмм с определенной нотацией. Наиболее популярный язык для описания таких моделей программных систем в последнее время – UML.

ПРИМЕРЫ КОЛИЧЕСТВЕННЫХ МОДЕЛЕЙ ПРИМЕРЫ КОЛИЧЕСТВЕННЫХ МОДЕЛЕЙ математические модели, которые могут быть описаны системами уравнений. Решение уравнений может быть в простейшем случае найдено в аналитической форме, в более сложных случаях применяются различные численные методы. Достаточно часто применяются электронные таблицы, с помощью которых могут быть проведены исследования типа "что – если". динамические исполняемые модели, которые строятся с использованием специализированных программных или программно-технических средств и позволяют исследовать поведение описываемых ими объектов в различных внешних условиях. Данные модели относятся к числу наиболее сложных и часто применяются на этапе выбора архитектуры сложных систем со многими элементами и связями, особенно когда поведение элементов описывается нелинейной или случайной функцией.

РАЗРАБОТКА МОДЕЛЕЙ Разработка моделей для различных доменов (предметных областей) архитектуры является итерационным процессом, который связан с рассмотрением различных перспектив (уровней абстракции), а также связей между моделями отдельных доменов архитектуры. На самом верхнем уровне описания контекста архитектуры для описания архитектуры информации могут использоваться списки бизнес-сущностей, таких как "счет", "клиент" и т.д., для архитектуры прикладных систем будет достаточно иметь список основных бизнес-процессов, а для технологической архитектуры – информации о местах расположения бизнеса.

МОДЕЛИ, ИСПОЛЬЗУЕМЫЕ ДЛЯ РАЗЛИЧНЫХ ПРЕДСТАВЛЕНИЙ (ДОМЕНОВ) И ПЕРСПЕКТИВ (УРОВНЕЙ АБСТРАКЦИИ) Домены Перспекивы (уровни абстракции) Бизнес-архитектура Архитектура информации Архитектура приложений Технологическая архитектура Контекст ("планировщик") Классы бизнес- процессов (группа процессов, имеющих много общих активностей) Список бизнес- процессов Список бизнес- сущностей – объектов, важных для бизнеса ("клиент", счет") Связи между сущностями (бизнес- объектами) Список бизнес- процессов Список мест расположения бизнеса Концептуальный уровень("владелец" предприятия) Сценарии использования (Use case) Модели бизнес- процессов Семантические модели Модели связей Модели "сущность- связи" Разбиение процессов на сервисы Модели бизнес- логистики Операционные (нефункциональные) требования Архитектура расположения элементов центра обработки данных Логический ("проектировщик") Модели процессов (потоков работ) Модели бизнес-событий Модель расположения процессов Определения ролей Логические модели данных Схемы данных Спецификации документов Определения сервисов Взаимосвязи между сервисами Модели классов Логические типы серверов: БД, почтовые, транзакционные, … Географическое распределение серверов Хостируемое ПО Физический ("разработчик") Спецификации процессов Модели интеграции процессов Описание ручных процедур Стандарты качества Физические модели данных Схемы БД Код доступа к данным Справочники данных Код программ Описания интерфейсов (WSDL) Расписания процессов Код workflow Физические серверы Топология фрагментов сети Мапирование продуктов на сервисы и приложения

ПРИМЕР ОПИСАНИЯ СИСТЕМЫ В качестве примера возьмем онлайновую систему выполнения заказов некоторого гипотетического магазина. Для описания требований к системе, ее проектирования и разработки можно рассматривать динамические и статические модели на различных уровнях абстракции: уровень контекста, концептуальный, логический, физический уровни.

КОНЦЕПТУАЛЬНЫЙ УРОВЕНЬ АБСТРАКЦИИ Модель на самом высоком уровне описывает бизнес-процессы продавца и содержит простой сценарий использования (use case), описывающий взаимодействия между системой и акторами Динамическая модель для этого уровня должна отражать взаимодействия между клиентом и магазином. При этом сама проектируемая система выступает как один из акторов процесса в качестве "черного ящика". Клиент и сотрудник(и) магазина выступают как внешние по отношению к системе акторы. Весь процесс рассматривается с точки зрения клиента и сотрудника. Клиент осуществляет заказ через Интернет. Оплата выполняется с помощью кредитной карты. Заказ посылается по указанному адресу. Уведомление о выполнении заказа посылается по электронной почте.

ДИНАМИЧЕСКАЯ КОНЦЕПТУАЛЬНАЯ МОДЕЛЬ ПРОЦЕССА ЗАКУПКИ ТОВАРА ДИНАМИЧЕСКАЯ КОНЦЕПТУАЛЬНАЯ МОДЕЛЬ ПРОЦЕССА ЗАКУПКИ ТОВАРА

СТАТИЧЕСКАЯ МОДЕЛЬ Статическая модель на этом уровне абстракции отражает структуру классов и связи между объектами, необходимость в которых становится очевидной при анализе динамической модели. Модель отвечает на вопрос "Какие объекты должен понимать клиент для того, чтобы выполнить транзакцию, связанную с покупкой?"

СТАТИЧЕСКАЯ МОДЕЛЬ ПРОЦЕССА ЗАКУПКИ ТОВАРА В МАГАЗИНЕ

ОСНОВНЫЕ ЭЛЕМЕНТЫ БИЗНЕС- АРХИТЕКТУРЫ Бизнес-стратегия, функции и организационные структуры – собрание целевых установок, планов и структур организации. Данная информация может быть представлена в самых разных форматах, но наиболее важный аспект состоит в создании контекста для описания бизнес- процессов. Архитектура бизнес-процессов, которая определяет основные функциональные области организации. Показатели эффективности. Этот аспект состоит в определении ключевых показателей эффективности (КПЭ) работы организации, их текущих уровней и желаемых, будущих уровней и включает в себя также разработку на верхнем уровне модели КПЭ для мониторинга.

ПОСТРОЕНИЕ БИЗНЕС- АРХИТЕКТУРЫ ПОСТРОЕНИЕ БИЗНЕС- АРХИТЕКТУРЫ Каков внешний контекст деятельности организации? В чем состоят основные функции и добавочная стоимость, которая является итогом деятельности организации? Какие сценарии развития бизнеса необходимо учитывать, и какова вероятность их реализации? Какие необходимы информационные взаимосвязи и процессы обработки информации? Построение бизнес- архитектуры начинается с общего обзора ситуации:

КОНТЕКСТ БИЗНЕС-АРХИТЕКТУРЫ

ПОСТРОЕНИЕ МОДЕЛЕЙ Gartner рекомендует начать с построения высокоуровневых моделей бизнес-процессов предприятия. Начальным этапом для этого является определение классов бизнес-процессов. Под классом бизнес-процессов понимается группа процессов, которые состоят из большого числа одинаковых бизнес-активностей.

ШАГИ МОДЕЛИРОВАНИЯ Шаг 1. Идентификация критически важных для предприятия процессов (обычно не более восьми): процессы, которые открывают новые возможности, например, новые каналы предоставления услуг; процессы, которые в настоящее время выполняются плохо и являются источниками неудовлетворенност и клиентов; процессы, в которых имеются возможности для экономии. Шаг 2. Отследить связи между этими процессами и бизнес-стратегиями, движущими силами и критически важными факторами успеха. Это можно сделать с помощью матрицы взаимных связей. Для каждого элемента этой матрицы определяется качественная оценка по принципу "важно" – "неважно" или по некоторой условной шкале. Например, можно использовать так называемую шкалу 9-3-1, в соответствии с которой 9 обозначает сильную взаимосвязь, 3 – промежуточную, 1 – слабую. Шаг 3. Построить модели высокого уровня для ключевых бизнес- процессов (см. следующий раздел). Это включает последовательн ость основных шагов (желательно, не более восьми на процесс). Шаг 4. Для каждого шага процессов, идентифициров анных на этапе 3, определить ответственных за выполнение шага. Это может быть функционально е подразделение внутри организации, партнер, клиент, внешний регулирующий орган. Шаг 5. Идентифициро вать и документирова ть основные категории информационн ых объектов (опять же рекомендуется не более восьми).

ОСНОВНЫЕ МОДЕЛИ И ИНСТРУМЕНТЫ ОПИСАНИЯ БИЗНЕС-АРХИТЕКТУРЫ Архитекторы нуждаются в простых, высокоуровневых средствах описания активностей и зависимостей в терминах, которые понятны бизнес-руководителям и пользователям. Модели обеспечивают важную связь между бизнес-целями и стратегиями деятельности организации и многими вариантами реализации ИТ (такими как готовые пакеты программ, унаследованные приложения, специально созданные заказные приложения, обслуживание по принципу аутсорсинга и подписки). Модели бывают различных типов: модели процессов/потоков работ, функциональные модели, организационные модели, модели данных/ресурсов, временные модели типа диаграмм Ганта, модели причинно-следственных связей.

ИНСТРУМЕНТЫ ДЕКОМПОЗИЦИИ декомпозиция функций/процессов;анализ бизнес-событий; моделирование местоположений выполнения функций/процессов; модель интеграции функций/процессов.

ДЕКОМПОЗИЦИЯ БИЗНЕС- ПРОЦЕССОВ ДЕКОМПОЗИЦИЯ БИЗНЕС- ПРОЦЕССОВ Декомпозиция бизнес-процессов включает: идентификации подпроцессов, которые составляют основу выполнения бизнес- функций, определении границ основных организационных единиц определении вклада каждой функции в цепочку создания добавочной стоимости. Декомпозиция функций/процессов должна: задать границы анализа рассмотрением наиболее критически важных функций бизнеса; идентифицировать основные процессы, обеспечивающие выполнение функций организации; идентифицировать межфункциональные процессы, которые являются первоочередными кандидатами на инновации, связанные с применением информационных технологий; идентифицировать пересечения и излишние функции/процессы.

КОМПОНЕНТЫ ДЕКОМПОЗИЦИИ ФУНКЦИЙ/ПРОЦЕССОВ Основная область анализа Результаты (артефакты) анализа Основные вопросы Определить границы каждой бизнес-функции Понять состав подпроцессов каждой бизнес-функции Дать основу для увязывания архитектуры информации, приложений и технологической архитектуры с бизнес- функциями Подпроцессы основных бизнес-функций Идентификация излишних и малополезных, неэффективных активностей Требования к прикладным системам и информации Каковы основные функции организации? Какие функции не несут в себе ценности? Какие функции пересекаются с другими бизнес-функциями?

АНАЛИЗ БИЗНЕС-СОБЫТИЙ Анализ бизнес-событий позволяет понять, как инициируются бизнес-события (например, оформление заказа) и какие связанные с ними процессы происходят в цепочке создания добавочной стоимости предприятия, что включает контакты с клиентами и поставщиками. При анализе берется конкретное событие, документируется текущий процесс его обработки, и оцениваются возможности по его совершенствованию.

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

МОДЕЛЬ МЕСТОПОЛОЖЕНИЙ Модель местоположений идентифицирует в географическом плане то место, где выполняются функции бизнеса, и обеспечивает логистический взгляд на функции, выполняемые организацией. Одним из преимуществ использования этой модели является идентификация архитектурных требований, которые предъявляются, в частности, к технологической архитектуре с точки зрения обеспечения информационного взаимодействия между различными местами расположения бизнеса. Целью моделирования местоположений является визуализация организационных единиц, определение мест, где выполняются функции и связей между ними.

КОМПОНЕНТЫ МОДЕЛИ МЕСТОПОЛОЖЕНИЙ Основная область анализа Результаты (артефакты) анализа Основные вопросы Обеспечить понимание того, где выполняются функции и процессы Понимание требований, накладываемых географическим расположением на решения, касающиеся бизнес- и технологической архитектуры Понимание требований со стороны технологической архитектуры к географическому расположению функций Распределение функций по местоположениям Связи между бизнес- функциями Требования к технологической архитектуре и архитектуре прикладных систем Возможности по организационным изменениям Где выполняются основные функции? Какие функции связаны между собой? Существуют ли возможности по консолидации и рационализации?

МОДЕЛЬ ИНТЕГРАЦИИ Модель интеграции отражает высокоуровневые требования к интерфейсам между процессами и бизнес-событиями, требования, предъявляемые к информации новыми шаблонами процессов, и временные требования. Модель интеграции служит основой для построения архитектуры информации и архитектуры прикладных систем, а также содержит общие требования к архитектуре предприятия с точки зрения бизнес-информации и интеграции.

КОМПОНЕНТЫ МОДЕЛИ ИНТЕГРАЦИИ Основная область анализа Результаты (артефакты) анализа Основные вопросы Обеспечить понимание ключевых внутренних и внешних точек интеграции Информационные потоки между участниками бизнес-событий Понимание основных интерфейсов прикладных систем Понимание требований к технологической архитектуре с точки зрения интеграции Потоки информации, которые требуются для реализации различных шаблонов бизнес- процессов Связи между функциями бизнеса Требования к архитектуре информации, приложениям и технологической архитектуре Возможности для организационных изменений Какая информация является критической для новых шаблонов реализации бизнес- процессов? Какие потоки информации существуют между различными точками соединения моделей бизнес- событий? Каковы требования с точки зрения времени?

ПРИМЕРЫ АНАЛИЗА БИЗНЕС- АРХИТЕКТУРЫ Анализ цепочек создания добавочной стоимости (А нужно ли вообще выполнять этот шаг?) Динамическое моделирование (Как эта модель выполнения бизнес- функций будет себя вести при различных значениях на входе и доступных ресурсах, и как со временем будет меняться поведение процесса?) Анализ пересечений и непокрытых областей (Gap-overlap analysis) (Будет ли наша бизнес-архитектура иметь избыточные элементы, и есть ли в ней "пробелы"?) Соотнесение затрат с активностями (Activity-based costing) (На каких процессах, каналах продаж и заказчиках мы реально зарабатываем или теряем деньги?) Обучение (Как эти бизнес-процессы соотносятся с другими?) Общая стоимость владения (Сколько стоит этот процесс?) Возврат инвестиций (ROI) (Будет ли достигнут возврат инвестиций в данный бизнес-процесс и когда?)

ДРУГИЕ МЕТОДЫ АНАЛИЗА БИЗНЕС- АРХИТЕКТУРЫ Существуют другие инструменты и модели, для более глубокого и более технологичного моделирования бизнес-процессов. В частности, могут использоваться контекстные диаграммы, диаграммы информационных потоков, а также конструкции и возможности языка UML, такие как сценарии использования, диаграммы последовательности, диаграммы деятельности и др.

СЕРВИС-ОРИЕНТИРОВАННАЯ АРХИТЕКТУРА В связи с развитием принципов сервис-ориентированной архитектуры и появлением технологически нейтрального, платформенно-независимого языка описания и выполнения бизнес-процессов BPEL (Business Process Execution Language ) появилась возможность не только моделировать бизнес-процессы, но и делать их целиком или частично доступными другим системам и организациям в виде сервисов. К этому можно добавить также возможности еще одного стандарта XML Metadata Interchange (XMI) для обмена (экспорта/импорта) данных практически в любые интеграционные продукты. Это дает возможность создавать модели и репозитории бизнес- процессов для их эффективной интеграции. Подробная информация о новых стандартах для моделирования процессов можно найти на сайте