Интеграция на марше

Ольга Мельник

Задумывая очередную тему номера, посвященную интеграции ПО, мы не ставили своей целью показать наиболее передовые решения в этой области. Современные подходы к интеграции связывают с концепцией SOA. Анализ «не вооруженным статисткой взглядом» показал, что найти для данной темы номера проекты с реализацией SOA будет затруднительно. Новых проектов почти не появляется. Видимо, не всё идет так гладко и быстро, как планировалось интеграторами, поэтому даже те клиенты, об успехах которых нам обещали рассказать «прямо в начале весны», и к лету еще не были расположены говорить о достигнутом. Некоторую информацию о развитии уже описанных нами внедрений (см № 16/2007) мы собрали в статье «SOA — как много в этом…» (стр. 14). В результате эта тема номера получилась ориентированной на более традиционные методы интеграции приложений.

Какие же подходы к интеграции сейчас наиболее употребительны? Более реалистичным и явно более востребованным подходом, чем SOA, опирающаяся на многократно используемые ИТ-сервисы, остается внедрение интеграционных платформ как единой шины данных, как средства коммуникации между приложениями. Этот факт подтверждают два интервью этого номера с CIO компании «ТрансТелеКом» Леонидом Ивановым и начальником Управления информатизации города Москвы Алексеем Михайловым (соответственно на стр. 10 и 23). Наиболее используемым в своей практике подходом считают его опрошенные эксперты из «Ай-Теко» и «Апланы». Пи этом Алексей Добровольский, директор по разработке ПО компании КРОК, замечает, что внедрение единой шины данных можно рассматривать как один из шагов на пути к SOA, которую можно создать только плавным переходом, постепенно адаптируя процессы, системы и ИТ-инфраструктуру. «Задачи всегда должны решаться наиболее эффективным, подходящим для этого способом, без излишнего фанатизма и стремления использовать «самые инновационные решения», — считает он.

На второе по популярности место среди интеграционных подходов Дмитрий Грязнов, директор департамента программной интеграции компании «Ай-Теко», поставил «складирование» данных из нескольких систем в единое хранилище. Точной статистики по этому вопросу нет, однако опыт общения с ИТ-директорами показывает, что именно такой подход хоть и не является в чистом виде «методом интеграции приложений», все более применяется если не для создания единых информационных пространств холдингов и корпораций, то хотя бы для обеспечения доступности одних и тех же данных в нескольких приложениях сразу. Не теряет популярности и традиционный путь: связывание «каждого с каждым».

Особенности интеграционных проектов

Есть ли у интеграционных решений какие-то особенности по сравнению с другими ИТ-проектами? Дмитрий Грязнов называет три:

●     необходимо представлять себе работу интегрируемых систем, которые всякий раз могут быть разными;

●     в процессе выполнения проекта нужно минимизировать влияние на интегрируемые системы, чтобы не нарушить их текущую работу;

●     следует учитывать интересы и специфику подразделений, использующих интегрируемые системы.

Если два первых отличия являются скорее технологическими, то третье кардинально затрагивает взаимоотношения ИТ и бизнеса. От того, насколько удачно будут учтены интересы, прямо зависит успех всего предприятия. Как это делается в государственном и в коммерческом секторе экономики, мы обсуждаем в интервью, о которых говорили выше. Вопросам взаимодействия ИТ и бизнеса в интеграционных проектах посвящено и интервью Игоря Ковальчука из Московского банка реконструкции и развития (см. стр. 17). Заметим лишь, что технологические проблемы по сравнению с вопросом коммуникации и увязывания интересов кажутся легкими и приятными в разрешении.

Очевидно возражение: да где же тут специфика интеграционных проектов? Договориться — в любом ИТ-проекте самый сложный этап. Однако создается впечатление, что именно в интеграционных проектах найти общий язык удается технологическим способом. У «ТрансТелеКома» и Московского правительства и задачи взаимодействия, и технологические способы, к которым они прибегли для его организации, были совершенно разными, однако в обоих случаях решение лежало в области работы с данными, в области архитектуры.

