Рубрика: Software architecture

Adaptive Case Management + Semantic Web

Развитие идей предыдущего сообщения другими словами.

Традиционный кейс менеджмент – это практика, предполагающая сбор в единой папке всех документов, относящихся к определенному случаю. Помните, были такие картонные папки с надпись «Дело №…». Adaptive case management позволяет нам ассоциировать с некоторым конкретным случаем (делом) не только документы, но и людей, процессы, сообщения, любые информационные ресурсы. Т.к. мы люди умные, то не будем физически подшивать эти ресурсы в папку, т.е. засовывать их внутрь, а соберем в кейсе гиперссылки на необходимые нам ресурсы: контент, карточку сотрудника, страницу бизнес-события и экземпляра бизнес-процесса.

Однако, простые гиперссылки не обладают семантикой. Т.е. ссылка на человека не будет отличаться от ссылки на документ. Это плохо. Поэтому мы будем использовать семантические ссылки, т.е. ссылки помеченные определенной меткой(тэгом). Например, ссылка на исполнителя кейса будет иметь тэг «case worker», а ссылка на инициирующее создание кейса событие будет иметь тэг «trigger». Естественно, нам не помешает механизм обратных ссылок, присутствующий в блогах, wiki и других социальных инструментах.

Это все! Очень простая и вполне законченная логическая архитектура ACM построена

Юзабилити глазами архитектора

При попытке охарактеризовать архитектурный стиль RESTful чаще всего мне в голову приходит термин usability. Конечно, я понимаю, что у этого термина совершенно другой смысл. Юзабилити ассоциируют с эргономикой и удобством пользователя. Есть замечательное по своему пафосу выражением «интуитивно понятный интерфейс», т.е. при выборе операции ты полагаешься не столько на знание возможностей инструмента, сколько на свою интуицию. В этой логике наиболее востребованной кнопкой должна быть ни «да» или «нет», а «может быть».

Впрочем, хватить злословить, теперь по существу. На мой взгляд, юзабельность любого программного инструмента определяется не его эргономикой, а простотой реализованной в нем логической модели. Сущностей должно быть мало. Они должны быть однозначно поименованы. Иметь простой граф изменения состояний и явно заданные отношения. Тогда и не будет возникать вопрос юзабельности. Попытка «упростить», уменьшить complexity другими способами, например изменением взаимного расположения органов управления, согласитесь, выглядит довольно лукаво

PS: Кстати, case management является довольно юзабильным подходом. Вы можете включить в кейс данные, людей, процессы, события так, как если бы они являлись объектами одного и того же типа. Логически кейс – это папка, которая объединяет все что угодно. В традиционном case management вы можете подшить в папку только документы. В advanced case managemnt-е  вы помещаете в кейс совершенно произвольные объекты, в том числе процессы, людей и события.

Другими словами:
ECM, Enterprise content management  – организация разнородного неструктурированного контента, используемого в деятельности предприятия
BPM, Business process management – объединение различных задач в согласованную последовательностей действия для достижения результата
Enterprise 2.0 (Social software) – объединение сотрудников в временные рабочие группы
Adaptive case management – объединение контента, процессов, сотрудников и событий, связанных с конкретной задачей.

Платформа управления заданиями

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

Прошло много времени. Мы были заняты другими делами: новые проекты, финансовый кризис и т.д. В общем, о сервис-ориентированной архитектуре все стали понемногу забывать. Читать далее Платформа управления заданиями

Интеграция приложений

Оказывается, проблемы распределения ответственности при эксплуатации сервисной шины и других интеграционных систем существуют не только у нас. Практически те же темы поднимаются и в банках. Надеюсь, на ближайших встречах архитекторов мы это обсудим. А пока несколько моих соображений.

Читать далее Интеграция приложений

Enterprise architecture в Клубе Архитекторов Microsoft

Вчера выступал и, что более содержательно, слушал чужие доклады и обсуждения, в Клубе Архитекторов Microsoft. Несколько наблюдений по горячим следам Читать далее Enterprise architecture в Клубе Архитекторов Microsoft

Enterprise architecture vs. BPM

