Примеры завершенных проектов по интеграции нескольких приложений крупных компаний пока еще весьма немногочисленны. Тем ценнее реальный опыт создания действующих систем на основе интеграционных платформ. Об особенностях проектов такого класса в ТТК (ЗАО «Компания ТрансТелеКом») рассказывает CIO компании Леонид Иванов.
Intelligent Enterprise: Какие причины вызвали необходимость масштабного интеграционного проекта?
Леонид Иванов: С 2002 года в компании работает биллинговая система Infranet производства Portal Software (США). Тогда это была самостоятельная фирма, в 2006 году ее поглотила Oracle и стала продвигать уже под брендом Oracle BRM. За пять лет эксплуатации системы у нас сформировалась собственная команда специалистов по поддержке и развитию — ведь и месяца не проходит, чтобы что-то в ней не менялось в связи с развитием услуг компании. Опыт эксплуатации накоплен значительный.
В 2006 году в связи с планами выхода ТТК на рынок междугородной и международной телефонной связи встал вопрос масштабирования биллинговой системы. Наших прежних (корпоративных) клиентов у нас несколько тысяч, а на новом рынке их десятки миллионов. Поэтому потребовалась биллинговая система, способная справиться со столь резким ростом объемов данных. Конечно, нам хотелось сохранить накопленный опыт, тем более что в Infranet мы не видели существенных изъянов, которые могли бы помешать нам организовать биллинг дальней связи. Увеличение производительности и объемов хранимой информации может быть обеспечено добавлением серверных ресурсов.
Переход Infranet в руки Oracle и дальнейшее продвижение системы этим вендором явилось для нас сигналом того, что это современное, «продвинутое» решение имеет длительные перспективы развития, коль скоро один из лидеров ИТ-рынка взял его под свое крыло. Конечно, как и везде, определенный монополизм в сфере ИТ опасен диктатом цен, но это общие издержки глобализации. Таким образом, мы решили использовать нашу биллинговую систему и в новых условиях, хотя на другой, более мощной серверной платформе.
Но при том, что система Portal в целом сделана очень красиво, продуманно и эффективно, у нее все же несколько слабоват пользовательский интерфейс. Для услуг нового типа требовались сотни агентов и дилеров по всей стране, но им было бы тяжело работать в системе. Когда стали искать выход, выяснили, что многие крупные операторы в других странах для устранения этого недостатка совместно с Portal применяют систему CRM, используя ее интерфейс для работы с биллингом. Мы узнали, что в Telecom Italia точно такую же задачу уже решали и в итоге сделали связку Portal — Siebel CRM, а между ними применили TIBCO BusinessWorks как интеграционную платформу.
Таким образом, для ИТ-поддержки работы компании на рынке дальней связи мы остановили свой выбор на конфигурации систем Oracle BRM, Oracle Siebel CRM с интеграционной платформой TIBCO ActiveMatrix BusinessWorks.
Но если у вас такая линейка решений Oracle, почему вы решили использовать не ее же интеграционную платформу?
Когда мы начали конструировать решение, Oracle еще не сформулировала концепцию развития своего пакета приложений для телекоммуникационной отрасли, в том числе и по интеграционной платформе. Эти планы прозвучали лишь осенью 2006 года, а мы своё решение принимали весной — летом 2006-го. Более того, так как все эти продукты, входящие в решение для телекома, были приобретены лишь недавно, еще не было проектов, демонстрирующих работоспособность подобных предложений в комплексе. Будут ли они работать все вместе? Если будут, то какой ценой? Ясности не было. А в Telecom Italia всю эту дорогу уже прошли и была уверенность, что в таком комплекте эти приложения интегрируются, причём хорошо.
Была и моя личная предыстория знакомства с платформой TIBCO. Еще за год до этих событий я познакомился с TIBCO и ее технологией. Впечатлила надежность этой платформы, применение ее в крупнейших по мировым меркам проектах и адекватные специалисты, способные отвечать на самые сложные вопросы.
Кроме того, у TIBCO есть еще одно чисто «айтишное» отличие: это ПО позволяет уйти от кодирования и выйти на уровень алгоритмизации. Существует графический интерфейс, позволяющий в терминах блок-схем описывать алгоритм работы системы. Можно сразу набросать структуру интеграционного решения. Для любой разработки ПО крайне важно, внося изменения в систему, сразу их документировать, тем более это критично для интеграционных решений. Предназначенные для этого инструменты TIBCO очень интересны архитектурно.
Ведь для интеграции двух ИТ-систем достаточно поставить задачу перед программистом, и рано или поздно он все соединит, так что данные будут передаваться из приложения в приложение. Формально это, конечно, интеграция, но до конца разобраться в том, что и как делается, может лишь сам разработчик. Средства TIBCO позволяют этого избежать, ведя разработку большей частью на уровне алгоритма. И хотя это продукт дорогой, но такая возможность, на мой взгляд, вполне оправдывает дороговизну.
А почему не WebSphere? Все же она более известна в России, чем решения TIBCO. И с технологической стороны это весьма «продвинутая» платформа.
На самом деле с точки зрения внедрений больше известна не WebSphere, а ее производитель, то есть IBM. Мы знакомились с этим продуктом, и меня WebSphere немного поражает своей «монструозностью». Мне нравится подход, если не ошибаюсь, авиаконструктора Туполева: красивые самолеты хорошо летают. Программа с красивым интерфейсом, продуманной логикой привлекает и даже завораживает. Ведь если разработчик пишет программу, то до графического интерфейса пользователя, как правило, он доходит в последнюю очередь. Если на уровне интерфейса у программного продукта все проработано, все сделано разумно и красиво, то резонно предположить, что и на уровне ядра системы проработано не хуже.
Старались ли вы выделять ИТ-сервисы в этом проекте, стояла ли перед вами задача декомпозиции приложений и реального перехода к сервисной архитектуре?
Пока мы ограничились интеграцией в рамках комплекса систем для поддержки дальней связи. В шине по сути дела две основные функции. Первая — это предоставление пользователям информации из различных систем. В нашем проекте в пользовательский интерфейс CRM-системы подтягивается информация из биллинга. Вторая часть — бизнес-логика. Нам было известно, что когда мы начнем оказывать услуги дальней связи, то состыковавшись с региональными операторами, мы должны получать абонентскую базу; работая с банками и платежными системами — получать от них информацию о платежах клиентов и так далее. Поэтому мы сразу поставили себе задачу организовать обработку такой информации через шину. Информация проходит через шину и вызывает некоторые действия: открывается лицевой счет, на него зачисляются платежи, данные передаются в бухгалтерскую систему... Но выделять такие сервисы в уже работающей системе значительно сложнее, чем с нуля.
В процессе внедрения мы ставили себе цель максимально вычленить «кубики», на которых можно было бы потом развивать систему. Вот, например, кубик «Получить от оператора файл с абонентской базой и загрузить ее в систему». Незначительно модифицируя его под очередного присоединяемого оператора, мы сможем обработать информацию в принятом им формате. Другой «кубик» делается сейчас для взаимодействия с платежными системами. Хочу подчеркнуть, что в проекте на основе TIBCO мы начинали с нуля, это было гораздо легче, чем работать с унаследованными системами. У нас было несколько систем, мы понимали, что с их помощью нужно сделать, и действия интеграционной платформы могли сразу спроектировать, расписать.
При этом в свою инфраструктуру мы TIBCO еще толком не встраивали. Однако в целом наш подход к интеграции очень близок к идеям ИТ-сервисов. У нас интеграция во многом построена на базе ядра WorkFlow, которое наши специалисты разработали на платформе IBM Lotus. На базе этого продукта в ТТК сделано очень много систем, так или иначе решающих задачу автоматизации документооборота. Их интеграция основана на следующих принципах. Есть объекты — заказы, договора, другие документы, которые отражаются в электронном виде записями в информационных системах. Если мы хотим, чтобы такой документ был обработан, то в процессе обработки он должен менять свое состояние. Если каждому состоянию объекта в реальном мире мы ставим в соответствие состояние документа в электронном виде, то при обработке он должен менять свой статус. Перевод объекта из одного состояния в другое производится действиями людей. Это мы называем «действием», action. В начале работы мы изучили ряд систем такого класса и немало идей взяли оттуда. Но философию мы несколько изменили: ведь во многих системах, поддерживающих WorkFlow, так и остается неясным, зачем же все это нужно. Если вы готовите к подписанию договор о сотрудничестве с контрагентом, ваша цель в самом подписании договора, а не в том, чтобы были выполнены некие манипуляции с ним. Для того чтобы быть подписанным, договор должен пройти ряд согласований, то есть менять свой статус. В зависимости от того, какие есть параметры у объекта (дата, время, кто визировал и пр.), можно попробовать нарисовать бизнес-правила и алгоритмизировать его обработку в зависимости от статуса и того действия, которое мы над ним в данный момент собираемся произвести.
Для пользователя при этом всё выглядит предельно просто. В какой бы системе, построенной на этом ядре, он ни работал с документом, у него в любом интерфейсе всегда есть одна и та же кнопка «WorkFlow-Действие». Нажав ее, он получает варианты последующей обработки текущего документа. Обычно их немного, два-три, и это результат автоматического анализа полей. Как только кнопка нажата, система начинает анализировать: какой документ, в каком статусе, кем обрабатывается и соответственно какие для него возможны дальнейшие пути следования.
В системе есть три типа сущностей: status (статус), action (действие) и activity (активность). Активность — это манипуляция с объектом, отсылка электронного письма, проверка содержания полей и их изменения по настроенному алгоритму. Активности реализованы на встроенном макроязыке IBM Lotus. Среди них есть те, что запускают взаимодействие с другими системами, например обращение к сторонним базам данным, запись в них какой-либо информации, формирование запросов к ним и пр.
Как сделана интеграция? Когда документ начинает движение по статусам, активности отрабатываются и происходит передача данных или иные взаимодействия. На базе этой философии мы автоматизировали множество бизнес-процессов. Поэтому можно уверенно говорить, что ТТК строит свою деятельность на процессной организации работы.
То есть интеграция поддерживает процессы в реальном времени?..
Да, интеграция хороша, когда она поддерживает действия людей. Я меняю статус: «договор подписан», — значит, в этот момент информация о его подписании должна транслироваться в бухгалтерскую систему. Если это не делается в реальном времени, придется эти отложенные действия выполнять по некоторому расписанию — скажем, ночью что-то отобрать, куда-то переслать. Это хуже, поскольку задерживает обработку информации в смежной системе. Как следствие, ввиду отсутствия требуемой информации может быть задержан платеж по договору. Мы считаем очень важным именно «онлайновую» интеграцию. Например, приходит клиент в какой-то наш удаленный офис. Он оформляет договор, и сейчас же в бухгалтерскую систему идет информация о том, что документ подписан, получен клиентом и скоро придут деньги в оплату подключения; в отдел эксплуатации идет информация о том, что возник новый заказ и скоро нужно будет подключать нового клиента по такому-то каналу, и так далее. То есть все, кто имеет отношение к реализации того или иного действия, моментально получают извещение об изменении положения дел.
Интеграцию мы применяем и для организации работы двух подразделений, занятых одним и тем же процессом — подключением нового абонента, — но разными его составляющими. Продавец вносит информацию о новом заказе, и сразу все базовые факты о нем отсылаются в систему, обеспечивающую работу технического подразделения. У них тут же запускается процесс подготовки к обслуживанию этого заказа, к подключению соответствующего канала связи. Когда клиент подключен, об этом немедленно информируется курирующий его менеджер продаж, но каждый отдел при этом оперирует только информацией, необходимой ему, а физически она хранится в разных базах данных. Попытка держать всю информацию о заказах в одной базе приводит к нежеланию подразделений развивать разделы, обеспечивающие работу соседей. Разнесение баз позволяет снять этот конфликт. Да и развивать системы так удобней: ведь у каждого подразделения свои требования, свои изменения процессов. Есть две базы данных с разными интерфейсами, разными правами доступа, и нам легче администрировать все эти системы. Это еще одна сторона интеграции: иногда лучше разбить данные на блоки и создать между ними связи, чем пытаться держать всю информацию в одном месте.
Интеграцию каких процессов вы планируете обеспечить с помощью интеграционной платформы, а какие останутся на старом решении?
В решении на базе IBM Lotus все хорошо за исключением одного момента. Бывают ситуации, когда внешняя система недоступна, но для меня факт передачи информации в нее не критичен, моего рабочего процесса он не тормозит, я могу идти дальше, а передачу информации повторить позднее. Значительно хуже, если без ответа внешней системы я сам уже двигаться не могу и должен ждать, пока восстановится связь. Тогда мне приходится организовать очередь таких неотправленных данных, вновь и вновь пытаться их отправить, а потом обрабатывать полученные ответы. До этого момента все хорошо и относительно просто, но как только я начинаю строить очереди на IBM Lotus (который для этого не предназначен), я практически начинаю строить интеграционную платформу. А в интеграционных платформах это давным-давно есть, все механизмы поддержки очередей уже сделаны. То же самое касается и разнесения на критические и некритические транзакции: в случае проблем с внешней системой отслеживается ее состояние, и как только она восстановится, можно повторить передачу информации. Есть протоколы, журналы транзакций. Так что при самостоятельном решении вопросов интеграции главное — вовремя остановиться. Не программировать то, что уже было до нас и неплохо сделано.
Кроме того, количество транзакций в новой системе неизмеримо больше, чем было раньше.
Поэтому в перспективе мы планируем перевести свои интеграционные разработки на промышленную платформу. А пока используем проект создания комплекса систем для дальней связи как базу для формирования этой культуры в ИТ-подразделениях компании.
Бизнес-процессы и интеграция — что первично? Из вашего рассказа следует, что процессы, автоматизированные на IBM Lotus, у вас давно и весьма полно описаны и формализованы…
Ситуация у нас сложилась несколько парадоксальная. Вначале мы провели анализ и разработали все эти алгоритмы, реализовали их в нескольких связанных ИТ-системах средствами IBM Lotus и таким образом автоматизировали обработку документов. И лишь потом процесс, существенно изменившийся относительно первичного описания, был задокументирован подразделением, отвечающим в компании за развитие бизнес-процессов. Мне кажется, что для этого лучше всего использовать язык блок-схем. Когда описание процесса положили на бумагу, объединив при этом пять систем и пять WorkFlow-схем, оно стало трудным для восприятия. Тем не менее такие документы тоже нужны, поскольку каждый новый сотрудник должен быть ознакомлен со стандартными процедурами. Теперь эти процедурные документы вид имеют примерно такой: делай первое, второе, третье, потом войди в систему и нажми такую-то кнопку, то есть бизнес-процесс очень тесно переплетается с использованием ИТ-средств.
Использование при такой автоматизации WorkFlow постепенно делает процессный подход общепринятым и понятным в компании. Те подразделения, у которых такие инструменты уже есть, начинают говорить с нами на одном языке, просят добавить статус, ввести дополнительные активности. Заявки на модификацию системы мы принимаем уже в виде блок-схем. Более того, и для сбора заявок у нас есть система поддержки ИТ-разработок, обеспечивающая нашу работу с той же кнопкой «WorkFlow-Действие», и запросы на модернизацию тоже обрабатываются вполне алгоритмическим образом.
Каковы особенности управления таким проектом? Оцениваете ли вы возврат инвестиций?
Реализация проекта была завершена в течение года. Проект был весьма сложным, в ходе работ приходилось уточнять бизнес-требования и корректировать постановку задачи перед интегратором. Моя задача как руководителя проекта была следить за тем, чтобы подрядчики — а это была компания «Микротест» — как можно меньше занимались классическим программированием и как можно больше функций реализовали средствами шины. Что касается возврата инвестиций, то выход компании на рынок массовых клиентов невозможен без организации эффективной ИТ-поддержки. Поэтому при разработке учитывалась и окупаемость системы. В стоимость проекта вошли большой серверный комплекс, СУБД, биллинг, CRM, интеграционная платформа, услуги интегратора. Общий бизнес-план выхода на новые рынки является долгосрочным. Пока мы не выходим за рамки заложенных нормативов.
Каковы планы развития проекта?
Компания ТТК собирается заняться широкополосным доступом в Интернет. Продажи, обслуживание и биллинг этого сервиса будут сделаны на тех же средствах. Другое направление — взаимодействие с внешними системами. С самого начала было решено, что взаимодействие с платежными системами осуществляется через шину. Сейчас мы делаем адаптер к платежной системе «Киберплат». Это позволит реализовать сложную логику взаимодействия систем. Ведь платежные системы позволяют организовать диалог с клиентом у терминала, и с помощью шины можно сразу организовать взаимодействие с целым набором наших приложений. Должно получиться красиво.
