Лет 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 из эксплуатации вывели (кому нужен инструмент не того уровня зрелости 😉
Но посвятить эту заметку я хочу немного другому. Идея о наличии нескольких, по своей сути довольно разных сценариев использования интеграционных сред заслуживает того, чтоб порассуждать о целях, задачах, техниках и уровнях зрелости подходов к разработке интеграционных решений. Моя версия уровней зрелости разработчиков интеграционных решений:
1 – Начальный уровень: Характеризуется владением навыками разработки в основных инструментах: MQ, ESB, ETL, умением разрабатывать адаптеры и реализовывать простые сценарии интеграции «точка-точка». Разработчики могут распарсить довольно сложные сообщения при помощи соответствующих инструментов, имеют общее представление о паттернах интеграции корпоративных приложений , умеют трансформировать и маршрутизировать сообщения и обогащать данные. В общем, интеграционная среда используется в качестве инструмента разработки ПО. Должна же существовать в организации система для перекладывания информации из файлов в базы данных, преобразования данных из одних форматов в другие и реализации нестандартных протоколов, типа SMPP для отправки смс-сообщений. Большинство системных интеграторов, увы, находятся на этом уровне зрелости.
2 – Технологический уровень: Основная задача интеграционной среды заключается в преодолении ограничений программных интерфейсов унаследованных систем. Интеграционная шина используется для разработки сервисов (повторно используемых программных интерфейсов). Вернее, для «оборачивания» имеющихся интерфейсов веб-сервисам. Проблема в том, что разработчики приложений не собирались кому-либо предоставлять программные интерфейсы к свои системам. Даже если в системе и есть какие-нибудь API, то делались они исключительно для себя, например, для того, чтоб распараллелить разработку между участниками команды. В общем, если программные интерфейсы в системе и реализованы, то от вызова их из внешнего приложения будут бдительно охранять системные администраторы. Разработчики этого уровня зрелости неплохо представляют себе, как преодолеть ограничения унаследованных систем. Знают, что такое CQRS, Какие данные можно взять из основной системы, а какие из копии, как построить конвейер обработки команд и т.п. На этом же уровне появляется осознание того, чем хаб отличается от шины, а ЕАI от ESB, реализуется идея транспорта на очередях сообщений и т.п. Как правило, от внедрения интеграционной среды заказчик ожидает именно этого. Справедливости ради следует отметить, что в наши дни в технологический уровень зрелости проникают такие вещи, как виртуализация и динамическая конфигурация интерфейсов, приведенные в модели OSIMM в качестве 6-го и 7-го уровней зрелости. Спасибо частным облакам и технологиям XaaS.
3 – Прикладной уровень: Разработчик интеграционных сред начинает задумывать о смысле своей деятельности, узнает у архитекторов умные слова и выражения типа управления основными данными (master data management) и пр. Сервисная шина уже не воспринимается как машинка для перекладывания данных из системы А в систему В. Она синхронизирует справочники, управляет основными данными и мета-данными, поддерживает процесс Data Governance, в общем превращается в инструмент корпоративной архитектуры. Стоит это существенно дороже, так как требует усиления команды разработчиков аналитиками, архитекторами, а зачастую и экспертами, разбирающимися в предметных областях. Меняется процесс внесения изменений. Появляются типовые изменения, избавленные от бюрократических правил организации.
4 – Бизнес уровень: Поддержка операционных процессов и Bi-Modal IT. Разрозненные сценарии интеграции сливаются в бизнес-процессы. Большая часть бизнес-процесса реализуется внутри интегрируемых приложений. Сервисная шина появляется только в точках кросс-функциональности бизнес процесса. Т.е. в те моменты, когда процесс выходит за границы одной системы, чтоб продолжится в другой. В сложных ИТ-ландшафтах один и тот же процесс может пройти сквозь интеграционную среду несколько раз: отправили задачу из одной системы в другую и ждем пока она к нам вернется. Тот, кто занимался синхронизацией статусов операций, «размазанных» в нескольких приложениях поймет, о чем я сейчас говорю. На этом уровне зрелости IBM рекомендовал использовать WS-BPEL, правда после покупки BPM Lombardi несколько поменял приоритеты. Основные задачи этого уровня зрелости: бизнес-мониторинг (нам не интересно сколько данных мы переложили из одной системы в другую в мегабайтах или штуках, нам важна информация о текущем состоянии бизнес-операции), скрупулёзная обработка ошибок, оперативное внесение изменений. Интеграционная среда в этом случае превращается в оазис второй модальности би-модального ИТ, т.е. область быстрого внесения изменений. Необходимо крайне плотное взаимодействие между разработкой и эксплуатацией в формате devops, автоматизация внесения изменений (для сокращения человеческих ошибок), failing forward, «канареечные» релизы и пр. (см. DevOps метафоры ). Иначе всех просто очень быстро уволят.
5 – Трансформирующий уровень: На этом уровне зрелости начинается Digital. Процессы, которые уровнем ниже были ориентированы преимущественно на людей(сотрудников), переориентируются на настоящих людей(клиентов и партнеров). Появляются разговоры про сквозную обработку (straight-through processing, STP). Инциденты заводят не сотрудники, у которых не обновился справочник контрагентов, а директора, провалившие план по выручке из-за ошибок в системе. Кратно возрастает нагрузка на систему до сотен TPS и выше, окна для технологических операций с приложениями исчезают как класс. Если к этому уровню зрелости интеграционная среда не отпочковалась от Mode1 IT, а архитектура интеграционных сценариев не стала cloud-native, то проблемы неминуемы. Такого рода решения не переживут плановых работ (установка свежего патча, обновление политики безопасности…) или традиционного цикла внесения изменений (обсуждаем, согласуем, разрабатываем, тестируем, обсуждаем, еще раз обсуждаем, еще раз обсуждаем, согласовываем, утверждаем, накатываем изменение, откатываем изменение, обсуждаем…)
Конечно, каждому из заказчиков самому решать какой уровень ему нужен. А разработчики интеграционных решений, возможно, в чем-то со мной не согласятся. Ну что ж, буду рад комментариям
Ещё бы картинки были бы читабельные.
Поддержу тезку насчет картинок, очень мелкие и практически нечитабельны. 🙁
Не нашел более качественных картинок. Чувствую, придется мне их самому перерисовывать. Займусь при случае.
http://images.cnblogs.com/cnblogs_com/zhoujg/201103/20110307190132277.png
Спасибо
Добрый день!
А скажите, когда есть 5 систем (у всех есть хорошее API, все системы в сетевой доступности и под контролем своих разработчиков), между которыми нужно синхронизировать 10 справочников по 100-1000 строк в 2-5 полей до 100 байт длиной, и изменений в них 50 раз в день на все 10 справочников и пересечение границ информационных систем бизнес-процессами происходит за дни, никакого реал-тайма, то нужна ли «очередь» для раздачи НСИ как у вас описано на 1-м уровне зрелости или можно спокойно оставаться на нулевом, делая все считанным количеством p2p для каждой мастер-системы?
Спасибо! )
Здравствуйте! API — это хорошо, но если у систем одинаковые СУБД, то справочники удобней синхронизировать встроенными средствами СУБД, типа oracle materialised view. Это, кстати, делается посредством встроенных очередей.
Если структура СУБД не понятна или сложно выделить мастер и т.д., то можно синхронизировать вызывая API. Я бы все равно делал это асинхронно, т.е. проводил бы обновления не в ходе операции добавления/изменения записи в справочнике одной из систем. Зачем в ходе такой операции вызывать пять систем вместо одной?
Использовать какую-нибудь легковесную очередь, взять сервис очередей из СУБД или просто складывать такие изменения в специальную таблицу и раздавать их потом отдельным процессом — решать Вам.