Что касается двух первых технологических отличий, то Алексей Семенов, исполнительный директор «Кворум-Телекома», подчеркивает еще несколько связанных с ними обстоятельств. Еще на ранних стадиях интеграционного проекта, считает он, необходимо обозначить протоколы взаимодействия между приложениями, определить, как именно интегрируемые системы будут реагировать на новые входящие данные. Другими словами, надо понять, действительно ли таким, как предполагается и как требуется, будет результат, или же сделанные изменения приведут к изменению и самого результата. Подобное тестирование на ранних этапах касается как производительности, так и функциональности, подчеркивает Алексей Семёнов. Эта мысль — о предварительном тестировании и ранней проверке взаимного влияния связываемых систем — представляется интересной и достаточно нетривиальной. Пока о таком этапе в реальных проектах слышать не доводилось, но, может, потому, что чаще всего разговор шел о связывании «с чистого листа», как в проекте «ТрансТелеКома».

Михаил Македонский, исполнительный директор компании «Аплана», обращает внимание на то, что чаще всего приложения, функционирующие у заказчика, имеют свои особенности и недостаточно документированы для того, чтобы разработчик мог сразу проводить интеграцию. Предварительно их требуется изучить, протестировать и, как правило, осуществить частичный реинжиниринг имеющихся систем, напоминает он. Но реинжиниринг — это еще мягко сказано. Судя по частным беседам, потребности в интеграции могут приводить к очень серьезным изменениям вплоть до кардинальной замены приложений.

Интеграция и изменение бизнес-процессов

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

Алексей Семенов рассказывает, что получается на практике. Интеграционные проекты, по его мнению, можно условно разделить на две равные части. Одна половина — это интеграционные проекты, направленные на автоматизацию существующих «ручных» бизнес-процессов. И так как сам бизнес-процесс при этом изменяется незначительно, то реинжиниринг бизнес-процессов в таком случае не требуется. В другой половине проектов по сути происходит автоматизация самого бизнес-процесса, и его изменение или замена особенно необходима, когда проект связан с тремя, четырьмя и более системами. Возникающие проблемы связаны, как правило, с техническими ограничениями. Тогда инициируемые ИТ-отделом и изначально направленные на облегчение жизни бизнеса проекты зачастую приводят к необходимости пересмотра самого бизнеса. В таком случае за счет решения неких технологических задач усовершенствуется именно ИТ-составляющая. При этом сами бизнес-процессы могут подвергнуться детальным изменениям или же вообще будут заменены другими, соответствующими новому ИТ-подходу. К примеру, по завершении проекта может отпасть необходимость в некоторых сотрудниках или их функциях, может потребоваться пересмотр самого хода бизнес-процесса и так далее, поясняет Алексей Семенов. Чем менее формализованы, оптимизированы и управляемы бизнес-процессы, тем чаще возникает необходимость в изменениях, считает Алексей Добровольский. Хотя современные интеграционные решения и призваны обеспечить гибкость и быструю адаптацию, подчеркивает он, однако постоянное отслеживание и реализация изменений будет отвлекать от развития самого интеграционного решения. Интеграция приложений и автоматизация бизнес-процессов позволяют также упорядочить существующие процессы, создать основу для их развития и оптимизации. Многие компании уже достигли вполне высокого уровня зрелости своих процессов, и внедрение интеграционных решений на их основе позволит достичь большей производительности и эффективности бизнеса, считает он. Эта мысль очень мягко формулирует то, что явно проступает из докладов, интервью и бесед с ИТ-руководителями об интеграции: если с бизнес-процессами ясности нет, то не надо спешить их интегрировать. В самом лучшем случае проект растянется на то время, пока будет выясняться суть этих процессов, то есть кто, что и когда должен делать фактически.

Управление бизнес-процессами и их интеграция

