Статья только в электронной версии журнала
ИНТЕГРАЦИЯ ПРИЛОЖЕНИЙ
Под термином "реинжиниринг" понимаются проекты, связанные с существенными изменениями программных решений. В этот класс проектов попадают инициативы по переносу систем с одной программной или аппаратной платформы на другую, по пересмотру архитектуры решения, перестройке базовых компонентов, модификации пользовательского интерфейса, созданию так называемых "оберток" вокруг унаследованных модулей для поддержки требований современных стандартов.
Когда речь идет о реинжиниринге ПО, ориентированного на средние или крупные предприятия, наиболее остро встает проблема обеспечения бесперебойной работы организации. Необходимо не только перевести большое число пользователей, эксплуатирующих старую систему, на новую с минимальным их отвлечением от основных обязанностей, но и осуществлять поддержку сложившейся инфраструктуры. В первую очередь требуется сохранить взаимосвязи между обновляемой системой и другими корпоративными приложениями, чтобы избежать разрывов информационных потоков (когда система является либо источником, либо потребителем данных) и потоков управления (в случае, если система вызывает другие приложения или сама активизируется извне либо выступает в роли инициатора событий, на которые реагируют другие программы).
Чтобы не перечислять массу различных конфигураций, складывающихся на реальных предприятиях, отметим крайние случаи. Например, во многих организациях явно или неявно выбирают одну из информационных систем, отвечающую за ключевые бизнес-процессы, и строят всю инфраструктуру вокруг нее. В других компаниях предпочитают разрабатывать множество подсистем вокруг центральной базы данных. В обоих вариантах формируется монолитная инфраструктура с высокой зависимостью от одной ведущей ИС. Еще одна крайность - использование множества систем с переплетением шлюзов и переходников: следить за такой конфигурацией сложно и изменение одной из систем чревато нарушением работоспособности всего комплекса по принципу домино.
Общая шина
Основная идея сказанного состоит в том, что на тот момент, когда будет принято решение о реинжиниринге одной из эксплуатируемых систем, в число ключевых требований непременно должно войти требование обеспечения (на период внедрения новой системы) обратной совместимости с упраздняемыми системами. Но зависимостей между приложениями может быть очень много. И для управления ими имеет смысл обратить внимание на интеграционные платформы, предоставляющие механизмы организации обмена данными и взаимодействия программных компонентов (обсуждение основных свойств этих платформ и имеющихся на российском рынке игроков можно найти в отчете RC Group "Методы и средства интеграции корпоративных приложений"). Отказываясь от связывания приложений напрямую и переключая потоки информации на единую интеграционную шину, можно как минимум изолировать приложение, требующее реинжиниринга или замены, и дальнейшую модернизацию производить без перепрограммирования смежных модулей, простым изменением настроек соответствующих коннекторов (подробнее о коннекторах и пр. см. PC Week/RE, N 35/2003, с. 37).
Стоит иметь в виду, что процесс внедрения обычно длительный и включает переходный этап, когда часть пользователей в режиме опытной эксплуатации работает с новой пилотной версией системы, а большинство остается со старой версией. И здесь интеграционная платформа способствует более простому решению проблемы. Достигается это за счет того, что шина обмена данными синхронизирует старую и новую базы данных в режиме, близком к реальному времени, или (если актуальность обновлений не критична) асинхронно, по заданному регламенту. Также интеграционная платформа берет на себя управление потоком сообщений и событий между внешними приложениями и обеими версиями модифицируемой системы. Как правило, эта задача решается встроенным в интеграционные платформы модулем управления процессами (workflow management engine, process automation module), посредством которого моделируется логика дублирования событий, ветвления потока данных и т. д.
В качестве примера из практики нашей проектной группы приведем внедрение CRM-системы в телекоммуникационном холдинге Golden Telecom. Мы начали проект в компании "Совинтел", но вскоре после этого он был приобретен Golden Telecom. В "Совинтел" функции ведения продаж были частично автоматизированы с помощью нескольких программ собственной разработки. В ходе предварительного обследования ИТ-инфраструктуры было предложено сопровождать проект внедрением интеграционной платформы, поскольку более 20 корпоративных приложений так или иначе должны были быть подключены к CRM-системе. Но затем "Совинтел" был приобретен Golden Telecom и началось его слияние с другим крупнейшим российским оператором фиксированной связи - "ТелеРосс". В результате этого рамки проекта значительно расширились, но благодаря применению интеграционной шины удалось с минимальными усилиями подключить системы, унаследованные от "ТелеРосса".
На момент запуска CRM-системы в промышленную эксплуатацию на шину обмена данными были возложены следующие функции:
- импорт исходных данных из заменяемых программ и поддержка актуальности данных на период совместного их применения с новой системой;
- синхронизация справочников и словарей по принципу публикации - подписки, где первым подписчиком стала CRM-система, а впоследствии подключились и другие;
- передача оперативных данных при непосредственном взаимодействии CRM-системы (front office) с другими системами (back office);
- сбор данных из приложений (в том числе дублирующих друг друга систем, оставшихся после объединения) в режиме "запрос - ответ" для представления всей информации по клиенту в портале CRM-системы.
На данный момент запланирован реинжиниринг следующих приложений, отвечающих за ключевые бизнес-процессы, и все они будут основаны на уже работающей в Golden Telecom интеграционной платформе.
Общее решение
Проект реинжиниринга может стать хорошей отправной точкой для построения всей ИТ-инфраструктуры предприятия на базе интеграционной платформы. На этапах анализа существующей системы и формулирования требований к новой самое время обратить внимание на следующие вопросы.
- Какая из систем является источником тех или иных данных? Где точки возникновения данных, их ввода? Есть ли двойной ввод? Какие потоки данных существуют между системами?
- Какие бизнес-процессы автоматизированы информационными системами и как? Где смежные точки, когда в рамках одного процесса задействовано более чем одно приложение? Насколько много ручной работы по переносу данных или активизации программ в ходе одного процесса?
- Как организованы автоматизированные рабочие места пользователей? Сколько клиентских приложений корпоративных систем необходимо запускать на своем "рабочем столе" тому или иному пользователю? Как часто приходится ему переключаться между окнами разных программ, чтобы выполнить одну бизнес-функцию? Приходится ли при этом копировать через буфер обмена или "перебивать пальчиками" ключевое значение объекта в разных системах (например, искать запись клиента в окне одного приложения по значению ИНН, скопированному из формы другой программы)?
- Как в целом и в частности у каждого приложения организована система безопасности? Есть ли общие списки пользователей? Поддерживается ли принцип единого входа в информационные системы предприятия (single sign-on), или пользователям приходится запоминать и использовать несколько паролей для разных приложений?
Вопросов такого рода немало, размышления над ними просто приводят к мысли о необходимости построения более общего решения или хотя бы выработки общих подходов и механизмов, которые можно будет повторно использовать при разработке или реинжиниринге ИС масштаба предприятия.
Как было замечено выше, невозможно обновлять хотя бы одно приложение без воздействия на другие компоненты всей ИТ-инфраструктуры. В этой ситуации интеграционная прослойка между существующими приложениями без их изменения может стать хорошей компромиссной альтернативой каскадным модификациям эксплуатируемых систем, особенно если требования бизнеса относятся к обеспечению стыков между ними.
В стратегическом плане перевод взаимосвязей корпоративных систем на общую интеграционную платформу позволяет изолировать отдельные приложения и управлять изменениями одной из них с минимальным влиянием на другие. В идеальном случае возможны реинжиниринг и полная замена одного из программных блоков по принципу "черного ящика", с которым интеграционная шина общается по интерфейсам входа и выхода.
В заключение надо признаться, что иногда сам проект интеграции корпоративных приложений может спровоцировать компанию начать проект реинжиниринга какой-либо из имеющихся систем. Ведь когда развязаны узелки взаимосвязей, перестройка решения становится ясной и доступной с точки зрения технической реализации, с позиций стоимости и длительности работ, а главное - появляется возможность оценить последствия.
С автором, менеджером по развитию бизнеса компании Vested Development, можно связаться по адресу: ArtakO@moscow.vdiweb.com.
