Все що ви хотіли дізнатися про BPM, але боялися запитати

У мережі є безліч публікацій про те, заради чого варто впровадити BPM у вашій компанії. Як зазвичай формулюються переваги, які дає бізнесу впровадження BPM:
  1. Візуальне моделювання та виконання бізнес-процесів.
  2. Набір готових компонент для побудови гнучких бізнес-процесів.
  3. Взаємодія з користувачем для виконання ручних дій.
  4. Гнучкість конфігурації бізнес-процесів.
  5. Підтримка версійності бізнес-процесів.
Це не все, що можна згадати, але досить типовий набір переваг платформи.

Чи насправді все так безхмарно? Не пора всім викинути старі інструменти, і повністю перейти на нову платформу?



Я хотів би розповісти про те, які проблеми можуть вас очікувати в процесі впровадження, а точніше — при розробці реальних програм. Мої враження засновані на досвіді роботи з платформою IBM Websphere BPM, для визначеності — з версіями 7.5 по 8.5 включно.

Розглянемо перераховані раніше пункти по порядку.

Візуальне моделювання
Чого ми намагаємося досягти? Щоб аналітики, або навіть бізнес-користувачі могли намалювати діаграму процесу, яка потім буде виконана рівно в такому ж вигляді сервером. Або хоча б могли розуміти суть процесу, глянувши на діаграму, намальовану кимось іншим.

Ми отримуємо те, чого хотіли добитися? Швидше ні, ніж так.

В чому тут корінь проблеми? Я б сказав, що їх два:
  1. Пропоновані мови моделювання процесів занадто примітивні для реальних завдань, і потрібні інші мови, щоб створити реально робочий процес.
  2. Мова у вигляді діаграм, начебто BPMN, погано вписується в типовий цикл разработаки програм.


Справа в тому, що процес, який виконується в рамках BPM системи, майже ніколи не зводиться тільки до діаграми, яку бачить бізнес-користувач або аналітик. До неї додається ще безліч подробиць, що розташовані на різному рівні деталізації, які так чи інакше визначають поведінку процесу. Це, наприклад, дані, що супроводжують примірник процесу, або інтеграція процесу з іншими існуючими системами. Всі ці подробиці як правило зводяться до коду на іншій мові програмування.

Практика показує, що без цих складових процес практично марний, і в теж час, вони на типової BPMN діаграма не видно.

З іншого боку, бізнес-процеси — це програмне забезпечення, нехай і дещо незвичайне. Процеси мають мати достатньо довгий цикл розробки і супроводу, причому зручність супроводу досить швидко стають важливим. Також, дуже важливим є управління змінами в додатку взагалі, причому в тісному зв'язку з так званими issue tracking системами (наприклад, JIRA). Тобто, нам потрібно знати, хто, коли, які саме і навіщо вносив зміни в процес, і в рамках яких завдань.

Таким чином, з одного боку, у бізнес-користувачів створюється швидше помилкове враження, що вони розуміють логіку процесу, частина якої від них прихована в коді. З точки ж зору розробників подання у вигляді діаграми лише ускладнює розробку, в першу чергу тому, що діаграми погано узгоджуються з життєвим циклом розробки, в тому числі — з управлінням змінами.

Інструментарій

Тепер про поговоримо про методи і інструменти для розробника.

Якщо для традиційних засобів розробки більш-менш придумані засоби (наприклад, рефакторінгу), показники і методики вимірювання, які дозволяють оцінювати розміри проекту (у рядках коду, зазвичай), і такі фактори, як покриття тестами, число потенційних помилок на одиницю коду, складність коду, і багато іншого, то при переході до BPM про багато що з цього можна забути. У всякому разі, мені невідомі якісь роботи в цьому напрямку. Це в якомусь сенсі відкидає розробку на багато років назад. Потрібно заново вчитися рефакторіть, збирати статистику по проектам, і вчитися оцінювати їх складність і розміри, щоб правильно планувати розробку.

Так, інструменти для аналізу коду та автоматичного рефакторінгу, на практиці не існують. Найгірше те, що саме створення таких інструментів під великим питанням. Уявимо собі достатньо типовий сценарій розробки на більш традиційної платформі. У вас є система версионирования, скажімо SVN або Git, є середовище розробки (IDE), і є інші інструменти. Так ось, якщо ваша улюблена IDE чогось не вміє, ви можете, як правило, або розробити для неї розширення, або застосувати сторонні інструменти безпосередньо для роботи з кодом. Наприклад, copy&paste детектор, або будь-який інший інструмент, безліч прикладів яких відомо нам з моменту появи UNIX. Це стало можливим тому, що код вашої програми традиційно є просто текстом. Ви можете скористатися будь-яким інструментом, і перенести змінений код назад в Git, або просто зібрати потрібну статистику, провести аналіз коду, і т. п.

