Прекращайте копировать, начинайте связывать

Следующее поколение управления моделями

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

Клаус Торп Дженсен, старший технический сотрудник, IBM

Клаус Торп Дженсен (Claus Torp Jensen) - фотографияКлаус Торп Дженсен (Claus Torp Jensen) является старшим техническим сотрудником и главным архитектором SOA-BPM-EA Technical Strategy в IBM, Сомерс, Нью-Йорк. Он входит в группу IBM SOA Foundation, работающую над конвергенцией различных архитектурных дисциплин. Клаус является членом WebSphere Foundation Architecture Board.

До прихода в IBM он десять лет был главным архитектором и пропагандистом SOA.



Жасмин Басраи, старший менеджер по продукции, IBM

Жасмин Басраи (Jasmine Basrai) - фотографияЖасмин Басраи (Jasmine Basrai) более 5 лет является старшим менеджером по продуктам WebSphere BPM. В сферу ее интересов входят бизнес-моделирование, мониторинг и BPM интерфейсы конечного пользователя. Она пришла в IBM из HOLOSOFX, где была директором службы консалтинга и руководила многими успешными внедрениями BPM. Имеет более 11 лет опыта работы в области BPM и является активным пропагандистом более тесного взаимодействия бизнес-пользователей при разработке BPM решений.



Пабло Ирассар, старший технический сотрудник, IBM

Пабло Ирассар (Pablo Irassar) - фотографияПабло Ирассар (Pablo Irassar) работает старшим техническим сотрудником в AIM Division, IBM Software Group, Торонто, Онтарио. Он является членом специальной группы WebSphere BPM Advanced Customer Deployments.



22.08.2011

Обзор

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

С аналогичной проблемой в самом начале столкнулся Интернет, поэтому пионеры Web выбрали совершенно другой подход к достижению видимости и трассируемости. Современна всемирная паутина основана на идее связывания различных видов страниц посредством облегченных стандартизированных HTTP-ссылок и принимает как данность факт периодической неработоспособности таких ссылок, что является платой за возможность избежать накладных расходов на копирование или негибкости глобального репозитория.

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


Введение

С распространением управляемых моделями технологий и дисциплин, таких как сервис-ориентированная архитектура (service-oriented architecture — SOA), управление бизнес-процессами (business process management — BPM), управление информацией (information management – IM) и корпоративная архитектура (enterprise architecture — EA), многие организации сталкиваются с проблемой управления растущим числом артефактов моделей в различных областях и ролях. Артефакты модели могут иметь родственные связи, прямые зависимости или даже быть различными представлениями и точками зрения того, что является, по существу, одной и той же системой. Зачастую связи артефактов модели разрешаются путем копирования или преобразования самих моделей для потребления в различных инструментах или областях. Результатом такого подхода являются потенциально большие объемы переделок и необходимость постоянной синхронизации между средами и инструментами. Что еще хуже, подход, основанный на копировании, размывает границы собственности и пренебрегает тем, что разные виды артефактов модели имеют различные жизненные циклы.

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


Прекращайте копировать

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

  • Двухточечная закрытая интеграция.
  • Потеря информации в процессе преобразования или концептуальные несоответствия.
  • Отсутствие видимости за пределы области.
  • Управление изменениями становится сложным или невозможным, потому что не ясно, кто владеет правом на истину.
  • Отсутствие поддержки управления жизненным циклом артефакта.

Внедряемые отраслевые стандарты, такие как BPMN2.0 и SoaML, включают в себя квазинормативные рекомендации, которые уменьшают необходимость преобразований и закрытой интеграции. Однако форматы стандартов не способствуют решению проблем управляемости; единственный способ по-настоящему решить эти проблемы — прекратить копирование артефактов. Суть проблемы в том, что при копировании артефакта вы сразу получаете две точные копии одного и того же. Это малозаметное, но существенное отличие от клонирования артефакта во что-то родственное, но все-таки индивидуальное. Следующие примеры призваны прояснить различие:

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

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

Во втором случае (клонирование), даже будучи изначально абсолютно похожим на оригинал (или, возможно, на его преобразование), клон имеет собственные идентичность и жизненный цикл, не зависящие от оригинала. Ведь даже изменение модели процесса в конкретном решении не означает в большинстве случаев изменения корпоративного стандарта. Вместе с тем важно сохранять связь клона с его оригиналом для поддержки видимости, трассируемости и возможности совместной работы. Обратитесь к статье Постоянное совершенствование вместе с BPM и EA (Клаус Т. Дженсен, developerWorks, 2010 год), чтобы получить дополнительную информацию об этом принципе совместной работы (EN).

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


Начинайте связывать

Что бы ни было избрано в данной ситуации - простая ссылка или клонирование - в обоих случаях необходим стандартизированный, не зависящий от инструмента способ связывания через границы областей моделирования. Такое стандартизированное связывание является одной из проблем, которой занимается инициатива Open Services for Lifecycle Collaboration (OSLC):

  • Ссылки должны быть прозрачными.
  • Ссылки должны иметь двунаправленную видимость.
  • Ссылки должны быть чувствительны к версиям.
  • Ссылки должны быть устойчивы к изменениям.

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

Рисунок 1. Связывание в интернет-стиле
Рисунок 1. Связывание в интернет-стиле

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

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

