Журнал "Банковские технологии" опубликовал статью "О перспективах технологического развития банков"
Вряд ли для кого-то является тайной стремление подавляющего большинства организаций быть "современными", "идти в ногу со временем". Вместе с тем понятие "современный" весьма и весьма размыто. Сегодня мы бы хотели поговорить о конкретном аспекте проявления современности - о технологическом развитии.
Что собой представляют "современные" банки в плане технологий? Для ответа на этот вопрос необходимо определиться с векторами технологического развития. Очевидно, что развитие IT-инфраструктуры представляет ценность для банка только в случае, если оно направлено на решение конкретных бизнес-задач. Из всего спектра бизнес-задач, которые могут быть поставлены владельцами и руководством банка, рассмотрим задачи продвижения банковских продуктов - актуальные и популярные, не правда ли?
Итак, если принять во внимание актуальность задачи продвижения продуктов, IT-инфраструктура со своей стороны должна:
2. Поддерживать любое изменение продуктовой линейки (в основном это касается появления новых продуктов и услуг);
3. Способствовать снижению прямых и косвенных затрат на обслуживание существующих продуктов.
Банк, обладающий такой IT-инфраструктурой, по праву может считаться технологически развитым.
На этом тему можно было бы закрывать, если бы не проблема, которая заставляет взглянуть на пути технологического развития банка под иным углом зрения. Особенностью практически всех систем (как российского, так и западного производства), на которые опирается IT-инфраструктура российского банка, является концентрация на решении ограниченного количества задач банковского бизнеса. Специализированный рынок автоматизированных банковских систем не предлагает единого решения, которое бы удачно закрыло все направления деятельности банка, нуждающиеся в автоматизации. Один разработчик предлагает специализированное решение для карточного процессинга, другой - мощную скоринговую систему, третий - систему дистанционного банковского обслуживания физических лиц класса интернет-банкинг. Четвертый предлагает комплексную систему автоматизации банка, но при ближайшем рассмотрении модуль по учету ценных бумаг по функционалу не выдерживает никакой критики…
Таким образом, в банке одновременно в эксплуатации находятся специализированные системы разных разработчиков, каждая из которых отвечает за определенный набор функций автоматизации банковской деятельности.
Так что же с критериями технологического развития? В теории к определению успешной IT-инфраструктуры добавляется требование "функционировать в условиях эксплуатации различных специализированных систем от разных разработчиков". На практике же это требование приводит к полному переосмыслению направления (или вектора) технологического развития банка.
Итак, в банке несколько систем и, будучи разработаны разными командами, они разные. Но в них все же есть одна общность: все они - часть IT-инфраструктуры одного банка. Обеспечить их мирное сосуществование - необходимая задача. Мы же затронем аспект, когда мирное сосуществование нескольких систем осложняется необходимостью их взаимодействия друг с другом.
Посмотрим, какие способы обеспечения взаимодействия систем предлагает нам современная IT-отрасль. Но сначала перечислим причины, по которым необходимо организовать это взаимодействие.
1. Использование системой результатов функций других систем для реализации собственных функций;
2. Использование системой данных, "подготовленных" другими системами;
3. Использование одних и тех же данных в разных системах;
4. Использование системой информации о событиях, произошедших в других системах.
Подчеркну, что это разделение произведено условно, так как в принципе первую причину (использование системой результатов функций других систем) можно считать универсальной. Но для прикладных целей я позволю себе остановиться на такой классификации.
Итак, рассмотрим способы обеспечения взаимодействия.
Первый способ. Система обеспечения взаимодействия в каком-либо виде отсутствует, все интеграционные функции (на них мы подробно остановимся позднее) берут на себя пользователи этих систем. Пример из жизни: копия распечатанного валютного платежного документа (прошедшая электронные и визуальные виды контроля, проштампованная, подписанная) передается оператору S.W.I.F.T.-терминала для ручной отправки.
Основные недостатки:
- при больших объемах обеспечение становится очень дорогим; - невозможно увеличить пропускную способность такой системы взаимодействия (хотя бы в 3 раза) без организационных изменений; - чрезвычайно высокое влияние человеческого фактора, возникновение ошибок.
Но есть и достоинства:
- низкие стартовые вложения для обеспечения взаимодействия; - почти безграничная гибкость при изменении в технологиях (качественных, не количественных); - высокая отказоустойчивость при возникновении внештатных ситуаций.
Второй способ. Пакетно-файловая передача данных от одной системы к другой. Данный способ предполагает, что одна система может формировать файловые пакеты данных ("выгружает в файл"), вторая система позволяет эти пакеты обрабатывать ("загружает из файла") и действует регламент приема/передачи от одной системы к другой. Этот способ сегодня настолько распространен, что примеры его использования приводить нет необходимости.
Недостатки:
- способ обмена данными не закрывает первую и четвертую причину организации взаимодействия (использование результатов чужих функций и обмен информацией о событиях), что делает невозможным организацию синхронного взаимодействия систем, критичную для онлайновых услуг; - функцию трансформации берет на себя одна из прикладных систем (что это такое и почему это плохо мы исследуем при рассмотрении интеграционных функций), и как следствие - присутствует высокая чувствительность к изменениям в технологиях; - гарантированность доставки обеспечивает пользователь, т. е. задействован человеческий фактор.
Достоинства:
- очень высокая производительность взаимодействия, ограничиваемая только средой и собственными возможностями прикладных систем.
Третий способ. Использование общего хранилища данных. Данный способ предполагает, что взаимодействующие на уровне данных системы используют для организации взаимодействия специализированное программное обеспечение. Хранилище - более продвинутый способ, так как предполагает использование специализированных интеграционных функций Хранилища (в частности, трансформацию), а не перекладывает их на прикладные системы. Но этот способ, как и второй, совершенно не подходит для организации синхронного взаимодействия систем.
Классический пример использования Хранилища - подготовка банковской отчетности с использованием информации из нескольких учетных систем: аналитической, управленческой, официальной (за исключением оперативной отчетности).
Четвертый способ. Непосредственное взаимодействие через программные интерфейсы. Данный способ предполагает, что одна система в процессе работы может обращаться к прикладным функциям другой системы путем прямого вызова.
Здесь лучше начать с достоинств:
- этот способ дает возможность синхронного взаимодействия между системами, что в свою очередь позволяет предложить клиентам банка онлайновые услуги, использующие функции разных систем (классический пример такой услуги - получение текущего остатка по счету через систему Интернет-банк); - высокая скорость взаимодействия.
Тем не менее, недостатки делают этот способ взаимодействия непривлекательным:
- все многообразие необходимых интеграционных функций берут на себя прикладные системы. Это делает решения, построенные при помощи описанного способа взаимодействия, неотказоустойчивыми во внештатных ситуациях, лишенными гибкости, необходимой в период технологических изменений. Зачастую уровень информационной безопасности также выдерживает никакой критики.
Пятый способ. Взаимодействие при помощи среды гарантированной доставки сообщений. Этот способ предполагает, что системы осуществляют взаимодействие при помощи тех же пакетов данных, что и второй способ, но пакеты перемещаются от системы к системе не через файловую, а через специализированную среду, обеспечивающую гарантированную доставку этих пакетов от системы к системе. Обычно такие среды снабжены брокером сообщений - специализированным программным обеспечением, в котором реализованы такие интеграционные функции как трансформация, маршрутизация, протоколирование и др.
К достоинствам такого способа можно отнести следующие:
- в отличие от файловой среды, среда гарантированной доставки дает возможность регламентировать время прохождения сообщения от системы к системе, что позволяет решить вопрос синхронизации функций и информирования о событиях между системами. Например, если временной регламент прохождения сообщений - одна секунда, то поступившую информацию об остатке на счете можно считать весьма достоверной; - все интеграционные функции вынесены из прикладных систем. Это дает определенную гибкость при развитии технологий, обеспечивает высокий уровень информационной безопасности и отказоустойчивости систем при внештатных ситуациях; - высокая скорость взаимодействия, которая ограничена лишь пропускной способностью среды и прикладными системами; - современные промышленные среды гарантированной доставки (IBM WebSphere MQ, Sonic MQ и др.) очень хорошо адаптированы к работе в гетерогенных комплексах, включающих в себя разнородные аппаратные платформы, операционные системы, СУБД, сервера приложений.
Недостатки данного способа обеспечения взаимодействия:
- высокие стартовые временные и финансовые затраты. Они связаны прежде всего с приобретением и освоением промышленных средств интеграции. Сейчас они достаточно распространены, а вот ранее интеграционные проекты нередко включали в себя разработку доморощенных "сред" и "брокеров"; - к условным недостаткам можно также отнести тот факт, что взаимодействие все же осуществляется на уровне данных, а не функций. С одной стороны, это легко обойти, если в тело сообщения поместить специальные данные, назначение которых - указать системе на вызов определенной функции, с последующим формированием сообщения с результатом. С другой стороны, такой алгоритм "обработка данных - вызов функции - формирование ответа" также является интеграционной логикой, которую придется реализовывать в прикладной системе. Но по сравнению со способами, описанными выше, объемы этой логики - сущий пустяк.
Каноническим примером использования данного способа обеспечения взаимодействия являются платежные системы. Они требовательны к обеспечению гарантированности доставки, отказоустойчивости, безопасности, подвержены постоянным изменениям (новые виды платежей, получателей, отправителей и т.д.), при этом системы участников прямых расчетов территориально распределены и имеют различное программно-аппаратное окружение.
Шестой способ. Взаимодействие систем при помощи сервисной шины. Этот способ обеспечения взаимодействия по праву считается вершиной эволюции интеграционных технологий. Взаимодействие между системами осуществляется через сервисную шину. Поясню: каждая система, участвующая во взаимодействии, может как регистрировать свои сервисы (это те же программные интерфейсы, но оформленные для унификации в едином стандарте, и назначение их строго определено - внешние вызовы), так и обращаться к сервисам любых других систем, зарегистрированных на шине.
Можно сказать, что этот способ сочетает все основные плюсы вышеперечисленных способов. Отдельно хочется отметить возможность полной изоляции интеграционной логики от логики прикладных систем. Это дает самую высокие показатели гибкости при развитии, отказоустойчивости, уровня информационной безопасности и др.
Недостаток у этого способа один - высокие стартовые затраты (финансовые и временные) на закупку и освоение промышленных интеграционных продуктов. Хотя здесь есть существенные подвижки. Все больше и больше IT-компаний предлагают свою экспертизу в области интеграции (существенная экономия временных затрат). На рынке промышленных интеграционных продуктов наметилась острая конкуренция, которая должна привести к снижению цен.
Итак, мы рассмотрели основные способы обеспечения взаимодействия между подсистемами. Нелишне будет напомнить, что почти все указанные выше способы хорошо сочетаются между собой. Так, например, территориально-распределенные системы многофилиального банка уместнее интегрировать между собой, применяя среду гарантированной доставки сообщений совместно с единой сервисной шиной. Это позволит предоставлять в региональных филиалах централизованный сервис, обслуживаемый в Головном офисе банка (например, единую точку платежей).
При описании способов обеспечения взаимодействия мы останавливались на так называемых интеграционных функциях - маршрутизация, адресация, трансформация, однократная аутентификации (single sign-on), управление распределенными транзакциями и бизнес-процессами и др. Почему так важно отделять их от прикладного кода? Ведь многие разработчики предоставляют свои прикладные системы с широкими возможностями по кастомизации (табличные и алгоритмические настройки, внутренние языки собственной разработки, да и просто открытый код). Почему нельзя использовать эти возможности, не прибегая к дополнительным средствам настройки и разработки?
Этому есть несколько причин:
- инструменты кастомизации прикладных систем не предназначены для решения интеграционных задач. В основном они ориентированы на изменения прикладных алгоритмов: изменить алгоритм расчета процентов, изменить контроль ввода данных в экранную форму, добавить дополнительные реквизиты в платежный документ (договор, информацию по клиенту банка), изменить печатную форму. Да, в современных системах присутствует возможность выгрузки данных в произвольный формат (в тот же xml), но считать это серьезным интеграционным инструментом можно было лет пять тому назад. Попробуйте реализовать решение с использованием распределенной транзакции в трех системах при помощи прикладной логики. Возможно, в каких-то системах это и получится, но, я уверен, это будет громоздко, ненадежно и с существенными технологическими ограничениями, - сопровождение прикладных систем необоснованно усложняется, - исчезает возможность распределять нагрузку на аппаратные средства между интеграционной и прикладной логикой, - фактически исчезает возможность масштабирования интеграционного решения, - нештатная ситуация может повлечь за собой масштабный сбой прикладной системы.
В заключение рассмотрим несколько примеров услуг, которые банк может предоставлять своим клиентам, являясь технологически развитым в части интеграционных решений.
Предположим, что в банке установлены следующие системы:
- АБС (в состав которой входят блоки вкладов и кредитов физических лиц); - карточный процессинг; - система дистанционного банковского обслуживания класса интернет-банкинг; - сервис внешней системы для оплаты услуг мобильной связи.
Некоторый перечень привлекательных моментальных услуг, которые банк сможет предоставлять клиенту - физическому лицу, если обеспечено взаимодействие между указанными выше системами при помощи среды гарантированной доставки сообщений (пятый способ) и/или сервисной шины (шестой способ):
- моментальная оплата погашения кредита с карточного счета при помощи системы интернет-банкинга; - моментальная оплата услуг мобильной связи с карточного счета при помощи системы интернет-банкинга; - получение выписки по всем счетам (текущим, кредитным, карточным) через банкомат; - совершение индивидуальных платежей через банкомат и отделение, ранее настроенных в интернет-банкинге; - моментальный перевод средств с карточного счета на текущий и обратно через банкомат, интернет-банкинг, отделение.
Этот далеко не полный перечень услуг дает представление об уровне сервиса, который банк сможет предоставлять своим клиентам, несмотря на то, что эксплуатирует системы от разных разработчиков. Что касается развития продуктовой линейки, то в такую IT-инфраструктуру банка легко впишутся новые сервисы от поставщиков услуг (Интернет, кабельное телевидение, коммунальные службы и др.) и новые каналы их оплаты (киоск самообслуживания, мобильный-банкинг и др.).
Итак, мы подробно рассмотрели один из критериев технологично развитого банка: уровень технологий банка для эффективного обеспечения взаимодействия между различными системами - уровень интеграционных технологий. Технологическая "продвинутость" и современность банка тесно связана с его привлекательностью для клиентов и прибыльностью для владельцев. Высокий уровень решения чисто технологических задач неизбежно проявится в повышении эффективности работы кредитно-финансовой организации.
