Архитектура Adaptive Case Management

Прочитал перевод забавной статьи Как ACM позволяет достичь гибкости бизнеса Деба Миллера, в которой автор сравнивает ACM c Dog Agility. Аджилити – это соревнование, в которых человек, называемый хэндлером, направляет собаку по полосе препятствий. Собака преодолевает препятствия, человек – бежит рядом и подает ей команды. Хэндлер не имеет права трогать собаку или препятствия, поощрять собаку едой или заманивать игрушкой. В его арсенале только команды жестом и голосом. Честно говоря, это действительно напоминает современные нам способы управления информацией через интерфейсы заказных программных систем. Только у одной собаки сразу несколько хозяев, расставленных по клеточкам бизнес-процесса

Прочитал статью и задумался над тем, что adaptive case management все больше и больше воспринимается не как инструмент, информационная система, бизнес-приложение, а как определенный набор практик сотрудника умственного труда (knowledge worker), работающего в современной организации. Это, безусловно, хорошо. Но чем дальше мы будем уходить от простых и конкретных понятий, тем меньше мы будем понимать, что же такое adaptive case management на самом деле. Поэтому, позволю себе вернуться к одному из первых определений ACM, предложенному Workflow Management Coalition. Возможно, это позволит избежать некоторого числа ненужных вопросов. Итак,

Adaptive Case Management (ACM) is information technology that exposes structured and unstructured business information (business data and content) and allows structured (business) and unstructured (social) organizations to execute work (routine and emergent processes) in a secure but transparent manner.

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

Далее следуют две не очень внятные картинки о том, что в случае BPMS в центре нашего внимания процессы, а в случае ACM – данные. Думаю, эти картинки вносят больше путаницы, чем понимания. BPMS, СЭД и прочие приложения тоже работают с данными. Но эти данные пользователям недоступны. Т.е. пользователи их, конечно, видят, но только на определенных шагах бизнес-процесса и только через те экранные формы, которые разработал для них программист. Возможности просмотра, изменения, добавления данных, ассоциирования их друг с другом ограничены дизайном экранных форм. Хочешь сделать что-то непредусмотренное в экранной форме – пиши change request разработчику, через полгода включат с очередной релиз или беги к знакомому сисадмину. Айтишники при этом очень любят посетовать на бестолковость пользователя, который не может изначально четко сформулировать требования. В ACM подход совершенно иной. Данные принадлежат пользователям.

Как это реализовать? Да, безусловно, через RESTful архитектуру. На веб-странице с адресом http://acms/case/7654 отображаем основную информацию по кейсу, свойства, ссылки на историю изменений и вовлеченных сотрудников.

http://acms/case/7654/history – история изменений кейса
http://acms/case/7654/workers – коллекция пользователей и групп
http://acms/case/7654/owner – ссылка на пользователя John Smith
http://acms/case/7654/content/filename.doc – вложение
и т.д.

Разумеется, что при обращении по этим ссылкам из браузера возвращается HTML страничка, а из приложения – информация пригодная для парсинга в форматах XML или JSON.

Все что и нужно-то сделать для успешного развития ACM, так это стандартизировать интерфейсы к хранилищу кейсов, определить минимальный набор обязательных свойств и способы его расширения (конечно же, просто добавляем “key = value”), зафиксировать основные коллекции: люди, связанные процессы, связанные кейсы, вложенные задачи, история изменений. Не знаю, почему OMG этого до сих пор не сделала. Наверное, там просто не умеют стандартизировать программные интерфейсы, а описать структуру данных в BPMN задача, действительно, нереальная.

Похожие сообщения:

