Насколько важно сегодня использование промышленных СУБД в автоматизированных банковских системах?  

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

Михаил Дробышевский, директор Департамента банковского ПО RS-Bank/Pervasive: Каждый инструмент предназначен для решения определенного круга задач. Главное – уметь правильно поставить задачу, выделить основные функции, выполнение которых необходимо обеспечить, а также определить ограничения по ресурсам. В настоящее время на рынке АБС в России присутствуют как системы на базе промышленных СУБД, так и системы на базе остальных СУБД. Я специально использовал слово «остальных», поскольку сложно называть такие СУБД, как Pervasive или Cache, не промышленными – с учетом того, что эти СУБД производят и развивают самостоятельные большие компании, что на базе этих СУБД в мире разработаны тысячи приложений (типа АБС, ERP-систем) и на этих приложениях работают миллионы пользователей по всему миру. Термин «промышленная СУБД» сейчас в большей степени носит маркетинговый характер. Появилось это понятие в то время, когда часть программных приложений использовала самописные СУБД, созданные компанией – разработчиком АБС или ERP-системы. Эти старые СУБД можно было назвать непромышленными. На сегодняшний день все имеющиеся на рынке тиражные АБС работают на тиражных СУБД, отвечающих современным требованиям по производительности, надежности, масштабируемости, открытости интерфейсов и т. д. Все они, по сути, работают на промышленных СУБД. Другое дело, что разные банки предъявляют к своим АБС разные требования, и чтобы удовлетворить эти требования, разработчики АБС применяют различные инструменты, в том числе СУБД. К примеру, если для банка важно, чтобы система работала быстро на относительно небольших объемах информации и на технике средней мощности, была недорогой с точки зрения лицензии, не требовала никакого администрирования («нулевое администрирование»), то для построения такой СУБД целесообразно использовать упомянутую выше СУБД Pervasive.SQL и крайне нецелесообразно использовать Oracle или DB/2 (так как перечисленные выше требования не будут выполнены). И наоборот, если банку необходимо обрабатывать миллионы операций ежедневно, то банк автоматически меняет требования к АБС – на первый план выходит производительность на больших объемах данных, зато стоимость лицензии и необходимость иметь специального администратора сервера БД отходят на второй план как неизбежные расходы для обеспечения выполнения основной задачи. Если же говорить о таких ключевых характеристиках СУБД, как надежность, возможность резервного копирования онлайн и последующего быстрого восстановления информации, то сейчас практически все СУБД на рынке обеспечивают достаточные для своей области применения инструменты для решения этих задач.  

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

Дмитрий Феофилактов, директор по технологиям /company-supplier/fors_bs/: Их использование обязательно. Причины кроются в совокупности требований к СУБД: надежность хранения, масштабируемость, отказоустойчивость, безопасность, функциональность, сервисное обслуживание и т. д. По совокупности только промышленные СУБД могут обеспечить выполнение этих требований. Любой недостаток должен компенсироваться доработками со стороны поставщика банковской системы.  

Михаил Анучин, региональный менеджер по странам СНГ компании Misys: С нашей точки зрения, самое ценное, что есть у пользователей АБС – это достоверная информация и наличие постоянного доступа к ней. Все остальное можно купить. Гарантировать высочайший уровень логической целостности данных, а также катастрофоустойчивость системы для поддержки непрерывности бизнеса может только промышленная СУБД, которая обладает соответствующим набором встроенных современных технологических решений.  

Какие качества платформы особенно важны с точки зрения создания прикладных решений?  

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

Михаил Дробышевский: Для каждой категории прикладных решений важны различные качества, предоставляемые платформой. Разумеется, есть и общие параметры, требования к которым предъявляет любая автоматизированная система. Я их перечислил выше: надежность, масштабируемость (хотя бы в пределах одного класса), открытость интерфейсов, наличие всех современных «стандартных» интерфейсов. Но в то же время для каких-то приложений важно, чтобы платформа (в данном случае СУБД) поддерживала несколько разных аппаратных платформ, для других – чтобы обеспечивала «нулевое администрирование» и т. д.   

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

