Главное не результат, главное процесс

BPM-блог Анатолия Белайчука

Сторонний инструментарий для BPMS

Я часто использую аналогию между системами управления базами данных (DBMS) и бизнес-процессами (BPMS):

  1. Когда-то давным-давно компьютерные программы состояли из одних алгоритмов.
  2. Потом в какой-то момент выяснилось, что алгоритмы и данные - это разные сущности. Профессор Вирт написал свою знаменитую книгу “Алгоритмы и структуры данных”, и появилось понимание, что для работы с данными нужен специальный инструментарий. Возник новый класс программного обеспечения под названием DBMS.
  3. Аналогичным образом, в какой-то момент появилось понимание того, что процесс лучше не сводить к алгоритмам или данным, а рассматривать как самостоятельную сущность, требующую специального инструментария. Так появились BPMS.

Теперь вспомним, как прогрессировали пользовательские интерфейсы к базам данных:

  1. Вначале каждая DBMS поставлялась со своим собственным инструментарием. Например, Informix 4GL для СУБД Informix или Oracle Forms для СУБД Oracle.
  2. Затем стали появляться универсальные инструменты, позволяющие работать с различными СУБД. Например, в 80-е Unify создал Accell 4GL, функционально очень близкий с Informix 4GL и Oracle Forms, но отличавшийся от них тем, что мог работать и с собственной СУБД Unify, и со всеми ведущими на тот момент СУБД: Informix, Oracle, Sybase. На этом этапе универсальность достигалась просто: поставщик встраивал в свой продукт поддержку той или иной СУБД. Преимущество, которое получал клиент: с таким инструментарием он мог безболезненно сменить СУБД. И это не абстракция: так, Сбербанк в свое время смог сменить СУБД Unify на Oracle, безболезненно перенеся миллионы строк кодов, написанных на Accell. Причем если бы даже Сбербанк сразу сделал ставку на Oracle, то и в этом случае у него были бы сейчас серьезные проблемы, так как, в отличие от Unify, который продолжает исправно выпускать для Accell новые версии, Oracle прикрыл Forms. (Повторяю, речь идет о прикладной системе масштабом многих миллионов строк исходного кода.)
  3. В конце концов появился поставщик инструментария настолько мощный, что он сумел заставить поставщиков СУБД стандартизировать программные интерфейсы: Microsoft предложил ODBC. Потом JDBC пошел уже по накатанной дорожке. Поставщикам СУБД пришлось на это пойти, чтобы не оказаться на обочине, но они делают все, чтобы их собственные проприетарные интерфейсы оставались более быстрыми или предоставляли доступ к нестандартным расширениям данной конкретной СУБД. Поэтому не является чем-то необычным инструментарий, который поддерживает, скажем, Oracle и MS-SQL по их собственным протоколам, а всех остальных - по ODBC.

Хотя Microsoft Studio и Oracle JDeveloper достаточно популярны, множество приложений для СУБД от Microsoft и Oracle разрабатывается не на них, а на Delphi, PHP и бог знает чем еще. Так что большинство прикладных разработчиков предпочитает вариант 3.

Как же обстоит дело с интерфейсами к BPMS? Очевидно, они сейчас находятся на шаге 1, и это печально.

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

Поэтому хочется видеть инструментарий для разработки интерфейсных форм от третьих фирм, который поддерживал бы несколько ведущих BPMS. Желательно от фирмы, имеющей опыт создания средств разработки.

Пусть для начала продукт следует варианту 2, т.е. работающий через адаптеры к конкретной системе. Если продукт окажется успешным, то производитель сможет предложить единый стандарт API для движка BPMS аналогичный ODBC и тем самым оттянуть на себя еще большую долю рынка.

