Литература:

• Статьи
• Обзоры
• Форумы
• Стандарты
• Книги
• Авторы

Автор: Кейт Свенсон (Keith Swenson)

Оригинал статьи: "Model Strategy: Preserving vs. Transforming"

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

И тот, и другой подход имеет своих приверженцев. И «религиозные войны» между ними ведутся постоянно. Но для потребителя, покупающего, в первую очередь, функционал, непонимание выбранной стратегии может привести к краху всей BPM-кампании.

Став участником подобного спора, Кейт Свенсон (Keith Swenson) решил внести ясность в этот вопрос, опубликовав сначала в своем блоге серию статей, которая была отражена в одном из  обзоров. Позже эти размышления,  вылились в статью «Стратегия моделирования: сохранение против преобразования».

 

Общий фундамент

Обе стратегии делают некоторые схожие предположения о процессе создания процесса. Давайте назовем процесс создания процесса «жизненным циклом бизнес-процесса». В мире BPM ничто не является статичным. Но надо понять, что динамика бывает, по крайней мере, трех различных видов, и помогут нам в этом следующие термины:

• Исполнение бизнес-процесса: бизнес-процесс сам по себе имеет динамическую составляющую, так как он движется от начала и до конца обработки одного «дела». Шаблон процесса здесь обычно не меняется, меняется только экземпляр процесса или контекст, сохраняющий состояние конкретного «дела».
• Жизненный цикл бизнес-процесса: это те изменения, которые происходят с бизнес-процессом от первоначальной концепции к  моделированию, интеграции и, наконец, к развертыванию в среде исполнения. 
• Усовершенствование бизнес-процесса: это изменения бизнес-процесса, которые происходят со временем, путем  многократного повторения жизненного цикла процесса, за которым следует анализ того, насколько хорошо работает очередная версия. Это TQM или концепция постоянного улучшения BPM.

По общему мнению, определение процесса проходит жизненный цикл, и при этом в него вовлекаются разные люди с различными специализациями. Первоначальная концепция бизнес-процесса, вероятно, будет исходить от владельца процесса чисто со стороны бизнеса. Еще там может быть «аналитик бизнес-процессов», который имеет представление о  самом бизнесе, а также имеет навыки, позволяющие смоделировать этот процесс. Также может быть «системный инженер», который выполняет работу по интеграции процесса с другими системами. Наконец, среда исполнения включает  администраторов и пользователей, которые взаимодействуют с запущенными процессами. Некоторые люди дают более сложные определения жизненного цикла, проходящего через четыре или больше разные специализации, и такие, безусловно, существуют, но для обсуждения мы будем придерживаться в первую очередь этих трех, которые без труда можно видеть сегодня.

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

Стратегия преобразования модели. Определение.

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

 

Аналитик бизнес-процесса разрабатывает высокоуровневую модель в сфере бизнеса. От этого представителя бизнеса или процессного аналитика не требуется вдобавок быть программистом. Высокоуровневая модель преобразовывается во что-то понятное для программиста. Это делается путем трансляции «бизнес-модели» в «системную модель»– либо добавлением узлов, управляющих интеграцией, либо путем преобразования диаграммы в совершенно новую диаграмму, отражающую взаимодействие системного уровня, которое должно иметь место, чтобы обеспечивалось взаимодействие на уровне бизнеса.

Стратегия преобразования модели следует давней традиции программирования и системной разработки. В области разработки программного обеспечения для визуального представления  модели верхнего уровня часто используется UML (Unified Modeling Language). Затем это представление должно быть переведено на язык программирования, например в C++. Подразумевается, что должно получиться то же самое, однако на деле форма существенно изменилась и не имеет никакого сходства с первоначальным UML. Можно сказать, что UML «уничтожен» и заменен другой формой. Значимые аспекты оригинала отражены и в новой форме, однако совершенно по-другому. Часто трансформация происходит «с потерями», т.е. в преобразованную версию попадает не все. Возможно, что преобразованная версия и не нуждается в этих аспектах. К примеру, когда С++ преобразуется в машинный код, то имена переменных теряются, т.к. машинный код в них не нуждается. Такой вид трансформации – установившаяся практика в мире разработки ПО.

Возвращаясь к примеру BPM: бизнес-аналитик может переложить  действия, описывающие рецензирование документа, на язык бизнеса. Они будут преобразованы в: действие, которое посылает кому-то e-mail; действие, выбирающее документ из репозитория; действие, посылающее напоминание, если ответ запаздывает, и действие, ожидающее ответа. Программист может расширить это представление, добавив обозначения управления исключениями и другие прерывания, которые не включает бизнес-аналитик. В последствии это представление снова может быть преобразовано для получения исполняемого кода.

 Привыкнув к такому подходу, легко представить, почему для экспертов в разработке ПО BPM – это всего лишь еще один перевод модели верхнего уровня в исполняемый код. Здравый смысл призывает основываться на успешном опыте прошлого, и это особенно сильно поддерживается вендорами, которые поддерживают стратегию преобразования модели.