В блоге Анатолия Белайчука появилась заметка Граница между инструментарием EA и BPMS. Желание провести такую границу абсолютно уместно. Не выполненных обещаний архитектуры предприятия, BPM сообщество  просто не потянет. С другой стороны, накопленный Enterprise architecture опыт реальной деятельности в компаниях, тоже не стоит сбрасывать со счетов. Тем более, что ошибки у корпоративных архитекторов и специалистов по управлению бизнес процессов одинаковы: Читать далее Enterprise architecture vs. BPM

Интеграция приложений

Среда интеграции приложений – программная платформа, предназначенная для развертывания большого количества композитных [микро]приложений в стиле SOA. Существуют два основных подхода к интеграции приложений: асинхронная интеграция приложений при помощи message-oriented middleware или же просто асинхронного взаимодействия между приложениями посредством обмена файлами или записями в общей базе данных и синхронная интеграция посредством сервисной шины. Недостатком первого подхода является сложная логика интеграции из-за необходимости синхронизации состояний объектов в различных системах. Второй подход требует обеспечения высокой надежности и масштабируемости решений.

Сервис-ориентированная архитектура (SOA) – стиль разработки, минимизирующий внесение изменений в унаследованные системы за счет повторного использования существующего функционала. Ключевой момент SOA заключается в реализации каждого бизнес-процесса в виде отдельного слабосвязанного компонента. В традиционных бизнес-приложениях множество бизнес-процессов реализуются в едином монолитном решении, что затрудняет локализацию проблем, существенно повышает вызванный внесением изменений риск нарушение работоспособности и как следствие требует более тщательного проектирования, разработки изменений и, как правило, проведение полного регрессионного тестирования.
Сервисная шина (ESB) – отдельный класс платформ интеграции приложений реализующий, в отличии от традиционных интеграционных сред, не только асинхронное, но и синхронное взаимодействии. Современные сервисные шины строится на базе решений JavaEE application server
Сервер приложений (JavaEE application server) – программная платформа, предназначенная для эффективного использования серверных ресурсов (процессы, оперативная память, пулы соединений, очереди и пр.) при исполнении множества java-приложений, реализованных в виде сервисов.

SOA сервис – слабосвязанный программный компонент, предназначенный для повторного использования. В отличии от традиционных интеграционных компонент, разработанных с учетом интерфейсов интегрируемых систем и используемых для интеграции только этих систем, сервис может использоваться любыми другими новыми приложениями.
Stateless протокол – протокол взаимодействия между клиентом и сервером, запрещающий сохранение на сервере состояния клиентского соединения. Таким протоколом, например, является протокол web-сервисов HTTP. В отличии от протоколов работы с базой данных, сохраняющих состояние клиентской сессии, stateless протоколы допускают высочайшую степень масштабирования за счет возможности установки дополнительных серверов, включаемых в общую систему балансировки нагрузки.

HATEOAS

Этот страшный заголовок является аббревиатурой Hypermedia as the Engine of Application State. Википедия указывает указывается на заметку блоге REST APIs must be hypertext-driven , принадлежащую Рою Филдингу. Слабо понятное сокращение скрывает совершенно великолепную архитектурную идею:

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

Филдинг говорил об этом применительно к архитектурному стилю REST (Кстати, он его и придумал). Из примеров реализации такой архитектуры мне на память приходят автоответчики, сценарии которых задаются в виде voiceXML страниц. Ну, а вспомнил я об этом, раздумывая об архитектуре BPM систем.

Dynamic business application

Способна ли ваша компания запускать новые продукты быстрее, чем ваше ИТ разрабатывает новые бизнес-приложения? Обычно ответ является отрицательным. Время вывода на рынок нового продукта или услуги не может быть меньше, чем время на разработку или на приобретение и развертывание нового приложения. Длинные циклы внесения изменений в ИТ системы являются существенным тормозом в стремлении предприятий гибко реагировать на меняющиеся потребности рынка.
Причина проблемы кроется в том, что используемые сегодня пакеты бизнес-приложений создавались для реализации типовых стандартных сценариев, создавались на основе требований сформулированных для текущей ситуации и не были предназначены для изменений. Дальше читаем Forrester The Dynamic Business Applications Imperative если найдем в бесплатном доступе