По функциональности такой продукт должен поддерживать:

  • Интроспекцию, т.е. предлагать, например, список атрибутов процесса, для которого разрабатывается данная форма.
  • Два режима: быстрого прототипирования и создания продуктивной системы. Первый предназначен для бизнес-аналитика, в нем достаточно задать перечень атрибутов и указать для них признак только для чтения / редактируемый / обязательный для ввода, а форма создается автоматически. Во втором визуальные компоненты размещаются на холсте вручную программистом и есть возможность писать код для валидации ввода, фоновых обращений к движку и т.д.
  • Те же два режима для портала. На этапе прототипирования - стандартный портал “из коробки”, для продуктивной системы - портал, собранный программистом из высокоуровневых компонент (см. “Демо- и промышленная система на основе BPM“).
  • Два типа клиентов: браузер и смартфон. Очень хочется иметь среду разработки форм, которые будут исполняться и на компьютере, и, скажем, на iPhone. В идеале хотелось бы, чтобы это была одна и та же форма. Как минимум, пусть формы будут разные, но со схожим дизайном и разрабатываемые в одной среде.
  • Ну и само собой, стандартную работу с базами данных и вебсервисами.

А вы воспользовались бы таким инструментом? Или он уже есть, а я просто отстал от жизни? Или вы собираетесь, или уже разрабатываете что-то подобное?

27.08.10 | Статьи |    