Стратегия сохранения модели. Определение.

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

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

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

На третьем шаге модель инсталлируется в исполняющий движок, снова без какого-либо преобразования. Количество узлов действий в движке в точности такое, как нарисовал бизнес-аналитик. Связи между ними в точности те же, что нарисовал бизнес-аналитик. Это принцип «что нарисовали, то и исполняем» («What You Draw is What You Execute», WYDIWYE)).

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

Анализ

Разные BPM-продукты можно разделить на две категории: поддерживающие «стратегию преобразования модели» или «стратегию сохранения модели». Какая из них лучше? Те, кто внимательно читает мой блог, уже знают, что ответ зависит от того, что вы собираетесь делать. Это зависит от типа бизнес-процессов, которые вы реализуете.

 Что мы можем сделать, так это сравнить эти две стратегии в их способности поддерживать следующие семь измерений:

• Поддержка «Round-Trip» (движение в оба конца)
• Управление проблемными ситуациями во время исполнения
• Полезность аналитических данных
• Возможность имитировать и оптимизировать процесс
• Простота использования для программистов
• Гибкая и итеративная разработка
• Видимость состояния исполнения

Исходя из этого далее, мы выясним, в каких ситуациях будет хороша одна стратегия и в каких ситуациях будет хороша другая.

Мы часто говорим о «round trip». Жизненный цикл – это, в основном, прохождение процесса через разных людей с различными специализациями. Бизнес-аналитик рисует модель верхнего уровня, системный интегратор добавляет детали для связи с системами. Другая динамика заключается в постоянном совершенствовании процесса, которое происходит тогда, когда вы оцениваете, насколько эффективен текущий процесс, делаете изменения на верхнем уровне и снова проводите эти изменения через весь жизненный цикл.

 В предыдущей заметке я ввел понятие «стратегия сохранения модели» против «стратегии преобразования модели» и определял их как два подхода, которыми BPM-системы могут поддерживать жизненный цикл бизнес-процесса.

Вы не хотите, чтобы программист начинал интеграцию с нуля из-за того, что вы сделали небольшое изменение в верхнем уровне. Round-trip – это идея того, что все изменения, которые программист делает во время интеграции, каким-то образом переносятся в первоначальную модель. Если вы делаете именно так, то аналитик может вносить небольшие изменения, и программисту останется только сделать небольшие, связанные с этим изменения.

Round-trip применительно к стратегии преобразования модели

Стратегия преобразования модели представляет собой серьезное затруднение для эффективного round-trip. При переходе из бизнес-области в системную область некоторые аспекты модели, которые не нужны для интеграции или ввода, обычно опускаются. Затем с этого состояния системный инженер начинает изменять модель. Когда он это сделает, не всегда ясно, как эти изменения должны вписываться в исходную бизнес-модель.

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

 Второй подход, позволяющий обеспечить round-trip,– это присвоить идентификационные номера создаваемым элементам, которые будут указывать, из какой части бизнес-модели они пришли. Бизнес-модель остается у бизнес-аналитика. Позже измененная модель из области интеграции может быть ре-импортирована в связанную бизнес-модель. Если во время импорта находятся соответствующие идентификаторы, то информация об интеграции присоединяется таким образом, чтобы она в любое время могла быть  повторно экспортирована.

Хотя это и является серьезным испытанием, но в стратегии преобразования модели возможно поддерживать round-trip, даже если они модель преобразовывается в другую форму.

Round-Trip применительно к стратегии сохранения модели

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

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

Agile-разработка зависит от Round-Trip

«Agile BPM Development»  означает не только реализовывать быстро, но и реализовывать итеративно. Agile метод состоит в том, чтобы реализовать часть решения, попробовать, что получилось,  возможно, измерить, насколько хорошо это работает, реализовать еще немного, снова попробовать и т.д. Делается множество небольших изменений, каждое изменение осуществляется и выпускается в очень короткое время. Каждый цикл начинается с результатов предыдущего цикла. Таким образом можно избежать множества переделок в каждом цикле.

Возможность поддержки round-trip прямо пропорциональна возможности поддержки Agile. Любое ограничение в переносе интеграционных изменений обратно в бизнес-область добавляет значительные усилия на каждом цикле, т.к. часть работы по интеграции придется делать заново. Чем больше работ требуется для выполнения итерации, тем меньше чистой прибыли вы получите от небольших изменений. Чтобы избежать потерь, организация в этом случае будет дольше ожидать и накапливать изменения перед выполнением итерации.

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

