Возвращаюсь к теме интеграции корпоративных информационных систем, начатой в конце июня этого года с сообщения об интеграции посредством СУБД. Как и обещал, рассказываю про более эффективные способы интеграции данных. Вообще, причина возникновения этой темы обусловлена современными(правильней сказать уже не столь современными) технологиями управления базами данных. Вернее двумя ограничениями этих технологий. Читать далее Сценарии интеграции приложений (2)
Рубрика: Software architecture
Приложение управления бизнес-приложениями
Чтобы понять рекурсию нужно понять рекурсию
Много слов сказано для обоснования полезности промежуточного ПО, интеграционных сред, систем управления бизнес-процессами. И количество «оппортунистических» связей между приложениями они сокращают, и интеграционные решения унифицируют и сквозные бизнес-процессы, включающие несколько приложений, реализуют. Всё это, безусловно, важно. Но не это главное.
Уже не один год существует класс информационных систем называемый application management. Эти системы позволяют удаленно развертывать и конфигурировать приложения, мониторить состояние системы, диагностировать ошибки, управлять квотами и т.д. Развитие облачных вычислений (cloud computing) дало дополнительный импульс application management. Насколько мне известно, в Windows Azure при наступлении определенных событий, например превышении загрузки процессора выше определенной черты или увеличении количества входящих сетевых запросов, можно автоматически поднять еще одну виртуальную машину и развернуть на ней дополнительный экземпляр приложения.
Не трудно провести аналогию между системами application management и интеграционными средами и BPMS. Только вторые управляют содержательной частью бизнес-приложений. Обычно, с бизнес-приложениями работают люди. Но по мере роста и развития информационной системы предприятия все чаще возникает необходимость заменить этих людей автоматизированными системами. Сценарии таких ситуаций следующие:
- Управление вводом данных. Когда возникает необходимость за ограниченный промежуток времени ввести в систему несколько десятков тысяч записей, люди становятся бессильны. До определенной степени можно расширять штат низкооплачиваемых сотрудников, занимающихся вводом, но это довольно затратный подход. Намного проще: загрузить данные подготовленные внешним приложением, например, переложить задачу ввода каких-либо запросов на партнеров и клиентов (системы self-service). Другой пример управления вводом данных – автоматическое добавление записей по событию. Многие сервисные службы создают инциденты не только по запросам пользователей, но и на основании событий систем мониторинга. (Подробнее об обработки событий см. ниже)
- Управление справочниками. Большинство бизнес-приложений используют справочники. Когда в различных системах ведутся разные справочники одних и тех же объектов, задача управления этими системами становится крайне сложной. Как только количество используемых систем превысит десяток – время задуматься о централизованном ведении справочников, а задачу управления справочниками возложить на интеграционную среду.
- Управление рабочими процессами (workflow). Сейчас трудно найти систему, внутри которой не было бы функций workflow. Однако такие workflow начинаются и заканчиваются «внутри» системы. Разделение труда между подразделениями предприятия, возможно и повышает его производительность, но в качестве цены за это формирует высоченные барьеры между подразделениями. В то же время, бизнес-процессы любого предприятия являются общими. Иногда в процессе участвуют не только подразделения одной компании, но и подразделения компаний-партнеров. Рабочии процессы – это единая сеть, требующая координации и согласованной работы. Идея бизнес-сервиса, как рабочего процесса, управляемого информационной системой была изложена мной в сообщении Программный интерфейс к бизнесу
- Обработка событий. На фоне всеобщего увлечения сервис-ориентированной архитектурой (SOA), управляемая событиями архитектура (even-driven architecture, EDA) осталась практически незамеченной. Однако, построение адаптивной информационной системы компании требует именно такого подхода. SOA сервисы интересны только в той степени, в которой они помогают компании реагировать на те или иные бизнес-события. Можно написать сотню сервисов, ни одним из которых никто и никогда не воспользуется. Событийный подход вносит смысл в информационную систему компании. Заставляет нас задумываться над вопросом «зачем», для каких случаев, мы разрабатываем тот или иной сервис. Перехват и маршрутизация событий, пожалуй, наиболее значимая ценность, привносимая интеграционными средами в корпоративный ИТ-ландшафт.
- Обработка исключений. Однако не все события поддаются автоматической обработке. Рано или поздно возникает ситуация не предусмотренная ни в требованиях к решению, ни в спецификации взаимодействий, ни в техническом задании. Огромная ошибка заключается в том, чтоб рассматривать такую ситуацию как ошибку, записать сообщение в системный лог и остановить бизнес-процесс. С каждой такой ситуацией должен кто-то разбираться. Появившиеся ошибки это та самая обратная связь от эксплуатации к развитию, помогающая своевременно корректировать бизнес-процессы и модернизировать приложения. Вопреки распространенному мнению интеграционная среда не является «системой без пользователей». Наоборот, это система для наиболее подготовленных и эрудированных пользователей, способных анализировать исключительные ситуации как с точки зрения ИТ, так и с точки зрения бизнеса и своевременно принимать адекватные решения.
Я надеюсь, что некоторые из изложенных мною соображений, расширят арсенал аргументов в пользу использования интеграционных сред в ИТ-инфраструктуре компаний. Комментарии и дополнения, как всегда, приветствуются.
Бои местного значения
Чизбургер этот не нужен тебе
…картошку Йоде желаешь отдать
Под заголовком Необъявленная война на BPMS.ru появился отличный обзор текущей ситуации между ECM, BPM и ACM решениями. Разные эксперты по-разному видят происходящее и оценивают перспективы. Так как я не являюсь продавцом лицензий на трехбуквенные системы, меня бы не должно это сильно затрагивать, но есть одно «но». Театром военных действий между поставщиками ИТ-решений являются корпоративные информационные системы. Война между поставщиками уже много лет разворачивается внутри корпоративных сетей заказчиков. И, естественно, потерь среди мирного населения никто не считает. Ежедневно ко мне приходят запросы от бизнес-подразделений с предложением купить новую систему или заменить старую, потому что: в ECMe нет функциональности BPM; в BPMе нет функциональности ACM, а в ACM нет вообще ничего, но это нам все равно нужно… Читать далее Бои местного значения
Почему архитектура нуждается в социальном ПО
В предыдущей заметке я позволил себе назвать появление UML основным событием в современной архитектуре информационных систем. Сегодня я подробней коснусь реализующих UML инструментов. Вернее, не существующих на сегодняшний день инструментов, а инструментов какими они должны быть.
Архитектура информационных систем предприятия
Почему-то архитекторам свойственно напускать много сиреневого тумана на свою деятельность: и определения что такое архитектура единого нет; и книжки про архитектуру все почему-то довольно толстые. Даже великий Буч, как мне кажется, больше написал о том, чем не является архитектура, а не о том, чем же она является. Мне хочется сделать простой и по возможности краткий обзор того, что же такое архитектура. Может начальникам как-нибудь расскажу. Обзор будет субъективный, потому сразу прошу – тапками в меня не кидайтесь.
Сценарии интеграции приложений
Одна из немногих книг по интеграции корпоративных информационных систем Enterprise Integration Patterns появилась в конце 2003 года. По большому счету других, сколь либо серьезных исследований данного вопроса с того времени и не появилось. Автор книги Gregor Hohpe поддерживает одноименный сайт Enterprise Integration Patterns на котором можно посмотреть основные паттерны. Впрочем, описаны они довольно кратко и лучше читать книгу. Тем более что она переведена на русский язык как Шаблоны интеграции корпоративных приложений.
При всем искреннем уважении к Грегору Хопу, должен отметить, что о паттернах корпоративной интеграции речь идет только в первых нескольких главах книги, написанных такими уважаемыми людьми как Мартин Фаулер и др. Авторы выделяют четыре основных паттерна интеграции: файловый обмен, общая база данных, вызов удаленной процедуры и обмен сообщениями. Основную часть книги как раз и занимают паттерны обмена сообщениями. Messaging, безусловно, мощный и эффективный подход как при интеграции так и при разработке корпоративных систем. Однако сценарии интеграции корпоративных приложений это не только и не столько messaging. Это и файловый обмен и синхронный вызов сервисов и доступ разных приложений к общей базе данных. И в описании подходов к интеграции чувствуется определенный пробел. Чтобы не перегружать слово паттерны, я буду использовать термин сценарии интеграции приложений и постараюсь постепенно заполнить возникший пробел.
Читать далее Сценарии интеграции приложений
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 – объединение контента, процессов, сотрудников и событий, связанных с конкретной задачей.
Платформа управления заданиями
Несколько лет назад, мы достаточно много говорили о сервис-ориентированной архитектуре. Напомню, что основная идея этого подхода заключается в разделении компонент корпоративной информационной системы на две группы. Первая группа состоит достаточно стабильных, предназначенных для повторного использования компонент, называемых сервисами. Сервисы реализуют базовый функционал и меняются не очень часто. Часто меняющийся функционал должен быть отделен от сервисов и вынесен в группу приложений второго типа.
Прошло много времени. Мы были заняты другими делами: новые проекты, финансовый кризис и т.д. В общем, о сервис-ориентированной архитектуре все стали понемногу забывать. Читать далее Платформа управления заданиями
Интеграция приложений
Оказывается, проблемы распределения ответственности при эксплуатации сервисной шины и других интеграционных систем существуют не только у нас. Практически те же темы поднимаются и в банках. Надеюсь, на ближайших встречах архитекторов мы это обсудим. А пока несколько моих соображений.