Дмитрий Феофилактов: Широта функционала, предоставляемого платформой, позволяет разработчику сосредоточиться на бизнес-логике, а не на реализации системных функций. В этом огромное преимущество промышленных СУБД.

       Отказоустойчивость. Без поддержки на уровне платформы разработчику будет практически невозможно построить отказоустойчивое решение для своей системы. А онлайновая работа систем – насущное требование рынка.

       Доступность «дешевых» решений. Начальные вложения заказчика в инфраструктуру необходимо сделать минимальными. Хотя большинство производителей ПО предоставляют урезанные версии своих систем бесплатно, важно, чтобы у заказчика была возможность заменить бесплатную (или дешевую) версию на Enterprise без существенных изменений кода (желательно вообще без привлечения разработчика).  

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

Можно ли говорить, что та или иная СУБД изначально обеспечивает АБС какие-то конкретные конкурентные преимущества? Какие?  

Андрей Висящев: В качестве главных и неоспоримых конкурентных преимуществ я бы назвал масштабируемость и качество технической поддержки.  

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

Михаил Талантов: Вероятно, можно. Для тех задач, которыми занимается EGAR Technology, производительность – на первом месте. Далее идут поддержка клиентских программ, поддержка стандартных скриптовых языков, таких, например, как PL/SQL, transactSQL и других. Имеет также значение количество людей на рынке, способных выполнять функции администратора БД.  

Дмитрий Феофилактов: Так говорить можно. Например, возьмем требование по масштабируемости. MS SQL Server может работать только на платформе x86. На данный момент можно приобрести сервер с 32 ядрами и не больше. А для Oracle Database доступны сервера со 128 ядрами и даже больше. Это пример «лобового» решения. Даже для платформы x86 у Oracle можно получить большую производительность, так как есть полноценный кластер (а не только failover как у MS SQL). Это позволяет получить базу данных, работающую на 64 (и т. д.) процессорах.  

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

       В случае компании Misys, основные АБС которой работают на платформе IBM DB2/400, соответствие международным стандартам, масштабируемость, открытость (возможность использовать любые языки программирования), высокая производительность и гарантия целостности данных, реализованные в вышеупомянутой СУБД, радикально повышают скорость разработки и качество прикладных программ.  

 Существуют ли какие-то специфические особенности у приложений класса АБС, которые накладывают определенные требования на платформу?  

Андрей Висящев: Безусловно, АБС надо рассматривать как программно-аппаратный комплекс, каждый элемент которого важен для бизнеса. И системная, и прикладная части накладывают друг на друга определенные ограничения.  

Михаил Дробышевский: Особенности есть у каждого вида приложений, в том числе и у АБС. Например, по сравнению с бухгалтерскими системами АБС должны работать гораздо более надежно и, как правило, обрабатывать значительно бОльшие объемы информации. Это означает, что от платформы требуется обеспечение такой надежности и возможности обработки бОльших объемов данных. В то же время, если сравнивать АБС с системами, работающими в режиме реального времени (станки с ЧПУ, телеметрия и т. д.), то требования АБС ко времени реакции системы гораздо менее жесткие, чем в этих РВ-системах. Значит, от платформы не требуется соответствующей функциональности.  

Дмитрий Феофилактов: Существуют. Это, например, доступность 24×7 (для карточных подсистем). Следовательно, резервирование должно проходить в «горячем» режиме – без останова базы данных. Кроме того, программная платформа должна поддерживать «горячее» восстановление – хотя бы failover, желательно вообще без downtime (например, кластер).  

Михаил Анучин: Безусловно. Требование номер один – защита информации во всех смыслах (физическое хранение, логическая целостность, защита от несанкционированного доступа). Второе – высочайший уровень доступности и способность справляться с пиковыми нагрузками. И что особенно важно для активно развивающихся банков – возможность масштабирования для поддержки растущих объемов бизнеса.  

Насколько важен выбор платформы с точки зрения стоимости владения?  

Андрей Висящев: Выбор той или иной платформы должен в первую очередь определяться стратегией развития бизнеса. Имеет смысл рассматривать отношение: цена/ производительность и коэффициент темпов развития бизнеса.  

Михаил Дробышевский: Чрезвычайно важен. Во-первых, СУБД может накладывать ограничения на возможности использования того или иного аппаратного и системного программного обеспечения (например, СУБД может работать только на Intel-серверах или только на серверах от Sun). Во-вторых, разные СУБД предъявляют совершенно разные требования к своей поддержке. Если не трогать изначально настроенную систему на базе Oracle (т. е. не заниматься проверкой корректности СУБД, просмотром логов, тюнингом системы), то с большой долей вероятности через некоторое время система начнет «сыпаться». А СУБД компании Pervasive Inc., напротив, предполагает работу в режиме «один раз настроил — и забыл». Понятно, что наличие выделенного администратора СУБД существенно увеличивает стоимость владения системой.  

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

