Наши знания о современных принципах интеграции часто ограничиваются критикой известного подхода, согласно которому обмен данными или объединение логики функционирования нескольких систем строится по принципу «один к одному». Формально более правильным подходом признается выделение некой централизованной структуры (называемой хабом, шиной, интеграционной платформой и пр.), ответственной за прием и передачу данных всех объединяемых систем, а также за их совместную работу — так называемую оркестровку. Далее концептуальные выкладки очень часто обрываются, а если необходимо более подробно разобраться с проблематикой интеграции, пользователю предлагается погрузиться в сугубо практические вопросы применения тех или иных технологий. В результате ряд промежуточных, и весьма важных, вопросов, предшествующих погружению в практику интеграции, остаются в лучшем случае осознанными неявно.
Дорогой ИТ‑сервисов
Начнем с организационной стороны вопроса, вспомнив, казалось бы, далекую от интеграции тему деятельности ИТ‑департамента. В третьей версии ITIL появились акценты на таких понятиях, как каталог сервисов и управление их жизненным циклом, благодаря чему сервисный подход как таковой оказался сформулирован куда более четко. Конечно, по тем или иным причинам не для всех компаний ITIL сегодня актуален, и уж тем более если речь идет о новой версии этого стандарта. Однако нельзя не признать, что в отношении подходов к ИТ-управлению на перспективу данная спецификация является законодателем мод. Далее определенный опыт экономической оценки функционирования ИТ-подразделения в различных ситуациях все более рельефно оформляется в виде лучших практик, также очень часто связанных с сервисным подходом. Речь здесь, например, может идти о так называемых разделяемых сервисах (shared services).
Можно предположить, что ИТ‑сервисы станут в будущем доминирующим термином в постановке задачи автоматизации бизнеса, а корпоративные системы с технологической точки зрения будут насыщаться адекватными внешними интерфейсами, к которым относится и концепция web‑сервисов. Собственно, это уже происходит, и так называемая компонентизация монолитных бизнес‑систем, технологическое разбиение их на отдельные сервисы — тенденция сегодняшнего дня.
Движение в сторону интеграции корпоративных систем с пространством Web 2.0 фиксируется сегодня далеко не единодушно. Но если это все‑таки будет происходить, далеко не все требуемые сервисы смогут быть взяты из внутренних бизнес‑систем. И чем сильнее это будет выражено, тем более явно будет выходить из употребления все еще достаточно популярная на практике (а в нашей стране тем более) технология точечной интеграции.
Вторая характерная черта включения внешних сервисов в ландшафт корпоративной автоматизации связана со способностью современных инструментов осуществлять динамичную интеграцию. Дело в том, что создавать статическую конфигурацию интегрируемых функций в этом случае практически бессмысленно. Требования к ее изменению будут возникать постоянно, а реализованные изменения в свою очередь будут приводить нас к вопросу об актуальности имеющихся бизнес-процессов.
И наконец, в‑третьих, если какой‑либо информационный срез данных внешнего Интернет-пространства и окажется востребован, то скорее всего ему будут соответствовать неструктурированные данные. Адекватно вписать их в традиционный информационный ландшафт бизнеса по меньшей мере сложнее технологически, что опять‑таки должно дать фору промышленным платформам интеграции. Хотя большинство популярных ныне Интернет-ресурсов, относимых к направлению Web 2.0, имеют в своем арсенале программные интерфейсы разработчика, необходимые для интеграции.
Все сказанное выше отчасти проясняет вопрос о целесообразности интеграции через единую платформу. Такая интеграция по крайней мере гарантирует куда более технологичный подход в случае множества динамично стыкуемых между собой сервисов, чем «точечная». Но практически ничего не говорится о более тонких моментах — например, о вопросе содержательных различий между Business Process Management (BPM) и технологией, определяемой в настоящее время как интеграционная платформа. Ведь оба этих направления, по сути, являются средством интеграции бизнес‑систем, и оба относятся к классу современных инструментов.
Процессный подход меняет требования
Пока речь шла лишь о том, как новые подходы к управлению ИТ и некоторые технологические изменения могут подтолкнуть нас к использованию сервисного подхода и, как следствие, к определенным приемам интеграции ИТ‑систем. Теперь поговорим об изменении в управлении самим бизнесом, приводящем, по сути, к тому же.
В этой связи вспомним идею автоматизации, непрерывно покрывающей собой деятельность нескольких юридически и территориально разделенных предприятий, объединенных вместе с тем единым бизнес-процессом. Идея эта, хотя и стала почти что банальной, все равно не теряет своей важности. Развитие подобного направления существенно сдерживается известным консерватизмом отдельных участников таких цепочек в отношении работы с информацией. Однако и здесь намечается прогресс — пока большей частью в виде совместных портальных решений, за которыми мало-помалу подтягиваются ИТ-решения, отражающие логику совместных бизнес-процессов. Речь здесь, очевидно, идет о процессном управлении, за которым чуть менее явно просматривается тот самый сервисный подход в автоматизации. Не так очевидны некоторые следствия процессного подхода, касающиеся тем не менее вопросов интеграции приложений.
Например, можно говорить об изменении концепций пользовательского интерфейса, или, более конкретно, о том, что в условиях доминирования процессного подхода более удобным и востребованным становится и объектноориентированный интерфейс. Иными словами, гораздо более важной становится возможность просматривать, скажем, и ретроспективу выполненных бизнес-транзакций, и историю переписки (осуществляемой самыми разными средствами — от почты и документов до голосовых сообщений) в контексте истории взаимоотношений с конкретным клиентом, поставщиком, в контексте исполнения произвольного заказа и пр. Осуществить все эти, казалось бы, несложные вещи чрезвычайно трудоемко для привычной точечной интеграции. Здесь по меньшей мере желательно иметь специальные технологические средства в составе интеграционных решений.
Еще одно следствие процессного подхода в автоматизации можно напрямую связать с применением так называемого ориентированного на события (event driven) подхода к управлению. Дело в том, что в условиях среды, меняющейся по определению более динамично, чем при автоматизации единственного предприятия, мы сталкиваемся с необходимостью «живого» обсуждения ситуации и возможности «вручную» вмешиваться в процесс.
И, наконец, еще об одной важной особенности. Всем известно, какую помощь призваны оказывать современные ИТ‑системы в поддержке основных бизнес-процессов, будь то планирование на производстве, урегулирование убытков в страховой компании или постановка логистических процессов розничной сети. Причем со временем в каждой ситуации появляется новый потенциал ИТ-поддержки, чтобы в конечном итоге начать действовать с большей интенсивностью, с более детальным учетом производственных условий и с более богатыми возможностями в отношении динамической реконфигурации процессов. За этим очень часто следует потребность в документарном (а в более общем случае — контентном) сопровождении. Основная система поддержки бизнес-процессов, как правило, уже не может его обеспечить. В этом случае бизнес сталкивается с необходимостью иметь мощное промышленное ядро (или, по‑другому, движок) интеграции, которое можно привязать к конкретному бизнес-процессу, как правило, емкому в отношении сопровождающих его информационных потоков.
Почему BPM?
После сказанного вернемся снова к продуктам. Первыми появились интеграционные платформы, позволяющие развязать запутанные связи (их часто называют «спагетти») преобладавшей еще лет десять-пятнадцать назад интеграции по принципу «один к одному». Это направление стартовало с одного из самых первых шагов, сделанных в свое время в сторону масштабирования логики корпоративных вычислений, — с создания трехуровневой архитектуры систем и явного выделения серверов приложений. В дальнейшем, сообразно возникающим в мире корпоративной автоматизации проблемам, задачи масштабирования, решаемые серверами приложений, были в значительной степени замещены задачами интеграции. Позже появилась и получила широкое распространение концепция адаптеров для связи серверов приложений с различными системами для ряда продуктов данного класса. Тогда и появился новый термин — «интеграционная платформа». А «проблема спагетти» в значительной части была решена еще в начале этого века.
Вместе с тем многие из отмеченных выше проблем (во многом связанные именно с процессным управлением, но не только) оставались. В этой ситуации внимание постепенно переключается на системы класса Business Process Management, о которых сейчас много говорят.
В отличие от «классических» интеграционных платформ они, в известном смысле унаследовав интеграционный функционал, добавили к нему и новые функции: инструменты моделирования бизнес-процессов, так называемый процессный движок, средства оперативного мониторинга хода процессов, а также некоторые средства (в виде, например, развитых возможностей работы с электронными формами), позволяющие влиять на их исполнение в режиме «ручного управления». В целом именно этих функций долгое время и не хватало бизнесу, осознавал он это напрямую или нет.
Здесь также уместно сказать и о классификации BPM‑систем, сделанной в свое время компанией Fоrrester Research и до сих пор, пожалуй, наиболее популярной. Речь идет о так называемой интеграционно-центрической (Integration centric BPM — IC BPM), а также ориентированной на взаимодействие персонала компании (Human centric BPM — HC BPM) моделях BPM‑систем. По мнению все той же Forrester, первая категория систем «растет» со стороны производителей платформ интеграции корпоративных приложений и отчасти производителей ERP‑систем (см. рис.). Среди таковых выделяются гранды софтверного направления ИТ-индустрии (например, IBM, SAP, Oracle, Software AG и некоторые другие).
С другой стороны движется гораздо более многочисленный отряд, хотя, быть может, в его состав входят менее именитые и крупные компании. Из того же рисунка ясно, что речь здесь идет о компаниях, имеющих давнюю историю работы с документами и неструктурированным контентом.
В итоге благодаря BPM к сегодняшнему дню мы имеем ситуацию, при которой:
- основные требования процессной, динамично проектируемой и реализуемой интеграции в целом оказываются выполненными;
- благодаря специфической картине становления BPM-концепции в ее развитие вовлечено подавляющее большинство ведущих производителей корпоративного ПО, а такое единодушие на рынке складывается не так уж часто.
Три составные части
Будем опираться опять‑таки на представленную диаграмму. Она позволяет заметить, что, решая многие вопросы интеграции систем, концепция BPM развивается так, что накрывает собой сразу два направления. Они, в свою очередь, традиционно играли главенствующую роль в автоматизации бизнеса, хотя при этом существовали в значительной степени параллельно. Речь идет об управлении структурированной и неструктурированной информацией, и поэтому связка трех продуктов класса ERP, Enterprise Content Management (ECM) и Business Process Management (BPM) на сегодняшний день является, пожалуй, наиболее функционально полной, охватывая все возможные задачи современного предприятия. Подобные связки уже реализуются на практике в виде тесно увязанной технической (равно, впрочем, как и маркетинговой) политики разных поставщиков в отношении развиваемых ими систем. Например, один из самых заметных альянсов — сотрудничество SAP с компанией OpenText, где последняя выступает в качестве производителя ПО класса ECM, а SAP соответственно как компания, предоставляющая не только ERP, но и BPM-функционал посредством платформы NetWeaver. Есть также прецедент тесного сотрудничества одного из столпов BPM-рынка компании Lombardi с компаний Infor.
С помощью такой интеграции (а возможно, лишь такой) предприятия не только получают самые богатые возможности документарного сопровождения ориентированных на процесс бизнес-транзакций, о которых мы говорили. Они способны пойти немного дальше. Дело в том, что как только контент перестает ассоциироваться исключительно с внутренними информационными ресурсами, тут же само понятие «документ» перестает быть безоговорочно доминирующим. Скорее речь идет о некоем «досье», составленном из разных лоскутов информационного поля, которое включает, кроме документов, электронную почту, источники электронной информации вне компании, ресурсы Web 2.0 и прочее. То, что это проблема не сегодняшнего, а завтрашнего дня, не меняет сути.
Бинарный подход
Олег Оленин
Технический консультант, InterSystemsИ оптимизация бизнес-процессов, и реализация масштабных интеграционных проектов, связанных с внедрением BPMS-решений, — все это требует времени и относительной стабильности, пусть даже такая стабильность будет проявляться в устойчивом стрессе. Сегодня еще рано искать некий новый глобальный тренд, связанный с интеграцией на предприятиях.
Требования к интеграционным решениям ужесточаются. Главным становится выбор технологии, которая обеспечит решение конкретных в данный момент вопросов интеграции качественно и в срок. Подход к выбору платформы интеграции становится прагматичнее.
Качество стало приоритетом номер один. Однако что же подразумевать под качеством? Системы либо интегрированы, либо нет. Процессы или внедрены и работают, или создается видимость их работы. В таком бинарном варианте может быть лишь один критерий качества — начало ли решение работать в заданные сроки. Как вендор старой школы, мы не можем не радоваться такому подходу.
Платформенная интеграция не исчезла
Дмитрий Зайцев
Руководитель Центра заказных разработок компании «Аплана»В период кризиса многие компании начали оптимизировать внутренние процессы с целью снижения операционных издержек, и интеграционные проекты стали особенно востребованы. Ведь они позволяют навести порядок в ИТ-инфраструктуре, снизить затраты на последующее сопровождение. Важно, что интеграционные проекты дают возможность провести подготовительные работы, чтобы сократить последующие затраты на внедрение и интеграцию соответствующих решений различных производителей. В дальнейшем эти решения будут выбраны в качестве замены существующих устаревших модулей.
Из кризиса многие компании выйдут с более системным подходом к развитию существующей ИТ-инфраструктуры. Интеграционные процессы — это один из эффективных способов оптимального использовать существующие ресурсы и подготовить их к последующей замене (развитию) в более удачное время. Мы выполнили в период кризиса несколько интеграционных проектов с применением промышленных интеграционных шин на базе ПО с открытым кодом, в том числе JBoss Enterprise Middleware, в составе которой есть удачное решение JBoss Enterprise SOA Platform.