Архитектура Adaptive Case Management: 8 комментариев

  1. 1. Описать структуру чего угодно (отмоделировать данные) — задача реальная. Так, Dennis Wisnovsky сделал онтологию BPMN и еще нескольких других стандартов (ontolog.cim3.net/file/work/OntologySummit2012/2012-03-01_Ontology-for-Systems-Federation-n-Integration/OntologySummit2012_Business-Enterprise-Architecture-Ontology-Development–DenisWisnosky_%2020110301.pdf). Это и есть “отмоделировал данные”. Хотя это нетривиальные пока технологии, чего уж там.

    2. Заход на моделирование данных и объектов с выполнителями — правильный. Интерфейсы же — это просто места предоставления этих данных, а REST так вообще данных не касается, и этого шага пропустить нельзя. Вот ваши URI — это ведь как раз отмоделированные данные (онтология кейса), способ доступа к ним тут вторичен.

    3. Поглядите на забавный постинг (ему соответствует огромный тред в комьюнити Adaptive Case Managemen в LinkedIn) — http://mtubook.wordpress.com/2012/02/20/requirements-for-an-acm-system/, это современное состояние дискуссий.

    4. Фишка, на мой взгляд, не в том, чтобы иметь одну ACMS на всех. Это я считаю утопией: все кейсы отрабаываются в сложной конфигурации разных систем. Я считаю, что ACMS нужно уметь завести как федерацию инормационных систем, в которой возможна работа с кейсами. И значительная часть этих систем будет (увы, но факт) legacy. См. мою презентацию, где я об этом рассказываю с использованием терминологии системной инженерии — http://ontolog.cim3.net/file/work/OntologySummit2012/2012-03-01_Ontology-for-Systems-Federation-n-Integration/OntologSummit2012_Ontology-based-Systems-Federation–AnatolyLevenchuk_20120301.pdf (на той же сессии, где выступал и Wisnosky. Ежели чего, там есть и аудио всех этих выступлений, и чат транскрипт — ссылки тут: http://ontolog.cim3.net/cgi-bin/wiki.pl?ConferenceCall_2012_03_01).

    5. Очень приятно понять, что кто-то обсуждает ACM по-русски. Я тоже довольно плотно этим вопросом занимаюсь, но пока не разразился текстами. Но уже скоро 🙂

    1. Спасибо за внимание к моим сообщениям и ссылки. Посмотрел презентации. Интересно.

      Федеративная ACMS получится после выполнения двух условий: отображения структур данных унаследованных приложений в структуру данных ACM и разработки механизмов “вытаскивания” событий из унаследованных приложений. Не думаю, что надо интегрировать старые приложения в ACMS через какие-либо другие механизмы, например, вызывать эти приложения через синхронные интерфейсы

  2. > http://acms/case/7654/content/filename.doc – вложение

    вот тут поправлю, вложение оно должно выглядеть вот так: acms/media/123 – т.е. какой либо документ это такая же сущность как и Кейс, как и Персона и она также может перетекать из одного кейса в другой, потому привязывать “файл” к кейсу низзя.

    К тому же это добавляет гибкости к архитектуре, например можно использовать внутреннее хранилище файлов и оно будет такое acms/media
    А можно Google Docs, и оно будет docs.google.com/123
    Ну и любые другие сущности, имеющие уникальный ID с URL

    http://acms/case/7654/history – вот это мне понравилось. я об этом думал, но до конца не осозновал. а тут раз и точка в мыслях поставилась )

    давайте назовем это формой кейса…
    какие формы могут быть еще?
    print – форма для печати
    feed-comment – RSS подписка на комментарии по кейсу 🙂
    print-sz – служебная записка, которая отличается от формы для печати тем что снизу будет поле для мокрой подписи – часто нужно для интеграции вирутального и реального миров 🙂

    и набор форм у кейса не ограничен… если это кейс на подготовку договора, то это форма договора, которая подтягивает в себя все данных из смежных сущностей, такие как реквизиты сторон и условия договора (с НДС или без)…

    ну и в части OMG – согласен. Правда есть и хорошая новость… прототип данной системы вчера запущен в тестовую эксплуатацию 🙂 на базе отдела ИТ. Будет ACMS ITSM 🙂
    Далее по плану 1-2 недели отточки и в систему будут заведены все бизнес процессы, всех подразделений и всех филиалов. Главное чтобы система выдержала нагрузку 🙂

    И да, я тоже прочитал эту статью, она написана очень абстрактно, и мне кажется что ее может понять лишь тот кто уже дозрел до идеи ACM. А для других это снова умная статья о не понятной аббревиатуре )

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

      1. а я вообще подумал что это следствие использования архитектур MVC. или я ошибся?
        т.е. имеем модель данных (внутренняя структура, типа данных, таксономии), можем их смотреть (шаблоны, темы, формы) и можем их обрабатывать (кнопочки, workflow …)

  3. Как обычно, по тех-части замечу…:)
    ….Относительно API тех-части протокола CRUD etc для доступа и управления вэб-ресурсами подобных кейсам и др., стоит посмотреть на AtomPub и его расширения типа archiving и gdata (Google). С АтомPub, в частности, прозрачно можно использовать как xml,- представления так и json вместе с HTML – что обычно реализуется посредством xslt, который применяется к хмл-содержанию как на стороне сервера, так и прямо в браузере (в большинство из них давно встроен препроцессинг заголовков xslt). А вариант формата возвращаемых данных указывается в параметрах, типа http://acms/case/7654/workers?type=json – вернуть ленту пользователей.

    По поводу ссылочности используем принципы вэб, сим-линки и все становится на места, если рассматривать модель ресурсов, существующих относительно независимо с собственными id: кейс, документ, сотрудник – параметры и описание которых (и метаданные) доступны по таким запросам:
    /askme/persons/123
    /askme/cases/9876
    /askme/contents/7654
    Причем, запрос /askme/persons – возвращает ленту всех персон, а если его дополнить нечто, /askme/persons?search=Вася&offset=10&limit=5&type=html – мы получаем готовую страницу результатов поиска, которые можно листать (стандарт OpenSearch).

    Далее, /askme/cases/9876/contents – лента параметров и ссылок на документы связанные с кейсом,а /askme/cases/9876/contents/7654 – параметры привязки документа (кто когда и т.п.), а /askme/cases/9876/contents/7654/self на самом деле при запросе делает редирект на линк выше. Еще пример: /askme/cases/9876/owner – содержит описание назначения роли (дата, автор и т.п.), а также редирект-ссылку на персону /askme/cases/9876/owner/self. Собственно, архитектурно подобное легко реализуется хмл-мапингом над обычной БД, важно только более менее корректно смоделировать предмет ную область в виде ресурсов и ссылок. По подобному шаблону можно свести к REST-стилю и упростить большинство задач (даже с транзакциями:).

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *