Журнал о системах электронного документооборота (СЭД)
Workflow и управление бизнес-процессами

Еще немного мыслей об архитектуре ЮЗДО

  5 комментариев Добавить в закладки

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

Мысль первая. Интересно, но при обсуждении архитектуры обмена электронными документами между несколькими информационными системами ни разу не всплыли популярные когда-то аббревиатуры SOA (Service Oriented Architecture) и ESB (Enterprise Service Bus). Да и BPM-функционал рассматривался как безусловный аттрибут ECM-системы, а не отдельное решение. А ведь в ряде моментов надо говорить уже не только о human workglow, но и о межсистемном взаимодействии. В чем, как считалось пять или чуть более лет назад, и есть весь цимес SOA. Сразу всплывают из памяти Microsoft Biztallk или IBM WebSphere. Думаю, если бы не цена решения, способная отпугнуть недостаточно крупный бизнес, отличная бы получилась архитектурка. Да... Быстротечна ИТ-мода и круты петли гартнеровской hype-кривой. Впрочем, наличие в ECM-системе workflow просто нашептывает использовать его и в интеграционных целях. Тенденция? Или речь идет об интеграции систем, находящихся в нескольких юрисдикциях (Конрагент 1, Спецоператор, Контрагент 2)? Каждый сам автоматизирует свой кусок, как может. Думаю, как-то так.

Мысль вторая. Говоря об информационных системах, будь то ECM или ERP, мы по привычке "думаем за" on-premise системы. А ведь совсем скоро облачные решения отвоюют еще больше ИТ-бюджетов, и интегрировать надо будет разнообразные облачные решения. По крайней мере, если мы говорим о SaaS (Software as a Service) и отчасти PaaS (Platform as a Service). И это уже в ряде случаев будет головная боль провайдеров услуг. Или такие решения, разработанные ISV (Independent Software Vendors ), будут продаваться в он-лайн магазинчиках тех же поставщиков сервисов. Или это будут отдельные сервисы, что-то вроде популярных когда-то mushup'ов. Опять, забытый или редко используемый термин?

Ещё материалы автора
Похожие записи
Комментарии (5)
Михаил Романов 12 января 2012 г. 19:21  
А ведь в ряде моментов надо говорить уже не только о human workglow, но и о межсистемном взаимодействии. В чем, как считалось пять или чуть более лет назад, и есть весь цимес SOA. Сразу всплывают из памяти Microsoft Biztallk или IBM WebSphere
Сереж, не путай (хотя я и сам в свое время весьма значительно путался) - ESB и human workflow это очень разные системы, хотя может для неискушенного человека они выгялдят как развитие одно другого.
ESB система занимается тем что маршрутизирует сообщения между различными системами, работая вовне их, human workflow - управляет API системы, в которую встроено.
 
Отличие вроде бы не сильно заметное, но тут дьявол именно в мелочах.

Данные и API с которыми они работают 

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

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

Workflow работает с внутренним API системы, в которую встроена. Ее задача - предоставление удобного интерфейса программисту для автоматизации рутинных задач или систематизации регламентов. Она оперирует ограниченным набором объектов, которое это самое API и предоставляет.

Масштабирование и устойчивость.

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

При этом на ESB стараются не вешать дополнительную сложную логику, а также они работают асинхронно. Т.е. обработал одно сообщение, отбросил его в нужную систему и забыл о нем.

Workflow - обеспечивает работу людей и сложные длинные процессы, которые могут течь годами. Обычно этих процессов не много (если, конечно, программисты не используют workflow для затыкания абсолютно всех задач - от подписания документов, до выполнения резервного копирования) - несколько десятков тысяч на всю систему. Но (!) как я уже говорил, т.к. Workflow по сути управляет системой, в которую встроена - нагрузки на нее весьма приличные.

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

Мониторинг и аналитика.

ESB прокачивает кучу данных. Почему бы сразу эти данные не консолидировать, не строить по ним аналитику? Не по количеству прошедших сообщений, а по данным в них!

Workflow данные не передает, она управляет тем, что есть в системе, где она работает. Поэтому для нее аналитика это выборки из самой системы.

 

Впрочем, наличие в ECM-системе workflow просто нашептывает использовать его и в интеграционных целях.

В свете вышесказанного, мне кажется это ошибка.

  • у встроенной Workflow редко встретишь какие-либо специализированные средства для интеграции. А это значит - куча ручной работы для разработчиков и тестировщиков, написание велосипедов, самокатов и прочих средств передвижения.
  • если вешать на встроенную Workflow еще и задачи интеграции, это значит нагружать и без того просядающую систему. Конечно, если разработчики Workflow смогли разработать действительно масштабируемую систему, то можно и попробовать, но весь мой опыт работы с разными Workflow говорит, что врятли стоит рассчитывать на чудо - Workflow делаются для другого.
Вадим Майшев 12 января 2012 г. 19:36  
Еще немного мыслей об архитектуре ЮЗДО
Все слова про управление потоками данных. А ЮЗДО, вероятно, должно быть про документы?
Сергей Бушмелев 13 января 2012 г. 09:24  
Все слова про управление потоками данных. А ЮЗДО, вероятно, должно быть про документы?

Тема, которую поднял Алексей, достаточно обширна и многогранна. Я "отвел ветку", в которой хотел поговорить об интеграционных аспектах, термин "ЮЗДО" в данном случае - просто ссылка на исходную статью.

Хотя как знать, может, в комментах и договоримся до обеспечения юридической значимости электронных документов :)
Сергей Бушмелев 13 января 2012 г. 09:54  

Миша, спасибо за подробный анализ! Теперь и в моей голове что-то проснилось и немного устаканилось.

Я, скорее всего, очень многословно и неявно выразил свой посыл. Меня как раз несколько удивило, что в обсуждении не говорилось о SOA, ESB, BPM (в более широком понимании, чем human workflow), только о wokflow. У меня два предположения: 1) термин SOA окончательно вышел из моды 2) на wokflow пытаются взвалить задачи межсистемной интеграции.

если вешать на встроенную Workflow еще и задачи интеграции, это значит нагружать и без того просядающую систему

Кто-то из коллег по отрасли рассказывал о случае, когда СЭД работала именно как message broker, соединив три системы. При этом никаких ЭД и human workflow в ней не было. Мощности хватало, а цена решения была ниже, чем при использовании заточенных ESB-средств. Но это частный случай.
Михаил Романов 13 января 2012 г. 11:29  
Меня как раз несколько удивило, что в обсуждении не говорилось о SOA, ESB, BPM (в более широком понимании, чем human workflow), только о wokflow.
 

Ну тут претензии к Алексею - он всячески продвигал идею "ECM - как центр вселенной", чем и задал тему обсуждения.

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

  

Кто-то из коллег по отрасли рассказывал о случае, когда СЭД работала именно как message broker, соединив три системы.

Понятно, что схемы могут быть разными. Хотя сама постановка вопроса меня смущает: СЭД в качестве ESB в целях экономии... Имхо, при наличии огромного рынка open source решений в этой области как-то даже смысла не видно в таком варианте.

Сейчас обсуждают
Больше комментариев