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

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

ЧИНОВНИКИ, ВЛИЯЮЩИЕ НА ПОРОЖДЕНИЕ ИЗМЕНЕНИЙ В БАНКОВСКОМ ПО, ИМЕЮТ ПОДАВЛЯЮЩЕЕ ЧИСЛЕННОЕ ПРЕВОСХОДСТВО НАД УЗКИМ КРУГОМ ЛИЦ, КОТОРЫМ ПРЕДСТОИТ БОРОТЬСЯ ЗА ВЫЖИВАНИЕ СОЗДАННОГО ИМИ ПРОГРАММНОГО ПРОДУКТА

ЛОГИКА БИЗНЕСА

Применительно к банковскому розничному обслуживанию эта «гонка на выживание» приобретает особо жесткий характер. Начать с того, что борьба на опережение потребностей клиента в изменениях не может вестись экстенсивным способом, т.е. простым увеличением штата программистов и аналитиков.

Проблема не только в том, что заказчик зачастую не имеет возможности выделить необходимые денежные ресурсы на сопровождение. Проблема глубже: внесение изменений в ходе сопровождения какого-либо одного банковского продукта порождает лавинообразный рост изменений в других сопутствующих продуктах. На описание одного дня жизни надо затратить неделю!

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

Поэтому нет ничего удивительного в многообразии программных решений, присутствующих на сегодняшнем российском рынке. Свои силы в создании интегрированной системы розничного обслуживания пробовали не менее двух десятков авторитетных российских разработчиков, не говоря уже о том, что на российском рынке присутствуют и западные производители. Казалось бы что нового можно придумать в линейке банковских продуктов, предлагаемых для розничного обслуживания? Практика, однако, показывает совершенно неожиданное комбинаторное богатство, возникающее на стыке электронных технологий XXI века при использовании множества валют, имеющих хождение на рынке (что было более характерно для средневековых менял, породивших само слово banco - конторка первых банкиров, дававших деньги в рост купцам-мореплавателям и учитывавших долговые расписки).

НА ВОЙНЕ КАК НА ВОЙНЕ

Чтобы осознать размерность пространства комбинаций, достаточно рассмотреть самый простой случай розничной банковской операции - взнос наличными на счет. Как вы думаете, сколько элементарных ответов получает и анализирует программный модуль этого продукта? Лежащий на поверхности ответ - сколько денег и на какой счет положить - оказывается столь же очевидным, сколь и неверным. Программный модуль почти незаметно отрабатывает «развилки»: паспорт или другой документ предъявил клиент, относится ли он по налоговому законодательству к резидентам или нерезидентам, совпадает ли валюта вклада с валютой вносимой суммы и т.д. Попутно решаются вопросы допустимости тех или иных вариаций (например, некоторые типы вкладов, согласно условиям договора, могут пополняться лишь в заранее оговоренные моменты времени), в необходимых случаях вычисляются размеры комиссионных сборов и налогов. Ознакомление с программным кодом этой простейшей банковской услуги типа «взял - положил» оставляет неизгладимое впечатление: более полусотни элементарных сервисов зашито внутри. Размер, как известно, имеет значение. И чем больше потенциальных ловушек, в которых можно ошибочно поставить «заглушку», тем ниже вероятность получить программное изделие, вычищенное от всех ошибок. Для сложных банковских информационных систем вероятность бессбойного функционирования равна нулю. На войне как на войне! Известный афоризм Карла Клаузевица о том, что военная наука проста и доступна пониманию любой домашней хозяйки, но воевать сложно, как нельзя лучше подходит к большим информационным системам. Все знают, каких опасностей следует избегать, но выигрывает тот, кто умеет это делать.

«УПАКОВАННАЯ» ОТДЕЛЬНО ОТ КОДА ПРОГРАММЫ БИЗНЕСЛОГИКА ОКАЗАЛАСЬ ПРИГОДНОЙ ДЛЯ ЕЕ ПОРТАЦИИ В ЛЮБУЮ ДРУГУЮ СРЕДУ. ПРИ ЭТОМ ГЕНЕРАЦИЯ КОДА ПРОИЗВОДИТСЯ НЕ РУКАМИ, С ПРАКТИЧЕСКИ НЕИЗБЕЖНЫМИ ЛЯПАМИ, А БЕЗДУШНОЙ И ПОЭТОМУ БЕЗОШИБОЧНОЙ ПРОГРАММОЙПЕРЕКОДИРОВЩИКОМ

АВТОКОДИРОВАНИЕ - В РОЗНИЦУ

Аврааму Линкольну приписывают изречение: «Имея час на то, чтобы свалить дерево, большую его часть я бы потратил на заточку топора». К похожему заключению пришла и группа разработчиков, программировавших розничные регламенты Сбербанка России, и нашла нетривиальный ход: для безболезненного прохождения жизненного цикла системы необходима оцифровка бизнеспроцессов (регламентов). Вместо того чтобы начать наперегонки со временем и вопреки здравому смыслу писать бесчисленные строки кода бизнес-логики, они создали необходимый инструментарий - модуль автокодирования типовых операций!

Без воодушевления такой подвиг повторить вряд ли удастся. Во всяком случае, хотя идея и лежит на поверхности, среди всех разработчиков банковского ПО она была реализована всего единожды. Сейчас нечто похожее, под названием API (аpplied program interface), продвигается крупнейшими разработчиками в составе дорогостоящих пакетов для разработки SOA-продуктов. Результат превзошел все ожидания. Удалось выполнить, казалось бы, бесконечную рутинную работу по написанию устрашающе длинного кода. Сложная длительная процедура в итоге свелась к набору типовых регламентов, каждый из которых состоял хоть и из большого, но все-таки преодолимого количества атомарных операций. Но самое главное преимущество разработчики и заказчик ощутили позже.

Во-первых, разработчики, к своему удовольствию, обнаружили, что вся бизнес-логика уже выделена в отдельный слой, который сегодня назвали бы сервером приложений.

Во-вторых, обслуживание и сопровождение получившегося продукта осуществляется хоть и на своей территории, но малой кровью, с выполнением требований Сбербанка России по розничному обслуживанию. Не самый легкий для сопровождения объект!

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