Я довольно давно не затрагивал тему adaptive case management. Не затрагивал, не потому что она мне стала не интересной. Просто последние несколько месяцев у меня очень много работы, связанной с практической реализацией ИТ поддержки такого рода процессов. В первую очередь, речь идет о процессах решения телеком инцидентов. Это тысячи тикетов ежедневно, необходимость оперативного доступа к данным о клиентах, договорах, адресах подключений, данным по сетевому оборудованию и предоставляемым сервисам. Все это по-разному работает для разных типов услуг, линий бизнеса, в разных информационных системах. Этот практический опыт подтверждает мои предыдущие наблюдения. Если бы мне сейчас пришлось писать Adaptive Case Management Manifesto я бы начал с того, что гибкость бизнес-процессов достигается разделением приложений для совместной работы и приложений управления данными.
Если у вас есть хорошо структурированные данные, открытые для всех корпоративных приложений через эффективные программные интерфейсы, то вопрос обеспечения гибкости систем управления бизнес-процессами теряет свою актуальность. Вы можете реализовывать такие приложения на Java, BPEL, в движках поддерживающих BPMN и т.д. Завтра придут новые средства реализации бизнес-процессов, такие как subject oriented BPM (S-BPM) или что-то другое. Все эти приложения могут мирно уживаться друг с другом, если под ними будет находиться единый слой данных. Вы можете менять такие приложения и технологии по мере необходимости.
Чтоб в очередной раз не быть голословным в призывах использовать RESTful API и пр., несколько слов о том, как такого рода хранилище реализовано у Facebook. Я выбрал его потому, что «пощупать» Graph API фейсбука можно прямо из браузера без написания кода.
Как всем хорошо известно, фейсбук – это социальная сеть, состоящая из узлов и именованных связей между ними. Люди, группы, события, сообщения – это все узлы, имеющий свой уникальный идентификатор и доступные либо в виде веб страниц по ссылкам типа:
https://www.facebook.com/115085015172389 — в HTML формате для людей, или по ссылкам типа:
https://graph.facebook.com/115085015172389 — в формате JSON для машин(программ)
Впрочем, для работы с API удобнее использовать страничку Facebook-а Graph API Explorer краткое описание которого доступно здесь Introducing the Graph API Explorer.Эксплорер позволяет легко сгенерить аутентификационный токен и в дальнейшем работать с данными фейсбука ни в чем себе не отказывая (в рамках прав доступа).
Для просмотра узлов, связанны с данным узлом какими-либо отношениями используются ссылки вида:
https://graph.facebook.com/115085015172389/friends — показывает друзей
https://graph.facebook.com/115085015172389/likes — показывает предпочтения и т.д.
Короткое и доступное описание Graph API: https://developers.facebook.com/docs/reference/api/
Более продвинутый раздел – подписки: https://developers.facebook.com/docs/reference/api/realtime/
Это все что надо, для того чтоб начать погружением в тему. Ну а то, как из разрозненных слабо документированных корпоративных хранилищ данных построить нечто подобное – это отдельный вопрос.
Я думаю, начать тренироваться можно с построения CMDB 3.0 о которой я совсем недавно писал в заметке Service Knowledge Management System и процессов управления ИТ отделом организации