У разі BPM такий підхід вам недоступний, або сильно обмежений. Можна автоматизувати багато рутинних операцій, і не завжди є доступ для розробки сторонніх інструментів автоматизації. Доступ до коду процесу хоча і можливий, але швидше теоретично — ви можете експортувати процес у вигляді набору схем BPMN, і застосувати різні інструменти для аналізу коду — за умови, що самі їх і розробите.

У підсумку така тривіальна на традиційних платформах завдання, як однакове зміна властивостей множини елементів діаграми процесу замість чогось на зразок Find&Replace виливається в нудну рутинну роботу, яку можна зробити тільки руками, і яка змушує вас ненавидіти цей інструмент вже через п'ять хвилин.

Ну і останнє, але не за важливістю. Якщо для більш традиційних проектів ви вмієте оцінювати розміри створюваного додатка (в рядках коду, наприклад), неформально, або згідно з будь-якої моделі типу CoCoMo, то в разі BPM ви опиняєтеся в незрозумілій ситуації. У вас мінімум два види коду — діаграми, і «звичайний» мова програмування, можливо навіть не один. Скільки часу потрібно, щоб намалювати діаграму процесу? Від чого це залежить? В чому вимірювати розмір і складність діаграм? І якщо для звичайного коду ви можете застосувати відомі моделі для оцінки трудомісткості, то для діаграм подібні моделі не побудовані і питання не мають відповідей.

Набір готових компонент і повторне використання

Деякі потрібні компоненти для побудови процесів: умови, паралельні гілки, очікування, події звичайно ж є. Тільки от їх рівень є досить низьким, а можливості комбінування, і в результаті повторного використання готових компонент, залишають бажати багато кращого.

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

Спробуйте, для прикладу, організувати у процесі цикл, користуючись тільки стандартним набором засобів. Ви ніби повернетесь у часи, коли в книгах по програмуванню ще малювали блок-схеми — тобто, років 40 тому. Інший вельми типовий, але далеко не тривіальний випадок — коли вам потрібно організувати асинхронне взаємодія з зовнішнім для вас сервісом, тобто відправити запит, і потім дочекатися відповіді. Навіть якщо потрібну вам логіку ви можете реалізувати — у вас навряд чи вийде використовувати її повторно в іншому схожому процесі, тому що реалізація буде розкидана по додатку таким чином, що виділити повторно використовуваний компонент виявиться неможливим. Причому корінь зла в даному випадку тривіальний і лежить на поверхні: BPMN не містить того, що називається «функції вищого порядку», якщо говорити термінами ФП. Або узагальнення, якщо згадати ООП і Java. Ви не можете написати узагальнений компонент, наприклад, для сортування, абстрагуючись від типу елемента списку. Ви не можете передавати функції (активні компоненти) як параметри. Тут немає способу описати метакомпонент, якщо можна собі дозволити його так назвати.

На сьогодні дві парадигми у вигляді функціонального програмування ООП можна вважати переважаючими. У випадку ж з BPM таких розробок немає, і поточний стан теорії прямо скажемо, плачевний. Фактично, немає навіть самої парадигми — є лише деякі практики, які лише з обмеженнями можуть бути рекомендовані до застосування. Більш того, якщо скажемо функціональне програмування базується на математиці, і в деяких випадках правильність програми може бути доведена формально, а у разі ООП та процедурного програмування іноді можна довести правильність хоча б частково, у разі BPM я не чув про подібні роботи.

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

При цьому, оскільки процес часто є набором паралельних активностей, і не може бути виконаний поза системи BPM, написання тестів також є завданням на сьогодні не вирішеним. Наявні для цього кошти не можна вважати адекватними, при тому що на сьогодні тестувати можна тільки сервіси — тобто синхронні компоненти процесу, для тестування же самих процесів як BPMN-діаграм (особливо з паралелізмом) автору ніякі засоби не відомі (хоча вони можуть бути розроблені, наявних API для цього достатньо, але це непросте завдання).

Підтримка версійності процесу

Всі програми розвиваються. Якщо програма не розвивається — це швидше за все нікому не потрібна програма. Винятки бувають, але вони дуже рідкісні. Це означає, що BPM процес може і повинен розвиватися, і проходити через кілька версій. Ці зміни потрібно відстежувати. Іноді ми розвиваємо дві гілки програми — скажімо, багфикс для версії 1, і нову версію 2. Іноді потрібно зливати зміни в них в одну версію.

Чому у випадку з BPM все це виходить погано?

По-перше, зміни погано доступні для огляду. Вихідним видом діаграми є не текст, а картинка. Квадратики, стрілочки, ромбики. І в порівнянні зі звичайним кодом у вигляді тексту, який як правило одновимірний, і для якого давно визначені всякі операції типу diff/merge/patch та ін., тут додається кілька нових вимірів. Наприклад, колір розмальовки квадратиків, або їх взаємне розташування на аркуші. Ви отримуєте значний рівень інформаційного шуму, просто тому, що частина змін діаграми рівним рахунком не впливає ніяк на її роботу.

У підсумку, у нас немає такої простої і очевидної можливості, яку з часів unix прийнято називати словом diff. Ви не можете просто і автоматично порівняти дві різні версії процесу між собою, на різних рівнях подробиці (тобто додаток, діаграма процесу, компонент, частина діаграми, рядок коду на якому-небудь мовою).

В кращому разі ви знаєте, що такого-то числа такого-то користувач змінив якийсь діаграму. Що саме, навіщо, і в чому, власне, полягала зміна — ви дізнатися не можете, або це важко. Все що є — це можливість відкрити (для читання), і подивитися, як виглядала конкретна версія. При цьому даний процес зовсім не швидкий. І найсуттєвіше — ви не бачите різницю, ви бачите або одну, або іншу версію коду. Порівнювати і розуміти, де є відмінності — це ваше завдання, і вона виявляється зовсім нетривіальним.

І друга звична можливість — це merge або хоча б patch. Вона також відсутня де-факто. Ви не можете перенести зміни з однієї гілки на іншу, з однієї версії до іншої, в тому числі — вибірково, зберігши зміни, внесені в обох гілках. Практично це позбавляє гілки будь-якого сенсу. З тієї ж причини, якщо якась зміна було збережено і потрапило в Tip відкотити його назад можна тільки на рівні великого компонента (сервісу), ймовірно втративши при цьому інші, корисні зміни.
Таким чином, ті кошти порівняння і злиття, які є, явно недостатні.

Відповідно, коли ми говоримо про гнучкості бізнес-процесів — ми завжди повинні мати на увазі тільки що розглянуту проблему. Ми можемо змінювати процес як завгодно гнучко — але ми дуже рідко при цьому будемо точно знати, що конкретно змінилося. І коли щось зламається — пошуки причини можуть вилитися в тривалі розкопки в коді.

Отже, коротко підсумую ще раз деякі проблеми:
  • Візуальне моделювання та виконання бізнес-процесів — частково. Модель не відображає реальності для аналітика, і незручна для розробника.
  • Набір готових компонент для побудови гнучких бізнес-процесів — ні. Засоби створення компонентів неадекватні.
  • Підтримка версійності бізнес-процесів — частково. Кошти неадекватні.


Іншими словами, бізнес-процеси у вигляді діаграм, BPMN, є досить гнучкими і простими в розумінні скажімо для аналітиків, але при цьому діаграми досить обмежені як засіб розробки.

А що в інших?

Так склалося, що в поточному проекті мені довелося зіткнутися з дуже подібним продуктом. Це MS Business Intelligence Development Studio, і те, що в ній розробляють — System Integration Services. І ось що дуже характерно — це зовсім інший продукт, зроблений іншою компанією для інших завдань, намагається в чомусь досягти тих же цілей, і стикається рівно з тими ж проблемами.

  • Візуальне моделювання ETL процесів відносно добре працює, поки пишеш їх з нуля. Як тільки намагаєшся перейти від версії до версії знайомі проблеми, такі ж як і у BPMN.
  • Також погано з пошуком і навігацією в межах проекту.
  • Створення повторно використовуваних компонентів у такому ж зародковому стані. Переиспользование — близько до нуля.
  • Все погано з рефакторінгом, із застосуванням сторонніх інструментів для роботи над проектом.


Який висновок я для себе зробив — думаю цілком зрозуміло. Буду триматися подалі від подібних інструментів, по мірі можливості. Якщо ж у вас склалися інші враження про практичній роботі з BPM, або скажімо SSIS, я пропоную розповісти про них в коментарях, і сподіваюся, що обговорення буде нам все корисно.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.