Я довольно давно не затрагивал тему 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 и процессов управления ИТ отделом организации
В этом контексте довольно интересной может быть тема построения некоторого социального dashboard для саппортов и поддержки решения тикетов:
* (самое главное) доступного поиска по базе знаний и другим тикетам (используется API поиска Confluence и Jira) – с обязательным механизмом suggest (как в гугле), категоризации и рейтинга поиска, по которому в том числе саппорты довольно хорошо обучаются (по истории решения других подобных решаемым тикетов).
* (нечто внутренней соц-сети) база пользователей (саппортов и внешних клиентов) на базе сервера OpenSocial (на базе Apache Shindig), где кроме относительно стандартных персональных данных, сохраняется глобальная история заказов клиента (ссылки на информацию в биллинге и др.), все факты взаимоотношений с клиентами (данные, ссылки, рейтинги), связи персоналий с внешними соц-сетями и др. И саппорты, и клиенты в одной БД, где между ними организуется граф с целью оптимизации их отношений (очевидно, клиенты не любят, когда их начинают бросать по телефонам). При продвижении продуктов через соц-маркетинг роль этой БД очевидна должна быть.
* gadget-портал для возможности построения персонализированных GUI и упрощения разработки/интеграции компонентов (мы ориентируемся на использование Apache Shindig с авторизацией по OAuth и поддержкой Google Gadget). В том числе, никто не запрещает загружать сторонние gadgets (хотя проводится аудит того, что используют и поддерживается чёрный список, по которому часть gadgets нельзя загрузить в портале). Для каждой роли пользователя задаётся список и формат отображения обязательных gadgets (нельзя их сдвинуть или поменять положение на странице dashboard), которые обычно связаны с решаемыми ролью задачи (синдикации activity stream подчинённых, ведомых обращений, обновления документации, чаты и др.).
* “пиналки” – отслеживающие жизненный цикл/статус тикетов, реализуется на базе Activiti, их задача очевидна (дедлайны, эскалации, журналирование и др.).
Практически везде ссылки и REstfull API (atom/json). Подобная инфраструктура развивается в некоторой небезысвестной компании-провайдере ИТ:)
Да. дашборды тема востребованная. Удивительно, что разработчики интранет-решений продвигают её как-то не очень активно
Вообще-то говоря, есть современные архитектуры интеграции данных разнородных приложений. Например, архитектура “ISO 15926 outside” (http://fiatech.org/images/stories/techprojects/project_deliverables/iso-intro-ver1.pdf).
Всё корпоративное — это мелочи по сравнению с тем, что происходит на отраслевом уровне. Ибо внутри предприятия можно выпустить какой-то архитектурный приказ, а вот между предприятиями этого сделать обычно нельзя…
И еще одна засада: есть интеграция данных, и есть интеграция воркфлоу. В какой-то момент можно сообразить, что данные о воркфлоу и о собственно данные — это одно и то же, просто интегрируемые данные и интегрируемые вычисления….
Так толком и не разобрался. Документ довольно объемный. Отложил до лучших времен
Ммм… да.
Я правильно понимаю что у WordPress похожая архитектура?
т.е. там есть Записи (как Узлы в Фейсбуке), которые можно настраивать и бить на виды. После чего можно до посинения выстраивать отношения между ними под любым углом, который зависит лишь от фантазии )
Кстати я долго искал решение для связки постов в WP и нашел вот это http://wordpress.org/extend/plugins/advanced-custom-fields/
Попробуйте. Уверен что вам понравится 🙂
Плагин позволяет добавлять доп.поля к записям типа: ссылки на другие записи.
Причем можно указывать кучу настроек.
Например:
1. у записей типа Задача, сделать доп.поле Ответственный и оно будет ссылаться на какую либо запись типа Сотрудники.
2. И более того, можно прикреплять эти отношения не только к типу записи, но и к типу записи определенной категории. Например одно дело это Задача категории Инцидент ИТ, другое дело что может быть Задача типа “Увольнение сотрудника” – там кроме Инициатора, Ответственного – было бы здорово иметь ссылку на того сотрудника, которого нужно уволить. И система позволяет добавить эту ссылку и это поле только к Задачам категории: Увольнение сотрудников
P.S. Слово Задача в этом тексте можно заменить на Кейс, Операцию или Тикет 🙂
Логически, архитектура, конечно, очень похожая. Но у фейсбука под этой моделью лежит логика распределения по узлам с mysql-ными базами, а у WP одна база из десятка таблиц. Вероятно, сейчас хранилища надо делать на чем-то более продвинутом, чем просто реляционная БД
оффтопик: facebook съезжает с mysql шардингового кластера на инфраструктуру hbase в котором они пытаются заменять и уровень кэширования (сейчас memcached) и хранения в том числе транзакций (hbase – реализуется CP-свойства CAP-теоремы) и аналитики в почти реальном времени. Я считаю это правильным направлением движения, в проектах своей компании (массовые транзакции, аналитика больших объёмов данных) – развиваем такой же подход… пока удачно, но не так всё красочно как кажется на первый взгляд (собственно faceboook основные комитеры hbase):)
Где-то я видел рейтинг внедрений open source в 2011г. HBase лидирует 🙂
Reblogged this on «Memento mori» and commented:
Маркер доступа ( на ФБ ) – “access token”.