Рубрика: Software architecture

Чтобы понять рекурсию нужно понять рекурсию

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

Уже не один год существует класс информационных систем называемый application management. Эти системы позволяют удаленно развертывать и конфигурировать приложения, мониторить состояние системы, диагностировать ошибки, управлять квотами и т.д. Развитие облачных вычислений (cloud computing) дало дополнительный импульс application management. Насколько мне известно, в Windows Azure при наступлении определенных событий, например превышении загрузки процессора выше определенной черты или увеличении количества входящих сетевых запросов, можно автоматически поднять еще одну виртуальную машину и развернуть на ней дополнительный экземпляр приложения.

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

1. Управление вводом данных. Когда возникает необходимость за ограниченный промежуток времени ввести в систему несколько десятков тысяч записей, люди становятся бессильны. До определенной степени можно расширять штат низкооплачиваемых сотрудников, занимающихся вводом, но это довольно затратный подход. Намного проще: загрузить данные подготовленные внешним приложением, например, переложить задачу ввода каких-либо запросов на партнеров и клиентов (системы self-service). Другой пример управления вводом данных – автоматическое добавление записей по событию. Многие сервисные службы создают инциденты не только по запросам пользователей, но и на основании событий систем мониторинга. (Подробнее об обработки событий см. ниже)
2. Управление справочниками. Большинство бизнес-приложений используют справочники. Когда в различных системах ведутся разные справочники одних и тех же объектов, задача управления этими системами становится крайне сложной. Как только количество используемых систем превысит десяток – время задуматься о централизованном ведении справочников, а задачу управления справочниками возложить на интеграционную среду.
3. Управление рабочими процессами (workflow). Сейчас трудно найти систему, внутри которой не было бы функций workflow. Однако такие workflow начинаются и заканчиваются «внутри» системы. Разделение труда между подразделениями предприятия, возможно и повышает его производительность, но в качестве цены за это формирует высоченные барьеры между подразделениями. В то же время, бизнес-процессы любого предприятия являются общими. Иногда в процессе участвуют не только подразделения одной компании, но и подразделения компаний-партнеров. Рабочии процессы – это единая сеть, требующая координации и согласованной работы. Идея бизнес-сервиса, как рабочего процесса, управляемого информационной системой была изложена мной в сообщении Программный интерфейс к бизнесу
4. Обработка событий. На фоне всеобщего увлечения сервис-ориентированной архитектурой (SOA), управляемая событиями архитектура (even-driven architecture, EDA) осталась практически незамеченной. Однако, построение адаптивной информационной системы компании требует именно такого подхода. SOA сервисы интересны только в той степени, в которой они помогают компании реагировать на те или иные бизнес-события. Можно написать сотню сервисов, ни одним из которых никто и никогда не воспользуется. Событийный подход вносит смысл в информационную систему компании. Заставляет нас задумываться над вопросом «зачем», для каких случаев, мы разрабатываем тот или иной сервис. Перехват и маршрутизация событий, пожалуй, наиболее значимая ценность, привносимая  интеграционными средами в корпоративный ИТ-ландшафт.
5. Обработка исключений. Однако не все события поддаются автоматической обработке. Рано или поздно возникает ситуация не предусмотренная ни в требованиях к решению, ни в спецификации взаимодействий, ни в техническом задании. Огромная ошибка заключается в том, чтоб рассматривать такую ситуацию как ошибку, записать сообщение в системный лог и остановить бизнес-процесс. С каждой такой ситуацией должен кто-то разбираться. Появившиеся ошибки это та самая обратная связь от эксплуатации к развитию, помогающая своевременно корректировать бизнес-процессы и модернизировать приложения. Вопреки распространенному мнению интеграционная среда не является «системой без пользователей». Наоборот, это система для наиболее подготовленных и эрудированных пользователей, способных анализировать исключительные ситуации как с точки зрения ИТ, так и с точки зрения бизнеса и своевременно принимать адекватные решения.

Я надеюсь, что некоторые из изложенных мною соображений, расширят арсенал аргументов в пользу использования интеграционных сред в ИТ-инфраструктуре компаний. Комментарии и дополнения, как всегда, приветствуются.