Дмитрий Феофилактов: Если рассматривать выбор между x86 и RISC-платформами, то критически важен. Начальные вложения для RISC в разы превышают стоимость x86. При том что удобство управления и надежность систем сравнимы. При этом «промах» в оценке производительности системы может еще больше увеличить «отрыв» RISC-платформы, так как простой расчет показывает, что имеет смысл сразу покупать полностью «упакованный» сервер, чем наращивать его производительность постепенно (кроме оперативной памяти, пожалуй). Что справедливо для обеих платформ.

       Для x86, если рассматривать комплекс из сервера, ОС и СУБД (как платформу), например, MS SQL (Windows), Oracle (Windows), Oracle (Linux), то при определенных условиях выбор не принципиален. Основное условие – при масштабировании система сможет работать на одном сервере (т. е. производительности одного x86-сервера достаточно при любом росте).

 Михаил Анучин: Это важно, как и все, что влияет на прибыльность бизнеса. Причем сейчас это важно как никогда раньше. И с каждым годом становится все важнее. Просто потому, что техника (и аппаратное, и программное обеспечение) дешевеет, а люди дорожают.  

Существует ли какая-то жесткая связка на уровне «программная платформа – аппаратная платформа»?  

Андрей Висящев: Такая связка определяется совместимостью компонентов программно-аппаратного комплекса и их жизненным циклом.  

Михаил Дробышевский: В общем случае не существует. Большинство современных аппаратных платформ позволяют устанавливать и использовать различное системное ПО. Ситуация с СУБД аналогична – практически все они способны работать на двух или более программно-аппаратных платформах.  

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

Дмитрий Феофилактов: Для MS SQL Server – да. Только x86. Для остальных возможны различные комбинации, однако там тоже есть предпочтительные связки. Наличие специфических багов для конкретных платформ есть у всех производителей сложного ПО. Поэтому предпочтительная связка определяется платформой разработки. В таком случае предварительное тестирование начинается уже на этапе разработки, а также упрощается поддержка, так как разработчику проще анализировать баги.
     Исходя из текущих реалий, основной платформой разработки становится x86 (x86-64). Поэтому наиболее предпочтительными являются связки Windows (x86-64) – MS SQL Server и Linux (x86-64) – Oracle.  

Михаил Анучин: У «программно-аппаратных» комплексов существует одно важное преимущество, затмевающее все остальные недостатки, – это оптимизация программной составляющей под конкретную аппаратную часть и наоборот – проектирование аппаратной части с учетом особенностей программной. Универсальные программные платформы в этом смысле сильно проигрывают, из-за того, что при разработке приходится ориентироваться на огромное многообразие «железа», представленного на рынке. Это зачастую приводит к некорректной работе «железа» с определенными конфигурациями программных платформ. А страдают от такого «многообразия» банки, которым приходится тратить свои ресурсы, разбираясь, где чьи проблемы. Кстати, посмотрите на последнее крупное приобретение Oracle – Sun Microsystems…

Насколько платформа core banking system ограничивает банк с точки зрения выбора других прикладных систем? Возникают ли какие-либо специфические проблемы в сфере интеграции приложений, обусловленные особенностями платформы?