Заключение

Если вы беспокоитесь о сильном round-trip и применении Agile разработки, то стратегия сохранения модели явно выигрывает. Поскольку нет преобразований между областями, нет барьеров, препятствующих бизнес-аналитикам и системным интеграторам передавать процесс туда и обратно столько раз, сколько они захотят. Нет ничего невозможного в том, чтобы обеспечить round-trip и в трансформируемых моделях, и некоторые существующие системы предлагают полный round-trip, но это требует тщательной проверки. И даже если round-trip поддерживается, тот факт, что вам необходимо делать явные преобразования между областями, становится препятствием к эффективной совместной работе аналитиков и интеграторов.

В предыдущей заметке я ввел понятие «стратегия сохранения модели» в противовес «стратегии преобразования модели» и определил их как два подхода, которыми BPM-системы могут поддерживать жизненный цикл бизнес-процесса. Затем я описал несколько ситуаций, когда стратегия сохранения модели является лучшим выбором. Но это не всегда лучший выбор. Эта заметка посвящена тем ситуациям, когда стратегия трансформации модели показывает себя наилучшим образом.

Основная причина преобразования модели в другую форму – это реализация улучшений.

Преобразование для исполнения

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

Альтернативой компиляции программ в машинный код является интерпретатор.  На ум приходят такие интерпретирующие языки, как LISP, PERL, PHP, Ruby и JavaScript. Иногда компилятор, действующий по принципу «точно вовремя», используется для компиляции кода непосредственно перед его исполнением, но окружение делает его прозрачным таким образом, что преобразованную версию никогда никто не видит. Java – это язык, который компилирует промежуточную форму, которая затем интерпретируется. Компромисс между использованием языка компилятора или интерпретатора является предметом многочисленных дискуссий, и по-прежнему зависит от того, какая производительность вам необходима. Ядро сервера баз данных – компонента,  критичная с точки зрения производительности, и однозначно требующая оптимизированного языка. Многие среды разработки веб-приложений используют языки-интерпретаторы, поскольку производительность процессоров – не такой критичный аспект для этих типов приложений.

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

Преобразование для разработчика

Другая причина преобразовывать модель – это приведение ее к форме, удобной для системного интегратора. Если у вас в штате есть Java-разработчики, то преобразование BPMN-модели в Java позволит разработчикам быть более эффективными с меньшим обучением, чем если бы они были вынуждены обучаться работать в рамках BPMN.

Вовсе не обязательно уходить от BPMN в язык программирования. Мой пост «Процессы, координируемые людьми» иллюстрирует преобразование из BPMN в BPMN. Разница в том, что модели бизнес-области была BPMN-диаграммой, представляющей поток передачи ответственности, тогда как модель системной области была BPMN-представлением потока данных.

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

Стратегия сохранения модели

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

Как решить

Если у вас есть BPM проект, содержащий много работы по интегрированию систем и сравнительно мало работы в бизнес-области, и низкая вероятность того, что понадобится развивать бизнес-модель с течением времени, то стратегия преобразования модели позволит вам оптимизировать использование системных инженеров. Они могут работать привычным способом, используя имеющиеся инструменты и навыки.

Если вы ожидаете большой скорости обработки транзакций, возможно вам придется рассматривать стратегию преобразования модели для более высокой производительности. Насколько велика значимость? Начните с подсчета количества случаев в месяц, умножьте на количество действий по каждому случаю в среднем, затем разделите на количество часов в месяце, чтобы найти примерное количество выполняемых действий за час. Если эта работа превосходит 1 миллион исполняемых действий за час, то вам следует осторожно относиться к вопросу о необходимости подхода с использованием компиляции. Если ожидаемое количество исполняемых действий меньше 10 тысяч в час, то не будет проблем и с использованием интерпретатора, даже на очень скромном сервере. Это лишь приблизительные цифры, и в этом промежутке вам придется также учитывать особенности применения и тип охватываемых транзакций.  Стоит отметить, что многие критичные с точки зрения бизнеса процессы предполагают менее 10 тысяч выполняемых действий в час и вопрос о производительности просто не встает.

Люди, разбирающиеся в производительности, знают, что программы проводят большую часть времени в 5% кода. Если вы можете оптимизировать эти 5% кода, вы сможете зачастую достичь 99% от производительности оптимизации всего кода.  Это объясняет, почему интерпретированные BPM-диаграммы, работающие на верхнем уровне через вызов функций, которые сами по себе оптимизированы,  часто исполняются почти так же быстро, как скомпилированные программы. Таким образом, общая производительность меньше зависит от того, скомпилирован код или нет, а больше зависит от того, насколько поддерживаемая функциональность отвечает требованиям.

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

Вывод

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

Комментарии