В последнее время отрасль уделяет много внимания выполнению динамичных изменений, но приобретать быстроту адаптации к новым условиям за счет управляемости не слишком разумно. Фактически важнейшей задачей современного предприятия должно быть непрерывное улучшение бизнеса посредством совместного комплексного планирования и доставки процессов по всему предприятию. Комбинация планирования и доставки — это именно то, чем силен подход связывания, так как он позволяет не нарушать жизненные циклы, границы областей и права собственности, но обеспечивает глобальную видимость и сотрудничество. Прочтите статью Использование SOA, BPM и EA для стратегического согласования бизнеса и ИТ (Клаус Т. Дженсен и другие, developerWorks 2008 год), в которой говорится о том, как связать BPM и EA для получения лучших бизнес-результатов. На рисунке 2 показан пример того, как можно связать BPM и EA (EN).

Рисунок 2. Эффективное взаимодействие BPM и ЕА посредством гибкого связывания
Рисунок 2. Эффективное взаимодействие BPM и ЕА посредством гибкого связывания

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

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


Заключение

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

Классический подход к междоменному сотрудничеству посредством копирования (exchange-by-copy) недостаточно хорошо масштабируется в больших управляемых моделями предприятиях. В лучшем случае его результатом является непереносимая и сложная в поддержке архитектура модели, а в худшем — разногласия и нескоординированные усилия, что значительно затрудняет развитие культуры моделирования. Эффективное сотрудничество между областями моделирования на основе надежных в обслуживании архитектур модели будет ключевым индикатором успешности предприятий в их стремлении к постоянной эффективности бизнеса и оптимизации услуг. Для этого предприятия должны перестать копировать и начать связывать.

Ресурсы

  • Оригинал статьи: Stop copying, start linking (EN).
  • Постоянное совершенствование вместе с BPM и EA (Клаус Т. Дженсен, developerWorks, 2010 год). В этой статье описываются принципы синхронизации и межкомпонентного соединения BPM и EA с точки зрения бизнеса. Статья предназначена для руководителей и архитекторов, которым необходимо понимание того, как эффективно объединить BPM и EA в ключевой инструмент достижения успеха предприятия в процессе постоянного совершенствования бизнеса (EN).
  • Достижение динамичности бизнеса вместе с BPM и SOA — интеллектуальная работа на интеллектуальном предприятии (Клаус Т. Дженсен, Роб Хай младший, Стив Миллс, 2009 год). В этом документе описываются принципы сближения BPM и SOA. Хотя BPM и SOA имеют самостоятельное значение, IBM считает, что они по своей природе являются синергетическими, т.е. их совместное использование дает дополнительный эффект с точки зрения динамичности, оптимизации и согласования бизнеса и ИТ. При совместном использовании BPM предоставляет бизнес-контекст, понимание и систему показателей, а SOA предоставляет управляемую библиотеку хорошо спроектированных сервисов и информационные строительные блоки. Обе эти составляющие, по сути, необходимы, чтобы динамически оптимизировать инвестиции, поддерживать высокие стандарты ведения бизнеса и управлять бизнес-рисками. Узнайте, как эффективно объединить BPM и EA в ключевой инструмент достижения динамичности бизнеса на вашем предприятии (EN).
  • BPM и SOA необходимы надежные и масштабируемые информационные системы интеллектуальная работа на интеллектуальном предприятии (Клаус Т. Дженсен, Роб Хай младший, Стив Миллс, 2009 год). В этом документе описываются принципы конвергенции BPM и SOA с точки зрения информационных систем. Если BPM и SOA правильно объединены с точки зрения информационных систем, то высокие стандарты ведения бизнеса, обеспечиваемые BPM, в значительной степени опираются на горизонтальную обработку транзакций и масштабирование, свойственные SOA. Конечным результатом использования этой внутренней способности к эффективной кооперации является надежная, непротиворечивая и управляемая сеть взаимодействующих и взаимозависимых людей, процессов, сервисов и источников информации. Статья предназначена для ИТ-руководителей и архитекторов, которым необходимо понимание того, как эффективно объединить BPM и EA для обеспечения соблюдения целостности и высоких стандартов ведения бизнеса (EN).
  • Использование SOA, BPM и EA для стратегического согласования бизнеса и ИТ (Клаус Т. Дженсен и другие, developerWorks, 2008 год). На современных предприятиях согласование бизнеса и ИТ является жизненно необходимым фактором поддержки динамичности и преобразования бизнеса. Этой цели можно достичь путем совместного применения SOA, BPM и ЕА в синергетическом стиле. Данный документ описывает основные принципы архитектуры и жизненного цикла, позволяющие достичь подобной архитектурной конвергенции, а также предлагает ряд шаблонов в зависимости от потребностей и зрелости организации (EN).
  • Практическое значение бизнес-архитектуры (PDF) (EN) (Рэй Харишанкар, Керри Холли и другие, 2010 год). Эта статья отвечает на вопрос о том, в чем состоит практическое значение бизнес-архитектуры. В ней обсуждаются три конкретные точки зрения: стратегия и преобразование (strategy and transformation — S T), управление бизнес-процессами (business process management — BPM) и сервис-ориентированная архитектура (service-oriented architecture — SOA).
  • Open Services for Lifecycle Collaboration: присоединяйтесь к сообществу OSLC для получения дополнительной информации об этой инициативе.
  • Object Management Group Business Process Management Initiative: спецификация BPMN 2.0, статьи и многое другое.
  • Service oriented architecture Modeling Language (SoaML): спецификация SoaML и другая информация.
  • Раздел BPM на developerWorks: новейшие технические ресурсы по BPM-решениям IBM, в том числе материалы для загрузки, демонстрации, статьи, руководства, события, web-трансляции и многое другое.

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=WebSphere, SOA и web-сервисы
ArticleID=753426
ArticleTitle=Прекращайте копировать, начинайте связывать
publish-date=08222011