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

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

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

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

Архитектура предприятия в формате Semantic Web

Готовлю презентацию на обозначенную тему:


Основные тезисы:
Читать далее Архитектура предприятия в формате Semantic Web

Lean процессы :-)

Как работает (хороший) бизнес-аналитик сегодня:
Он довольно быстро создает основную ветку процесса. Иногда это называют типичным ходом событий. А потом очень много времени тратит на выявление исключительных ситуаций и написание для них обработчиков. Причем, сложность обработчиков может быть крайне велика. Существенно больше, чем сложность основного сценария. Это хорошая практика. Нас всех так учили на уроках программирования. В результате, в современных приложениях огромный объем кода никогда не вызвался, а возможно и не будет вызываться. А модели бизнес-процессов перегружены логикой, которая мало того что сложна и редко используется, но с большой вероятностью уже давно неактуальна. Ситуация меняется. Исключения надо обрабатывать иначе. Case management интересен тем, что сводит развесистый граф традиционной модели процесса к небольшому набору практически линейных наборов активностей. Ну а с исключениями пусть разбираются люди.

HATEOAS

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

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

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

Первый взгляд на Metastorm BPM

Посмотрел дизайнер бизнес-процессов от Metastorm (взять можно на http://www.metastorm.com/). Решение совсем игрушечное и применять его в реальной деятельности вряд ли целесообразно. Впрочем, простота решения способствует пониманию идей.
Читать далее Первый взгляд на Metastorm BPM

Dynamic business application

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

Что роднит BPM и кейс менеджмент

Брюс Сильвер пишет о том, что case managment нацелен на решение тех же управленческих проблем что и BPM:

  • задачи решаются слишком долго;
  • неэффективно используются ресурсы;
  • необходимая информация отсутствует или недоступна;
  • отсутствует стандартизация и обмен опытом, схожие задачи решаются разными способами;
  • ключевые показатели эффективности отсутствуют либо непрозрачны.

Вероятно, BPM может решить эти проблемы для узкого круга задач. Но что делать во всех других случаях?

Case Management for Knowledge Work

Вебинар Workflow management coalition, состоявшийся 3 марта необходимо посмотреть всем, кто интересуется данной темой. Доступны как слайды, так запись вебинара case management for knowledge work

Несколько идей тезисно:

Knowledge worker — это тот, кто лучше всех в организации разбирается в определенной задаче. (моя вольная интерпретация Друкера)

BPM базируется на следующих допущениях: ваш процесс предсказуем и четко определен; его можно автоматизировать; увеличение «объемов производства» позволяет вернуть вложенные средства. О последнем необходимом условии забывают чаще всего. Интересно, сумел ли Адам Смит продать все булавки, произведенные после эксперимента с разделением труда?

Work-around — старейший киллер производительности труда

Accenture 2009: Companies need to treat innovation with the same discipline as other functions. The most successful companies are generating profitable revenue by managing innovation as a business process.