Олег Подкопаев: На базе сложившейся архитектуры

Что будут делать банки в наступившем году в области ИТ? Какие проблемы и какими средствами станут решать? Своим видением ситуации в российских банках «первой сотни» делится Олег Подкопаев, председатель клуба банковских ИТ-директоров CIO Bank.

Intelligent Enterprise: Банковский сектор – один из самых старых и активных потребителей ИТ. Можно ли говорить о типовой ИТ-структуре крупного российского банка?

Олег Подкопаев: Банки уже привыкли рассматривать ИТ как один из своих основных производственных ресурсов и планировать развитие этого ресурса. У крупных банков стандартизируется и видение, и применяемые технологии. С высокой долей вероятности можно говорить о том, что типовая ИТ-структура современного российского банка сформировалась

Каналы взаимодействия банков с клиентами многообразны и в принципе не ограничены: от отделений, Интернета до самых современных разнообразных мобильных устройств. Бизнес-логика взаимодействия с клиентом рассматривается как единый слой с равным уровнем сервиса вне зависимости от канала взаимодействия, что позволяет предоставлять единый уровень обслуживания вне зависимости от канала доступа, с одной стороны, и с другой – существенно снижает сроки и затраты на внесение изменений и вывод новых продуктов и услуг.

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

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

Аналитика и отчетность: эти слои вполне сформировались, трудно представить банк первой сотни, где не было бы выделенного хранилища. Причем транзакционные и отчетные системы довольно четко разделились. Если раньше АБС имела в своем составе множество отчетов и шла постоянная конкуренция за производительность между транзакциями и отчетами, то теперь эти функции все больше и все чаще разделяются.

Интеграция является в этой архитектуре центральным звеном, связывающим вышеозначенные разнородные компоненты. При этом интеграция может реализовываться на различном уровне, начиная от уровня корпоративной шины до применения сложных BPM, хотя злоупотребление бизнес-логикой непосредственно на слое интеграции может оказать существенное влияние и на гибкость, и на производительность, и на эксплуатационные характеристики.

Через все эти слои проходит слой «продуктов и клиентов», поскольку банку необходимо на каждом уровне бизнес-процесса иметь полное представление о том, что он делает и с кем он работает. Также сквозным образом обеспечивается доступ к безопасности. Управление ею ведется по всей архитектуре банка централизовано, а не в каждом процессе, продукте отдельно.

Какими технологиями и продуктами, архитектурными подходами реализуется такая структура?

В области продуктовых систем виден переход к подходу «лучший в своем классе». Банки перестали искать универсальную АБС, покрывающую все, а смотрят на отдельные компоненты, возможно от различных поставщиков, которые наиболее удачным образом удовлетворяют их бизнес-потребностям. При этом для каждой компоненты есть специфичные бизнес-требования, которые включают функциональность, производительность и доступность. Фронтальные системы – те, которые работают с большим числом пользователей, от десятков до сотен тысяч в зависимости от размера банка, и требуют доступности 24х7. Бэк-офисные системы – это меньшее число пользователей, сотни или тысячи, и совершенно другой уровень доступности. Для них нет ничего страшного в технологических окнах.

Известно, что российские банковские приложения развивались как монолиты. Сейчас происходит их «раздирание на части». Плохо или хорошо это получается – пока сказать довольно сложно. Я знаю единственный хороший опыт в компании ЦФТ. У «Диасофта» я пока не видел хороших внедрений, хотя декларируется неплохая архитектура. При этом все равно происходит формирование практики на клиентах. Компании продолжают мало инвестировать самостоятельно. Их можно понять, поскольку риски существенные, угроза кризиса, и все это приводит к уже известному пути. Инвестиций для создания новой системы с нуля нет. Берут старую систему, разделяют на части, внедряют на клиенте, дорабатывают, и через некоторое время эта новая «инкарнация» признается достаточно хорошей.

Что касается производительности таких систем, то, несмотря на многочисленные тесты, случаев доказанной производительности мало. Принципиальным остается вопрос, на каком оборудовании достигается производительность, на каких «железках». Не каждый даже крупный банк может себе позволить поставить действительно мощный ИБМовский сервер.

В этой ситуации, как ответ на запросы российских банков, идет реакция поставщиков зарубежных специализированных систем. Ясно, что комплексные западные АБС в России не внедряются, в силу сложностей локализации. Но специализированные системы, например кредитный бэк-офис, с привязыванием его к другим действующим приложениям – такие связки внедряются хорошо. Иностранные вендоры ПО стали этим пользоваться и без больших вложений в локализацию проникать на рынок.

Внедрение западных решений обусловлено скудостью предложения российских продуктов и отсутствием практики их применения для действительно больших объемов, больших нагрузок. Западные – да, в целом они внедряются у нас плохо, но на Западе-то они работают, и работают на объемах, которых наших банки пока еще и не достигли. Поэтому есть смысл внедрять, поэтому и выделяется специальные accounting engine, который позволяет решить сложности с локализацией.

Что можно сказать о подходах к интеграции приложений?

Это тенденция – изменения в понимании сервисного подхода. Я считаю, что SOA и сервисный подход у нас только в стадии становления, значительной практики пока накоплено не было. Стандартом де-факто в банках является iBM WEB Sphere, далеко за нею – продукты Oracle, и потом уж все остальные. По мере использования накапливается негатив. Высока стоимость интеграции на этих продуктах, есть проблемы с производительностью и внесением изменений.

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

