Альфабанк ведет масштабные интеграционные проекты уже несколько лет. Михаил Коленкин, первый заместитель директора по ИТ, рассказывает о том, каким подходам и концепциям следует банк на этом пути.
Intelligent Enterprise: Когда ваша организация ощутила реальную необходимость ревизии архитектуры?
Михаил Коленкин: Это произошло примерно три года тому назад, когда количество систем и интерфейсов между ними выросло настолько, что у нас возникли проблемы в управлении ИТинфраструктурой. Система стала слишком сложной, чтобы в ней оперативно производить необходимые изменения. В одном бизнеспроцессе могут быть задействованы десятки различных приложений, обменивающихся друг с другом данными через интерфейсы, и если нужно изменить этот процесс — а в современном мире такая потребность возникает нередко, — то приходится вносить изменения как в приложения, так и в интерфейсы. Каждый раз при внедрении новых банковских продуктов мы упирались в проблему многочисленности и разнородности интерфейсов, сложности их отладки и в конечном счете теряли время. А время вывода продукта на рынок критично в напряженной банковской конкуренции. Мы поняли, что основным источником проблем является сложность нашей информационной системы. Сложность не только в смысле количества подсистем, но и в смысле топологии интерфейсов и многообразия их реализации. По сути мы имели дело с так называемой «спагеттиинтеграцией», которая всегда возникает в отсутствие стандартов на интерфейсы или при слабом архитектурном надзоре за разработчиками. Осознав суть проблемы, мы приняли решение целенаправленно снижать уровень сложности нашей информационной системы.
Какие шаги вы для этого предприняли?
Мы обратились за помощью к нескольким вендорам, предлагающим промышленные решения. Предложение IBM оказалось наиболее интересным для нас. В рамках BIVA (программа Business Integration Value Assessment. — Прим. ред.) консультанты из IBM провели обследование нашей системы и насчитали у нас более трехсот пятидесяти интерфейсов в промышленной среде. В среде тестирования было более тысячи интерфейсов. В общей сложности оказалось, что мы управляем более чем полутора тысячами интерфейсов. Основываясь на результатах обследования, консультанты оценили, какой выигрыш мы можем получить в случае перехода на новую архитектуру. За счет стандартизации интерфейсов и уменьшения количества обслуживаемых платформ должна уменьшиться общая стоимость владения интерфейсами. Кроме того, выигрыш состоял в сокращении стоимости и времени разработки новых интерфейсов. И еще мы получили оценку ROI, что очень важно, поскольку создание новой платформы и переход на нее требует серьезных инвестиций. Оценки оказались, как показывает теперь практика, оптимистичными, но все же близкими к реальности. В соответствии с рекомендациями вендора в качестве интеграционной платформы мы выбрали семейство продуктов IBM WebSphere и в первую очередь Web Sphere Business Integrator (WBI).
Как вы расставляли приоритеты?
Расстановка приоритетов при внедрении существенно зависит от условий финансирования. Если для ИТдепартамента выделен бюджет на развитие и совершенствование архитектуры, то внедрение новой платформы можно начинать с наиболее критических областей — там, где интерфейсы нестабильны, плохо масштабируются или морально устарели. В противном случае, разумеется, надо искать заказчика в бизнесподразделениях и выбирать такие области, где быстрее и убедительнее достигается значимый для заказчика результат.
Нам удалось получить выделенное финансирование на интеграционные проекты, поскольку ИТдепартамент предварительно разработал долгосрочную стратегию развития информационных технологий, в которой была явно обозначена роль новой интеграционной платформы в достижении стратегических целей предприятия. Стратегия была утверждена руководством банка, что и позволило получить необходимый для данной работы бюджет.
На первом этапе мы провели пилотный проект, перед которым было поставлено несколько задач. Вопервых, мы хотели убедиться, что новая платформа действительно масштабируема. Поэтому была поставлена задача заменить существовавший тогда интерфейс между двумя банковскими сиcтемами — новой, Equation, которую мы только внедряли, и выводимой из эксплуатации старой, системой на основе СУБД Informix. Этот интерфейс был принципиально немасштабируемым и потенциально ограничивал объем перекачиваемых данных. Вовторых, требовалось получить подтверждение, что новая интеграционная платформа способна работать со всеми важными системами, используемыми в банке. Поэтому мы выбрали для замены несколько интерфейсов, которые связывали между собой системы на основе OS/400, HP Unix, MS Windows и работали с СУБД DB2 и Lotus Notes. Кроме того, нужно было убедиться, что IBM WBI в состоянии решать сложные задачи по передаче данных с их трансформированием по определенным правилам, а также проверить возможности по созданию Webсервисов и ESB (Enterprise Service Bus, корпоративная шина данных). Другими словами, мы подвергли проверке все аргументы, которые приводила компания IBM, убеждая нас приобрести WBI. Результаты пилотного проекта оказались положительными.
На следующем этапе мы развернули платформу IBM WBI на основе AS/400 и произвели замену целого ряда критически важных интерфейсов. На этом этапе основная задача состояла в том, чтобы получить экспертизу в проектировании интеграционных решений и их сопровождении.
Затем мы приступили к созданию сервисноориентированной архитектуры. ИТдепартамент разработал концепцию использования интеграционных решений в банке, которая выделяет четыре сегмента в спектре возможных интеграционных решений и для каждого из них определяет необходимые инструментальные средства. Например, для создания информационных сервисов, где основной результат заключается только в чтении данных, рекомендуется использовать Webсервисы на основе IBM WebSphere Application Server (WAS), а для целей перекачки данных с их трансформацией следует применять WBI. Кроме того, концепция предусматривает использование таких средств, как IBM WAS ESB и Process Server, для определенного класса задач.
На этом этапе мы изменили подход к выбору задач по интеграции. К числу наиболее приоритетных стали относить те задачи, при решении которых можно было добиться значимых для бизнеса результатов. Например, ускорения вывода на рынок новых продуктов. Проанализировав планы развития бизнеса в среднесрочной перспективе, мы определили, какие сервисы потребуются в ближайшее время, и приступили к их созданию заблаговременно с тем, чтобы иметь готовые сервисы к тому моменту, когда они будут востребованы. Мы не ставили задачу замены подряд всех интерфейсов, которые приносят массу хлопот ИТдепартаменту. Гораздо важнее, как мы считали, было сыграть на опережение, чтобы продуктивность нового подхода стала очевидной для бизнесзаказчиков.
В результате мы своего добились: теперь переход на сервисноориентированную архитектуру в значительной мере финансируется из бюджетов конкретных бизнеспроектов.
Что же касается проблемных интерфейсов, то если какойто старый интерфейс становится слишком ненадежным, мы его скорейшим образом заменяем в рамках централизованной программы по совершенствованию архитектуры. Чаще всего проблемы возникают изза недостаточной масштабируемости. Некоторые параметры, такие как число транзакций или число счетов в определенных приложениях, за год могут вырасти в несколько раз — таков уж рост нашего бизнеса.
Насколько вы уже продвинулись в направлении SOA?
Мы спроектировали несколько десятков базовых сервисов, и большая часть из них уже реализована. Оркестровка этих сервисов в настоящий момент осуществляется посредством IBM WBI. Они построены главным образом для нужд розничного бизнеса, развивающегося сейчас наиболее динамично. Однако сервисы эти спроектированы таким образом, что в дальнейшем будут использованы и для задач корпоративного и инвестиционного бизнеса.
Проектирование базового набора сервисов — это очень масштабная и ответственная работа для команды архитекторов. Для начала необходимо проанализировать существующие в системе интерфейсы, выделить дублирующиеся, часто повторяемые блоки. Затем нужно сгруппировать их, придать им универсальность, сохранив в то же время необходимую специализацию. Например, у нас есть системы, которые обслуживают ипотеку, автокредитование и другие виды розничного кредитования. Все они поддерживают процессы выдачи кредитов физическим лицам, во многом состоящие из одинаковых элементов, таких как скоринг, верификация, оформление кредита. Но в каждом случае существует и определенная специфика — скажем, в комплектности документов, в формах заявок, во временных рамках обслуживания клиентов. Базовые сервисы, которые поддерживают кредитный процесс, должны быть, с одной стороны, достаточно универсальны, но вместе с тем и учитывать специфику каждой реализации этого процесса. Построив базовый набор сервисов, можно сконструировать практически любой бизнеспроцесс, используя для этого шину передачи данных и инструментальные средства оркестровки Webсервисов.
Важнейшей задачей при построении SOA является установление архитектурного контроля за разработками поставщиков программного обеспечения. Без такого контроля поставщики будут реализовывать заказанные им разработки с помощью тех технологий и в той архитектуре, которые им удобны и в которых они обладают наибольшей экспертизой. Наш контроль заключается в том, что требования по архитектуре передаются поставщикам. Мы передаем им свою документацию по нашей архитектуре, описание существующих Webсервисов, а в ряде случаев даже имитаторы этих сервисов, чтобы они могли проверять работоспособность собственных продуктов в своих тестовых средах. Новые создаваемые ими модули и приложения будут подсоединяться к нашим системам в основном через Webсервисы, разработанные нами.
На пути к SOA мы пока прошли не более четверти дороги, основные работы по переходу будут длиться еще дватри года. Но уже сейчас видно, что интерфейсы на одной платформе проще обслуживать, проще отслеживать их состояние, и мы реально получаем выигрыш во времени при реализации новых продуктов.
Кто занимается выделением и разработкой сервисов?
Проектированием Webсервисов занимается наша команда архитекторов. Разработка же кода полностью передается вовне (подрядчик — компания «Синимекс», они же вели наш проект перехода на WebSphere). Сопровождение осуществляется внутренними силами.
Следует отметить, что архитектура определяет практически все существенные макрохарактеристики крупных и сложных информационных систем — надежность, доступность, масштабируемость, модифицируемость, а в конечном счете — отношение бизнеса к ИТдепартаменту и его руководителям. Если изза архитектурных ошибок инфраструктура постоянно сбоит, её дорого обслуживать, системы ненадежны и невозможно быстро произвести необходимые изменения, то как бизнес будет оценивать работу ИТслужб и их руководителей? Поэтому все архитектурное проектирование и анализ мы оставляем за собой.
Для вас SOA — одна из удобных технологий или стратегическое направление развития ИТ в целом?
Для бизнеса важна в первую очередь низкая стоимость владения, а также непрерывность бизнеспроцесса: чтобы данные не терялись и не искажались при передаче от приложения к приложению. Не менее критична возможность быстрого вывода новых банковских продуктов на рынок. На эту скорость и на качество работы с данными прямо влияет применение SOA, поскольку при переходе к ней мы заменяем несколько интерфейсов одним универсальным Webсервисом, а интеграция новых решений в банковскую систему заключается только в подключении к уже отлаженным и внедренным сервисам.
Осознание того, что архитектура ИТсистемы — это фактор, влияющий на развитие бизнеса, приходит только на определенном уровне развития компании и ее инфраструктуры. Для организации, в которой тысячи пользователей работают с сотнями взаимодействующих систем, он абсолютно критичен. Известный скепсис по отношению к SOA в России отчасти вызывается тем, что многие предприятия просто еще не достигли критического масштаба, когда проблемы архитектуры становятся реальностью и без SOA дальше двигаться уже невозможно. Мы воспринимаем этот подход как магистральный, объективно необходимый для всех крупных организаций, в том числе и для Альфабанка.