Андрей Висящев: Возможности любого прикладного решения (в том числе и core banking system) определяются изначально закладываемыми (рынком) бизнес-требованиями. Еще несколько лет назад основными инструментами интеграции были межфайловый интерфейс и повторный ручной ввод. Сейчас требования по интеграции являются одними из ключевых. Решения, прячущиеся за высоким забором, уйдут с рынка.

 Михаил Дробышевский: Это зависит от конкретной платформы core banking system. Если платформа построена с использованием SOA (сервис-ориентированная архитектура) или является открытой, позволяет получить доступ к информации при помощи внешних API или хотя бы через файлы, то никаких ограничений по выбору других прикладных систем и последующей интеграции между ними не возникает. Однако на рынке до сих пор используются некоторые устаревшие системы (в основном это системы, разработанные в самих банках, – не тиражные), единственный способ получить информацию из которых – посмотреть ее на экране или распечатать отчет на принтере. Конечно, с такими системами практически невозможно интегрироваться, и это накладывает существенные ограничения на выбор остальных систем, используемых в банке.

 Михаил Талантов: Очень многое зависит от самой CBS. По опыту EGAR Technology, если она, скажем, реализована в SOA-архитектуре или просто достаточно открыта для создания внешних интерфейсов, то проблемы с БД не возникает.

 Дмитрий Феофилактов: Жестких ограничений нет, так как уже давно банки от монолитных решений перешли к «лучшим в своем классе» или индивидуальных подсистем. Однако проблемы есть. Они лежат в двух плоскостях. В первой из них – построение интерфейсов – существует три проблемы: безопасность, производительность и гибкость. Вторая – кадры. При использовании систем, в основе которых лежат разные ОС и СУБД, возникает потребность в большом числе разнопрофильных администраторов. 

 Михаил Анчучин: Сама по себе – ни насколько не ограничивает. Любая core banking платформа потребует интеграции с другими приложениями. Если АБС использует промышленную аппаратную платформу (типа IBM Power), то банку будет намного проще осуществить интеграцию. Если такие ограничения все же возникают, то они в подавляющем большинстве случаев обусловлены наличием у банка унаследованных (legacy) систем, и к особенностям платформы это не относится.

 Исторически промышленные банковские системы иностранного производства строились на закрытых платформах. Почему? Есть ли будущее у таких решений?

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

 Михаил Дробышевский: Сорок лет назад не существовало понятия рынка независимого программного обеспечения. Все ПО поставляли только производители аппаратуры (такие как IBM, Digital Equipment и др.). Все платформы были закрытые, соответственно, все ПО строилось на закрытых платформах. Со временем системы становились все более открытыми, однако старые АБС переводились на них очень медленно. С точки зрения разработчика, в большинстве случаев проще (дешевле) переписать систему с нуля, чем переводить ее с закрытой платформы на открытую. Но и такое переписывание требует немалых ресурсов, поэтому происходит медленно. Тем более что многие банки – пользователи таких систем до какого-то времени остаются вполне удовлетворенными функциями этих АБС и не требуют их переноса на другие платформы. Но, конечно, со временем требования банков изменяются (растут, добавляются новые виды услуг, сервисов, форматы электронного обмена и т. д.), и банки все равно меняют такие системы на современные, построенные на базе открытых технологий, SOA-архитектуры. Так что будущего у закрытых систем нет.

 Михаил Талантов: Эти платформы долгие годы наращивали свою функциональность на системном уровне, и она использовалась в банках самого разного масштаба и специализации. Уровень решения вопросов надежности системы и ее производительности на таких платформах всегда высок, что и дает им перспективы.

 Дмитрий Феофилактов: Открытых систем тогда просто не было. А к моменту появления открытых платформ слишком много кода было написано, чтобы разом все поменять. Поэтому сейчас в основном такие системы «обрастают» интерфейсами, основанными на открытых стандартах для связи и расширения своей функциональности. Развитие таких систем под вопросом, они скорее находятся на стадии консервации и постепенно будут вытесняться решениями, основанными на открытых платформах, в том числе и OpenSource. 

 Михаил Анчучин: На закрытых платформах? Видимо, в первую очередь надо разобраться, что подразумевается под закрытой платформой.

      Когда-то давно не было ничего, кроме IBM AS/400 и мейнфреймов. Все серьезные промышленные АБС были написаны под эти системы. Шло время, эти АБС совершенствовались, накапливали «зрелость». Позже появились так называемые открытые платформы (кстати, абсолютно несовместимые между собой до сих пор). Пошла волна новых разработок (сродни тому, как в свое время в СССР каждая контора разрабатывала свою АСУ и бухгалтерию) под эти «модные» платформы. Будущее? Правильнее спросить, есть ли оно у некоторых из новоделов. Время покажет…

 Пара забавных фактов:       
     OS/400 был сертифицирован на соответствие стандартам POSIX и Х/OPEN раньше большинства Unix’ов. DB2/400 всегда поддерживала стандарты ISO SQL. Общий тезис таков: открытые системы – это системы, соответствующие промышленным стандартам. Так вот IBM Power (нынешнее поколение AS/400) изначально построена на таких промышленных стандартах;
на Windows до сих пор нет серьезных промышленных АБС.
     Вывод прост – будущее за решениями, которые в наиболее полной мере позволят банку обеспечить непрерывную, эффективную и производительную поддержку своего бизнеса. И без современной промышленной технологической платформы это вряд ли достижимо.