Очень серьезным фактором при интеграции становится BPM, а точнее – злоупотребление им. Если посмотреть на любую интеграцию через шину, то видно, что хотя ее обычно рисуют как «трубу», по сути это звезда. При отказе шины падает весь банк. Как бы ни были плохи парные интерфейсы между системами, шина – опасное узкое место. Как только вы начинаете ее нагружать бизнес-логикой, она начинает заметно проседать по производительности.

BPM – хорошая вещь. Но когда вы переносите бизнес-логику в шину, когда из специализированных систем переносите ее тоже в шину, то, во-первых, создаете единую точку отказа, а во-вторых, получаете монолит. Когда потом вам просто нужно вывести новый продукт на рынок, приходится тратить огромные деньги и много времени, чтобы что-то изменить.

Второй крупный минус сегодняшней реализации в SOA заключается в огромном числе сервисов. Я видел уже довольно много решений и могу сразу сказать: если система предоставляет тысячи сервисов – извините, это неуправляемо. Если идет переход на интеграционную шину, то общее число сервисов должно быть не более сотни. Тогда можно вести реальную оркестровку. Если же сервисов тысячи, нужно держать людей, которые будут следить за ними, управлять всем этим многообразием и изменениями в нем, а это практически неподъемная задача.

BI и хранилища: как развиваются они?

С хранилищами и аналитикой все гораздо лучше. В том или ином виде они присутствуют в каждом банке. Есть довольно много российских игроков с прикладными решениями, в том числе по МФСО, по очистке данных с конкретными применениями для российского рынка. Налицо и массированное проникновение западных производителей такого ПО, предлагающих тяжелые решения именно как инструментарий.

Существуют проблемы, связанные со сложностями в стандартных моделях данных, особенно в рознице, что не позволяет решениям работать напрямую с бизнесом. Приходится привлекать айтишников, чтобы добавить необходимые измерения. Другая общая проблема – хаос в данных и источниках. Если бы хранилища строились с нуля, то можно было бы считать находящиеся в них данные исходными и всю остальную информацию координировать с ними. Однако на практике приходится объединять множество различных источников, постоянно очищать данные, синхронизировать и т. д.

Существенно, что BI-инструментарий, который сейчас применяется, довольно сложен для бизнеса и требует навыка. Но положительный фактор – полное разделение информационных и аналитических систем. Это дает возможность развивать настоящие средства Business Intelligence. Бизнес получает возможность самостоятельно получать все более сложные отчеты, выявлять связи и зависимости без привлечения айтишников. Стали появляться локальные решения на базе сложных западных инструментариев, что важно, и в частности, подталкивает российских поставщиков подобных систем.

ИТ-аутсорсинг, облака и SaaS – есть ли здесь реальные изменения?

Если три-пять лет для банков ИТ-аутсорсинг был абсолютным табу, кроме, пожалуй, разработки ПО, то теперь он стал уже весьма распространенным. Это и аренда ЦОД, и отдельные услуги и сервисы, в том числе облачные. Пока они применяются в основном только для разработки и тестирования, но и это уже существенный шаг вперед. Недалек тот день, когда банки будут полностью разворачивать свои приложения во внешних облаках.

Для развития этого направления остается существенным препятствием облачная безопасность и ответственность поставщика сервисных услуг. Пока видно, что в облака могут и должны передаваться системы обслуживания клиентов, в том числе CRM и системы выдачи кредитов. Возможно, это начнется с банков мелких, поскольку именно для них это удачный момент: не вкладывая заметных ресурсов, получить сразу хороший функционал.

Наиболее общая тенденция – в банке все меньше и меньше будут заниматься ИТ-деятельностью. Собственная разработка, как правило, слишком дорога. Еще один важный момент – мобильные платформы. Уже сейчас практически любое фронт-офисное приложение работает на мобильных платформах. Степень покрытия, доступность приложений на всех возможных устройствах будет расти и дальше, плюс к тому появится все больше бэк-офисных приложений, тоже работающих с мобильными платформами, в первую очередь BI. При этом важным (и во многом нерешенным) вопросом остается безопасность мобильных устройств, и заниматься ею придется очень серьезно.

Переход к компонентной архитектуре взамен монолитной, миграция в облака, существенное снижение собственных разработок и вообще ИТ-работ – очень сильные тезисы и небесспорные, во всяком случае, они не выглядят близким будущим.

Эти тренды связаны между собой. Компонентная архитектура позволяет проще и лучше переходить к сервисам. Слияния в монолиты вновь не произойдет, скорее монолит будет пониматься как единый доступ к сервисам, получение их из одной «розетки». Их только надо будет правильно потреблять. А компоненты выносить в облако значительно легче, чем монолит. Компонентный подход влияет и на востребованность аутсорсинга. Банк занимается интеграцией: берет сервисные компоненты и связывает их так, как ему нужно. Ответственность поставщика – давать те сервисы, которые декларировались.

Материал подготовлен по докладу г-на Подкопаева на конференции «ИТ в финансовом секторе» AHConferences, декабрь 2011 г.