Уровни зрелости разработчиков интеграционных решений

esbЛет 7-10 тому назад, во времена всеобщего увлечения сервис-ориентированной архитектурой было модно придумывать уровни зрелости SOA сервисов. Open Group придумал Service Integration Maturity Model (OSIMM). IBM отметился свое трактовкой уровней зрелости (см., например Solution design in WebSphere… ), обещающий достигнут пятого из семи возможных уровней зрелости посредством внедрения WebSphere Process Server  (см. рисунок ниже). Ну, а Microsoft c Informatica-ой занимались оценкой уровней зрелости в деле интеграции данных (A Maturity Model for Data Integration) В общем, каждый занимался своим делом. IBM даже порывался сделать у нас консалтинговый проект, но мы сами приписали себе второй или третий уровень зрелости и сразу согласились на пилотный проект с WS Process Server.По результатам пилота мы даже приняли решение внедрить BPEL Engine, правда не от IBM-а, а open source, да и WebSphere Message Broker из эксплуатации вывели (кому нужен инструмент не того уровня зрелости 😉 Читать далее Уровни зрелости разработчиков интеграционных решений

Forrester: SOA жив и здоров

Примерно таким заголовком анонсировали интернет издания мартовское исследование Forrester SOA Adoption 2010: Still Important, Still Strong Оказывается 71% опрошенных компаний уже используют SOA или собираются это сделать в течении 2011 года. То же самое говорит почти половина средних и малых компаний. Организации довольны результатами, получаемыми от сервис-ориентированной архитектуры и не собираются от неё отказываться. Безусловно, определенная часть опрошенных просто не понимает о чем говорит, но единодушие в ответах респондентов показывает, что «пациент скорее жив, чем мертв».

Не менее интересное исследование появилось в конце апреля The Forrester Wave™: Enterprise Service Bus, Q2 2011. Рынок ESB продолжает неплохо расти. Кроме вполне привычных для ESB задач, таких как маршрутизация сообщений и преобразование данных 35% компаний используют ESB непосредственно для разработки сервисов, а 14% для прикладной разработки на BPEL (28% используют BPEL для оркестровки). Кстати, с языком исполнения бизнес-процессов WS_BPEL ситуация тоже интересная. 2-3 года назад только ленивый не говорил о том, что SOA и BPM – браться на век. Затем из лагеря BPM стали отчетливо слышаться голоса, что BPEL not for people. В ответ могу попрекнуть разработчиков BPMS в монолитности архитектуры их флагманских продуктов. Далеко не все BPMSы, те который для людей, а не так называемый IC-BPMS, отвечают принципам сервис-ориентированной архитектуры, потому как сервисов они не предоставляют. В итоге, у больших вендоров в линейке присутствуют как минимум по два продукта: один для быстрого рисования процессов и пользовательских интерфейсов к ним, а другой для интеграции в корпоративную информационную систему, т.е. интероперабельный. Читать далее Forrester: SOA жив и здоров

Услуга интеграции приложений для оператора связи

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

Потребности оператора связи в интеграции приложений можно условно разбить на следующие группы: Читать далее Услуга интеграции приложений для оператора связи

Сценарии интеграции приложений (3)

Я довольно редко пишу о сценариях интеграции и потому не могу закончить с интеграцией данных и перейти к интеграции приложений и сквозным бизнес-процессам. Тем не менее, интеграция данных это важно. ESB, SOA и прочие трехбуквенные сокращения, занимая наше внимание, отвлекают нас от других, намного более важных трехбуквенных сокращений, таких как ODS и DWH. ODS и DWH – «рабочие лошадки» ИТ архитектуры предприятия, способные избавить нас от множества лишних информационных систем и оппортунистических связей между ними.
Читать далее Сценарии интеграции приложений (3)

Сценарии интеграции приложений (2)

Возвращаюсь к теме интеграции корпоративных информационных систем, начатой в конце июня этого года с сообщения об интеграции посредством СУБД. Как и обещал, рассказываю про более эффективные способы интеграции данных. Вообще, причина возникновения этой темы обусловлена современными(правильней сказать уже не столь современными) технологиями управления базами данных. Вернее двумя ограничениями этих технологий. Читать далее Сценарии интеграции приложений (2)

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

Одна из немногих книг по интеграции корпоративных информационных систем Enterprise Integration Patterns появилась в конце 2003 года. По большому счету других, сколь либо серьезных исследований данного вопроса с того времени и не появилось. Автор книги Gregor Hohpe поддерживает одноименный сайт Enterprise Integration Patterns на котором можно посмотреть основные паттерны. Впрочем, описаны они довольно кратко и лучше читать книгу. Тем более что она переведена на русский язык как Шаблоны интеграции корпоративных приложений.

При всем искреннем уважении к Грегору Хопу, должен отметить, что о паттернах корпоративной интеграции речь идет только в первых нескольких главах книги, написанных такими уважаемыми людьми как Мартин Фаулер и др. Авторы выделяют четыре основных паттерна интеграции: файловый обмен, общая база данных, вызов удаленной процедуры и обмен сообщениями. Основную часть книги как раз и занимают паттерны обмена сообщениями. Messaging, безусловно, мощный и эффективный подход как при интеграции так и при разработке корпоративных систем. Однако сценарии интеграции корпоративных приложений это не только и не столько messaging. Это и файловый обмен и синхронный вызов сервисов и доступ разных приложений к общей базе данных. И в описании подходов к интеграции чувствуется определенный пробел. Чтобы не перегружать слово паттерны, я буду использовать термин сценарии интеграции приложений и постараюсь постепенно заполнить возникший пробел.
Читать далее Сценарии интеграции приложений