Комментарии (5)

  1. Александр 01.09.10 13:02

    По отношению к DBMS, Вы сконцентрировались на технологиях доступа, а главное, что породило такие системы упущено. Главное - это SQL. Именно использование стандартного языка привело к развитию этой технологии. Если бы каждый начал использовать свой язык, то мы получили совсем другую историю. Преимущество DBMS в том, что есть некое ядро языка, которое поддерживается всеми и есть особенности, которые позволяют реализовывать крутые фишки. Сила Oracle DB не только в ее производительности, но и в ее возможностях, которые иначе представленны у других БД. Ну это отдельная тема…
    Вернусь к теме поста. Проблема в том, что, в то время как БД имеют под собой достаточно стройную теоретическую систему (теория множеств и язык програмирования SQL), BPMS никакого НОРМАЛЬНОГО языка и теоретической базы не имеют. Это всего лишь красочные технологии. Верно подмечено, что “у него может быть…нестандартный язык программирования”. На мой взгляд, это и есть главная проблема. Нет теории, нет НОРМАЛЬНОГО языка. Эти системы будут продолжать коптить, пока не разгорятся :-). А это случится, только после появления стандартного языка (только вот не надо говорить о пародиях на язык програмирования в виде диалекта XML, если бы обращение к БД было бы на таком диалекте, то мы так бы на dbf и жили бы).
    И все таки еще… Если бы Unify закрыл (закроет) Accell, то проблемы действительно были бы (будут). Это странная аргументация.
    Если Вы заплатили за Oracle БД глупо не использовать те особенности, которые присущи этой базе (за которые заплачены немалые деньги) и ограничиватся стандартным SQL 92. Вы говорите про JDBC и ODBC, а что будет если от этих технологий (которые привязаны к конкретному вендору) решат отказаться? Кстати, если бы Oracle не подхватил бы SUN, посмотрел бы я на любителей Java технологий :-) с их мечтами отвязатся от вендора БД. Сила SQL в мобильности программистов между системами, а не в мобильности самих систем. Мобильность систем зависит от архитектора, проектировщика и качества кода программистов.
    Поэтому первое что должно произойти, это появление нормального языка, а потом будет и пункт 2 и пункт 3.
    А просто API не решает проблему, а только усложняет.

  2. Anatoly Belychook 01.09.10 13:46

    Александр

    Ваш выстрел просвистел мимо цели. Во-первых, в BPM есть и стандартный язык BPMN, и математическая основа. В основе DBMS реляционная алгебра Кодда (а вовсе не теория множеств), в основе BPMS - процессная. Погуглите. Нормальные они или там НЕНОРМАЛЬНЫЕ - это уже эмоции. Во-вторых, DBMS появились раньше, чем SQL, и намного раньше, чем появился стандарт SQL. Или Adabas - это, по-вашему, не СУБД? Поинтересуйтесь, какого масштаба прикладные системы на нем построены.

    Если бы… посмотрел бы я… - это слабая аргументация. Ваши аргументы в сослагательном наклонении работают против вас - по факту, любители Java технологий прекрасно себя чувствуют.

    В любом случае, эти аргументы имеют мало отношение к теме заметки, и давайте не затевать религиозных войн в защиту Oracle. Я просто ратую за то, чтобы для BPMS, как и для DBMS, существовал спектр решений для пользовательского интерфейса - и от вендора, и от третьих сторон. Вы, как я понимаю, сторонник концепции “все из одних рук” (single vendor)?

    А.Б.

  3. Александр 01.09.10 18:10

    “Ваш выстрел просвистел мимо цели” :-) Не страшно! Я сторонник не причинения вреда живому :-)
    “Ваши аргументы в сослагательном наклонении работают против вас ” - я не приводил аргументы, это примеры. Вы говорите “Преимущество, которое получал клиент: с таким инструментарием он мог безболезненно сменить СУБД.” А я считаю, что это не правильно. Это значит купить за 100 долларов вещь, а использовать только на 10 долларов, ожидая, что в будущем ее придеться поменять. Про это чуть позже.
    Мне интересна тема BPMS, но, к сожалению, они замерзли несколько лет назад, заняли скромную нишу на рынке и слабо развиваются.
    “DBMS появились раньше, чем SQL” - да ради бога! Я же не отрицаю существование BPMS, хотя языка (аналогичного SQL) все равно нет.
    Навсякий случай я уточнил на http://ru.wikipedia.org/wiki/BPMN и вижу ничего не изменилось.
    “Нотация моделирования бизнес процессов (Business Process Modeling Notation, BPMN) — графическая нотация для моделирования бизнес процессов.”
    Видел я еще XML диалекте этой нотации, но меня надо сильно прижать, чтобы я согласился писать на этом “языке”. Туже гадость могу сказать про BPEL - язык еще тот…. (Пришлось использовать на проектах), если бы не мода, даже не притронулся…
    Вообщем, как я и говорил речь идет о “красочных технологиях” и XML подобных языках.
    Вы пробывали писать SQL запросы не руками, а мастером (с помощью визуального, красочного интерфейса)? Если Вы занимались программирование в больших масштабах, то поймете о чем я. Такой же пример могу привести с точки зрения администрирования систем (командная строка или визуальные мастера).
    Я не сторонник одновендороного подхода. Но считаю, что из инструмента надо вытягивать все возможное (бабки заплачены, имею право), а не ставить себе ограничение в виде “не использовать расширения, которые не соответствуют открытым стандартам, ибо…”. Я делал проекты Oracle+ Delphi, Oracle + Forms, Oracle + Flex, Oracle + J2EE (интерфейс JSF). И каждое решение было, на мой взгляд, выбранно правильно. Кстати, нисколько не защищаю Oracle, просто я очень хорошо знаю базу данных этой фирмы, но некоторые проекты лучше делать на других БД.
    А пытаюсь я донести мысль, что нужен язык для BPMS, а его нет ;-(
    Все это имеет прямое отношение к Заметке, ибо Вы приводите некую типизацию-историзацию развития пользовательских интерфейсов к БД и пытаетесь провести аналогию с развитием BPMS. Наверное развитием доступа к BPMS? Так вот будет язык… Будет и BPMS, будет и доступ к нему. А пока все на уровне DBF файлов, хотя и с красивым интерфейсом.

  4. Anatoly Belychook 01.09.10 18:39

    Александр

    Спасибо за высказанное мнение, но Ваши оценки роли, назначения, состояния и перспектив BPMS и BPMN настолько сильно расходятся с моими, что продолжать дискуссию нет смысла.

    Я тут не знаю как управиться со всеми потенциальными заказчиками на проекты BPMS; на тренинг по BPMN, который я анонсировал пока что в очень узком кругу, народ ломится, а Вы говорите - все замерзло ;)

  5. Александр 02.09.10 09:12

    Анатолий
    Вам так же спасибо за приятную дискусию и интересный блог.

Комментирование закрыто

Copyright © 2008-2024 Анатолий Белайчук. Спасибо Wordpress и Yahoo.  Контент  Комментарии