Упрощенная HTML-версия
В том числе и консерватизм. Ведь как
большинство людей принимают ре-
шение? Коллега сказал, что хорошо,
значит, стоит попробовать. Если та-
ких двое–трое — совсем прекрасно,
рисков меньше.
Но кто-то решает и сам: изучает,
анализирует, сравнивает, взвешивает
риски. Это серьезная работа, требу-
ющая времени и напряжения. И от-
ветственность. Тут ведь еще дело в
том, что когда, скажем, разработчик
приходит к своему потенциальному
клиенту, то расписывает главным
образом преимущества своего пред-
ложения, а на тему возможных слож-
ностей не распространяется. Но ведь,
например, председатель правления
банка не должен детально разби-
раться в информационных техноло-
гиях. И если он чего-то не понял, а
ему не объяснили, то он, скорее все-
го, поостережется связываться с этой
новинкой.
Перелом случится в тот момент,
когда самые крупные, известные,
ключевые российские банки решат
перейти на компонентную архитек-
туру. Тогда за лидерами потянутся и
остальные.
БДМ:
А они пока не решили?
Похоже, что в теории мир уже купил
компонентность. Во всяком случае,
компания Gartner, которая проводит
исследования как раз на стыке меж-
ду ИТ и финансами, опросила CIO
тысячи крупнейших банков мира, и
83% из них ответили, что в ближай-
шие пять лет намерены выстраивать
в своих организациях компонентную
архитектуру: кто-то—SOA, другие—
EDA, третьи — гибридные варианты.
Но в любом случае — компонентную.
Это если говорить о мировых тенден-
циях.
БДМ:
Выходит, идея компонентности
начинает овладевать умами?
Не все так просто. Я открою вам
злейшего врага компонентности —
он зовется интеграцией. В монолит-
ной системе ничего не надо интегри-
ровать, а в случае с компонентной
структурой интеграция обязательна.
Кстати, лет 10 назад банки друж-
но избавлялись от компонентных
систем и ставили монолит. Потому
что компонентность того времени
представляла собой неуправляемый
ворох неизвестно чего: много раз-
ных систем от разных поставщиков,
между собой не стыкуются, сбоят, не
работают. Тогда даже термин появил-
ся — «лоскутное одеяло».
БДМ:
Я слышала не менее крас-
норечивое определение — «зоо-
парк»… Тогда понятно, почему
банки не хотят отказываться от
проверенного монолита. А что в
нем не так, чтобы менять на компо-
нентную систему?
Во-первых, монолит — это зависи-
мость от одного ИТ-поставщика.
Во-вторых, невозможность быстро
поддерживать развитие бизнеса. Вы
как поставили монолитную систе-
му, так она и стоит. Что-то не нужно
стало — не выбросишь, новое по-
надобилось — разработчик чешет
в затылке и говорит: «Дорого обой-
дется, и делать будем долго», — или
вообще отказывается дорабатывать.
А между тем на рынке есть приложе-
ние, которое вам подходит в самый
раз. Вы его покупаете, потом еще
одно, еще… Но монолитная система
интегрироваться не любит, да и уме-
ет не слишком хорошо. Таким обра-
зом, вдобавок к монолиту (за под-
держку и сопровождение которого,
замечу, вы продолжаете платить) у
вас появляется все то же «лоскутное
одеяло».
Для поставщика, конечно, такая
ситуация выгодна: внедрил систе-
му один раз в банке, а потом года-
ми поддерживай ее и не горюй. На-
пример, в западных банках мощные
монолитные АБС стоят по 10–20 лет,
и их так просто не вытравишь, по-
тому что они замкнули на себя все
бизнес-процессы, весь бизнес на них
держится.
В конце концов, когда система со-
всем устаревает, ее все-таки прихо-
дится менять, целиком, и это серьез-
ные затраты и очень большие риски.
Но прежде другого выбора у банков
не было.
БДМ:
А что поменялось? Предлагая
сейчас банкам перейти на компо-
нентную архитектуру, вы прово-
цируете все те же затраты и про-
блемы.
Как раз нет. Мы сейчас один за дру-
гим переводим наших клиентов с мо-
нолитной 5NT на компонентную FA#,
причем делаем это в рамках перехода
на новую версию системы.
БДМ:
Откуда такой альтруизм? Чем
плохо «пасти» три с лишним сотни
банков, где стоит 5NT?
Нет здесь никакого альтруизма, про-
сто мы смотрим вперед. И хорошо
знаем, каких усилий стоит даже не-
большое изменение в монолитной
системе. На самом деле на мини-
мальные изменения требуется от
полугода до года, а банку они нуж-
ны срочно — у него бизнес буксует.
Мы мониторим рынок, собираем и
систематизируем потребности, ко-
торые генерируют наши клиенты,
плюс учитываем изменения в нор-
мативной базе, возникающие регу-
лярно. Потом все это аккумулируем
и планируем новую версию своего
большого продукта. Ее нужно соз-
дать, протестировать, отладить, пи-
лотировать в реальном банке — и
только после этого можно выпускать
на рынок. Как ни крути, меньше чем
Выбирая компонентный подход,
вы платите только за нужный вам
функционал и
быстрее начинаете
зарабатывать
сентябрь 2012
Банки и деловой мир
77
Информационные технологии