Всем очень нравится красивый подход: есть формализованные процессы, описанные в ARIS, — например, установлена их однозначная связь с ИТ-системами, и когда нужно что-то изменить, мы это «что-то» просто меняем в описании, после чего адекватно меняются и ИТ-системы, и бизнес-процессы. Мечта! В общем виде ее очень изящно выразил один из спикеров Oracle Apps Forum: «Бизнес рулит». Очевидна автомобильная аналогия: когда вы хотите повернуть на ближайшем перекрестке направо или даже собираетесь поехать из Москвы в Петербург, вы же не бежите в сервис-центр к автомеханику с вопросами, что для этого нужно изменить в машине. Вы просто поворачиваете руль. Концепция слишком заманчивая для того, чтобы ее сразу отбросить как нереалистичную. Скорее всего именно таким и будет направление дальнейшего развития ИТ-систем. Но стоит вспомнить, что для модернизации такой простой вещи, как самодвижущаяся повозка с двигателем внутреннего сгорания, от того состояния, когда у водителя были десятки элементов управления, до нынешнего, когда их всего несколько, прошло более ста лет. А ведь это всего-навсего машина.

Однако уже появляются проекты, в которых на практике реализована связь информационных систем с бизнес-процессами: меняя одно, можно изменить другое, как это сделано в проекте «Одно окно» (см. стр. 23). Судя по намерениям, пресс-релизам и обещаниям, через пару лет таких проектов должно осуществиться немало. Еще один шаг в направлении большей, чем сейчас, управляемости — стремление к реальному времени. Как только данные изменились, все смежные системы получают обновленный вариант. Как только некое событие произошло — сменился ли статус, произошло ли нужное действие, — весть об этом сразу доносится до всех «заинтересованных ИТ-сторон». Заметьте: не ночью и не через какой-то временной промежуток. «Реальное время не является самоцелью. Это просто очень эффективно работает: сильно упрощается жизнь, если действие в одной системе сразу инициирует цепочку действий в других», — говорит Леонид Иванов, CIO «ТрансТелеКома». Ненадежность связи, нестабильная работа самих приложений, а главное, отсутствие бизнес-потребности в такой срочности не позволяли реализовывать подобные подходы раньше, за редкими исключениями. Строящиеся сейчас интеграционные решения все чаще подразумевают взаимодействие в реальном времени: именно потому, что три оговоренные выше препятствия постепенно исчезают.

Насколько важна готовность приложений к интеграции при их выборе?

Возможность интеграции приложения с другими системами — это очень важно. Но насколько большую роль эти свойства играют при выборе приложений? В исследовании «Практика использования ИТ на российских предприятиях», проведенном Intelligent Enterprise в 2005, 2007 и 2008 годах, мы занимались этим вопросом. В 2005 и 2007 году мы спрашивали: «Каковы по вашему мнению основные критерии выбора программного продукта» (рис. 1). Вопрос в 2008 году несколько отличался: «Как ранжируются критерии выбора программного продукта, используемые в вашей компании?» (рис. 2). В обоих исследованиях приняли участие около 150 ИТ-директоров из компаний, различающихся по отраслям, по видам деятельности и размерам бизнеса.

Рис. 1. Каковы, по вашему мнению, основные критерии выбора программного продукта?

Рис. 2. Как ранжируются критерии выбора программного продукта, используемые в вашей компании? (1 — минимальная важность, 3 — средняя, 5 — максимальная)

Прежде всего тройка первых по важности критериев и в 2005 и в 2007 году была одинаковой: функциональность ПО, требования архитектуры, платформы и интеграции с существующим в компании ПО, а также цена. И в 2005 и в 2007 годах абсолютно лидирует функциональность, что, наверное, и должно быть в подавляющем большинстве ситуаций. Однако относительная популярность критерия архитектуры, платформы и интеграции с существующим ПО в 2007 году стала заметно меньше (67% опрошенных в 2005 году и 50% — в 2007). Это можно трактовать и как большую свободу ИТ-директоров в создании нового архитектурного и системного ИТ-ланшафта, и как некоторое уменьшение трудоемкости интеграции, обусловленное, скорее всего, активным развитием инструментов этого класса. При этом наиболее важен этот критерий для крупных компаний, что собственно совершенно понятно. Ответы 2008 года подтверждают крайнюю важность критерия интеграции при выборе ПО. Наибольшую важность респонденты отдали функциональности, а далее с совсем небольшим отрывом — архитектуре, платформе и интеграции с существующим на предприятии ПО. По важности эти два критерия сильно отрываются от остальных (в том числе и цены) и фактически приближаются к максимальной оценке — 5 баллов.