Подписаться
Читать в телеграм
Впрочем, даже без быстрого роста и при стабильном законодательстве процесс совершенствования делопроизводства не стоит на месте. Например, современные модели организации документооборота позволяют существенно увеличить эффективность организационной структуры предприятия (здесь интересно то направление разработок, начало которому положила фирма Lotus своей системой Notes). Успешный бизнес всегда находится в движении, и это вызывает потребность в постоянном изменении потоков обработки данных в организации. Покупать ли при каждом существенном изменении документооборота в банке новую, удовлетворяющую новым требованиям, программу, или приобрести настраиваемую банковскую систему — обычная проблема для управления автоматизации.
Сложность данной проблемы усугубляется несовпадением масштабов ожидаемых затрат на автоматизацию банка в России и в "западных" странах. При этом технические средства идут "оттуда", со своей исторической родины, где они создавались в расчете на возможности западных банков. Это накладывает дополнительный груз ответственности и заставляет искать особо эффективные решения по параметру цена/производительность.
Цель проекта
В 1994 году достигнутый объем операций АКБ "РПБ" заставил управление автоматизации банка искать пути к использованию современных способов организации обработки финансовых транзакций. Положение в РПБ было следующее. Банку-участнику прямых расчетов необходимо было получить систему автоматизации, позволяющую надежно работать в режиме реального времени со счетами клиентов в распределенной многофилиальной сети.
По нашему мнению, на российском рынке нет банковских систем, способных справиться с этой задачей. Поэтому, несмотря на очевидные трудности такого решения, банк был вынужден приступить к разработке собственной высококачественной программной системы, удовлетворяющей следующим требованиям.
Обеспечение максимальной надежности
Главной нашей целью было создание "невидимой" системы. Хорошая банковская система должна быть незаметна в банке. Банковские работники просто должны знать, что она есть и что с ее помощью можно сделать все, что им нужно, причем в приемлемые сроки. Если бухгалтеры и операционисты должны учитывать в расписании своей работы возможные "падения" системы и непонятные обычному человеку "особенности", это неправильное положение. Все-таки основная (и, наверное, единственная) задача банка — предоставление клиентам финансовых услуг, и выполнению этой задачи не должно мешать несовершенство в организации какой-либо вспомогательной службы, каковой, по большому счету, является управление автоматизации.
Двумя "китами", на которые может опираться создание такой системы, являются производительность и надежность. Они дают тот фундамент, на котором можно возводить здание развитой программной системы, не опасаясь, что при определенном уровне сложности этот фундамент "поплывет".
Должную надежность и достаточную производительность серверной части системы ныне могут обеспечить две платформы: мейнфрейм и сочетание RISC/UNIX. Первый вариант из-за необходимых больших начальных затрат пришлось отвергнуть. Второй вариант нас вполне удовлетворил, к тому же, кроме надежности и производительности, UNIX на большинстве RISC — платформ дает масштабируемость и открытость.
Обеспечение "прозрачного" выполнения всех корректных банковских операций
"Покупные" программы, эксплуатировавшиеся в нашем банке, требовали в некоторых нестандартных случаях совместной работы программистов и бухгалтеров по коррекции информации в базе данных. Некоторые вещи вообще невозможно было сделать по непонятной причине. Видимо, при разработке этих программ с успехом применялся принцип "если в Вашей программе есть недостатки, подробно их опишите и назовите особенностями". Эта проблема тесно смыкается с проблемой "невидимости" программы. Все действия должны обрабатываться адекватно, и бухгалтер при работе не должен помнить о том, что в одном случае блокируется такая-то таблица базы данных, а в другом случае все пользователи должны выйти из программы, чтобы нормально отработала административная задача. Для решения этой проблемы необходима тщательная разработка структуры данных и алгоритмов их обработки. Для хранения данных мы использовали СУБД CA-OpenIngres, обладающую развитыми системами блокировок, индексации и оптимизации.
Совместная работа валютного и рублевого управлений банка
До сих пор функционирование этих управлений в техническом плане было искусственно разделено, так как обычно существуют раздельные версии коммерческих систем для валютной и рублевой частей и, как следствие, раздельные рублевые и валютные базы данных со сложной системой связей между ними. Это противоестественное положение мы решили устранить, для чего нам пришлось решать массу проблем как программного, так и бухгалтерского характера.
Связь с филиалами
Банк с продуманной финансовой политикой функционирует как единое целое, со всеми своими территориальными управлениями. Имеющиеся же на рынке пакеты автоматизации предполагают взгляд на банк как на набор слабосвязанных филиалов. Информация между филиалами должна проходить достаточно быстро для предоставления клиентам филиалов того же уровня услуг, что и в Центральном отделении банка. При этом филиалы должны оставаться в рамках своих полномочий и иметь доступ только к своим данным. В то же время ответственные лица в центральном офисе нуждаются в полноценных средствах доступа к данным любого филиала. Чтобы удовлетворить всем этим требованиям, мы реализовали в системе три различные стратегии. Ниже мы их коротко опишем, в порядке убывания оперативности обмена информацией.
- Филиалы, для которых имеется возможность организовать надежную связь в режиме on-line, имеют единую базу данных в одной территориальной точке и образуют некий "кластер", внутри которого информация циркулирует почти мгновенно. Для повышения надежности применяется дублирование линий связи. Например, в РПБ каждый московский филиал соединен с центральным отделением двумя выделенными линиями связи. Надежность такой связи, как показала практика, достаточна.
- В тех случаях, когда возможность соединения филиалов по протоколу TCP/IP есть, но надежность такой связи вызывает сомнения, разумно держать в каждом филиале (или "кластере" филиалов из предыдущего примера) свою базу данных. Обмен информацией между такими базами происходит довольно редко, например, для прохождения межфилиальных документов или для подсчета консолидированного баланса.
- Если нет возможности установления связи между филиалами по протоколу TCP/IP, обмен информацией между филиалами происходит через электронную почту.
Нам представляется наиболее правильным разумное сочетание стратегий а) и б), и по возможности исключение ситуаций типа в), когда качество обслуживания клиентов заметно ухудшается. На практике это может реализовываться организацией филиальных "кластеров" в крупных центрах и соединением этих "кластеров" между собой выделенными линиями.
Для того чтобы такое решение было возможно, необходимо минимизировать объем информации, передаваемой по глобальным (обычно довольно медленным) линиям связи. В качестве способа решения мы выбрали архитектуру клиент-сервер с использованием монитора транзакций. Монитор транзакций позволяет достаточно просто организовать взаимодействие компьютеров в глобальной и локальной сетях, при котором трафик будет минимален.
Открытость алгоритмов обработки данных
Если в случае необходимости изменить алгоритмы обработки данных приходится привлекать программиста, это является трудоемким, дорогостоящим и даже опасным способом совершенствования программы. По нашему мнению, хорошая система должна предоставлять инструментарий для создания банковского документооборота. Внедрение такой программы будет трудным процессом, но все это многократно окупится на этапе эксплуатации. Программисту желательно не задумываться о конкретных путях прохождения документа в банке, а администратор должен получить гибкую систему, в которой он опишет этот путь.
Извечная проблема банковского программиста — постоянно меняющийся список финансовой отчетности, к тому же в разных банках имеются разные стандарты. В одних банковских программах отчеты жестко вставляются в программный код, обеспечивая высокую производительность и отсутствие гибкости. Другие программы предоставляют генератор отчетов, но скорость выполнения таких отчетов оставляет желать лучшего. Перед нами стояла задача использовать оба подхода для оптимизации системы получения отчетности.
Безопасность и контроль прав доступа
В системе, которая позволяет работать в одной базе данных нескольким филиалам, а также валютным и рублевым управлениям каждого из филиалов, необходима сильная подсистема контроля прав доступа и обеспечения логического разделения баз данных для пользователей с обычными полномочиями. При этом пользователи с высокими полномочиями должны иметь возможность получать любую информацию в системе.
Отдельным вопросом является защита от программиста-злоумышленника. В банке, распределенном по различным территориям и работающем в единой базе данных, среди работников могут оказаться разные люди. Выпускник ВМК МГУ, работающий операционистом в банке, теперь обычное явление. Принципиальной задачей для нас было требование невозможности создания злоумышленником программы на рабочем месте, получающей доступ к базе данных. Весь контроль должен вестись в серверной части комплекса, и ни один пользователь не должен иметь прямого доступа к серверу или базе данных. Программист — злоумышленник, создавший собственный программный клиентский агент, не должен иметь возможности доступа к информации без знания пользовательских паролей плюс изощренного программного интерфейса, малодоступного и хакеру. Необходимо было также предусмотреть возможность установки стандартного программного обеспечения (например, SunScreen фирмы Sun Microsystems), защищающего сеть от "диверсий" на уровне сетевых протоколов — от прослушивания сети и от попыток "прикинуться" другим пользователем или даже драйвером. Эта проблема возникает в связи с тем, что финансовые центры все чаще становятся участниками всемирной сети Internet, что имеет и некоторые негативные последствия для них, а именно, возникновение вероятности проникновения злоумышленников в корпоративную сеть. Для борьбы со злоумышленниками используются возможности систем защиты корпоративных сетей.
Проблемы коммерческих банковских систем
Систем автоматизации деятельности банка сейчас на рынке много. Приходится ограничиться перечнем основных проблем, возникающих при эксплуатации широко известных систем производителей банковского программного обеспечения.
Вопрос "нужно или не нужно использовать технологию клиент-сервер" банковские программисты и фирмы-производители банковских программных комплексов вроде бы уже решили. Есть только одна проблема и заключается она в том, что вопрос был ими решен по-разному: программисты-практики в банках убедились в необходимости такой технологии, а отечественные фирмы-продавцы банковского программного обеспечения — в сложности создания качественных решений для банков в архитектуре "клиент-сервер" (КС). Следствием такого положения явились многочисленные статьи в компьютерной печати, доказывающие потребителям, что вредная западная мода на "клиент-сервер" не нужна. Но сейчас информация о современных системах доступна всем и никто всерьез не принимает уверения в том, что банковский комплекс на основе Foxpro, Clipper или системы управления записями Btrieve является последним достижением могучей человеческой мысли. К тому же, системные администраторы в банках убедились на практике в неспособности такой технологии поддерживать одновременную работу сотен или хотя бы десятков пользователей. Автор этой статьи сам работал администратором двух известных систем и, увы, имеет представление о качестве подобных решений.
Термин "клиент-сервер" у нас час-то трактуется очень широко. Под эту категорию на отечественном рынке попадают любые сетевые архитектуры, организующие взаимодействие компьютеров. Под это определение подходит и схема построения приложений с использованием менеджера записей Btrieve. И даже обычный вариант с файл-сервером и Clipper'ом удовлетворяет этому широкому толкованию. Но в области "тяжелых" проектов архитектурой "клиент-сервер" принято называть схему построения приложений, обеспечивающую эффективное распределение логики приложения между различными компьютерами в сети. Каждый компьютер имеет определенный набор параметров, важнейшими из которых являются аппаратные характеристики и набор системного программного обеспечения. Развитая архитектура "клиент-сервер" позволяет строить приложение так, чтобы у каждого компьютера максимально использовались именно сильные стороны специфических для него характеристик. Как правило, в финансовых системах это достигается трехуровневой схемой приложения (клиент-сервер-СУБД).
Но реализовывать трехуровневую схему можно по-разному. Многие отечественные разработчики пошли по пути использования технологии хранимых процедур в таких высококачественных СУБД, как Sybase, Oracle и др. Встроенные процедуры помогают небольшим приложениям эффективно распределять нагрузку в сети между приложением-клиентом и приложением-сервером. По сути дела, встроенные процедуры представляют собой суррогат мониторов транзакций. Но именно суррогат, заменитель, никак не обеспечивающий необходимых средств создания и поддержания крупномасштабного проекта.
Кроме того, использование встроенных процедур обеспечивает программе полную непереносимость на СУБД других производителей.
Программисты-практики хорошо представляют, что такое встроенные процедуры, как сложно их создавать и отлаживать, и как затруднена их поддержка. Вот комментарий специалиста. "Эксплуатировать мощные сетевые приложения без TP-монитора — это все равно, что переходить через скоростную магистраль с закрытыми глазами... Встроенные процедуры, выполненные в виде модулей СУБД, имеют ограниченные возможности по распределению загрузки и контролю надежности. Они не могут использовать ресурсы вне базы данных, и, в конечном счете, пользователям приходится выполнять [большую] работу на компьютерах-клиентах, что сильно снижает производительность" (Линда Радосевич, "PCWEEK", 29 мая 1995г., стр. 10).
Для реализации трехуровневой схемы мы использовали монитор транзакций, позволяющий наиболее полно и гибко строить систему "клиент-сервер".
Сейчас в России имеется много банков, обладающих обширной сетью филиалов. Филиалам необходимо обмениваться информацией. Передовые современные банки вынуждены идти навстречу клиенту и ускорять прохождение информации из филиала в филиал. Кроме того, в условиях напряженной современной жизни необходимо усиливать контроль за деятельностью филиалов со стороны центрального отделения для постоянной корректировки финансовой политики банка в целом. Все это вызывает необходимость в постоянной связи между филиалами для мгновенного прохождения сумм и для контроля базы данных филиала. В идеале, в каждом регионе у банка должна быть единая база данных для всех филиалов этого региона, и базы данных различных регионов должны быть связаны между собой (и очень желательно в режиме on-line). При использовании программных комплексов, имеющихся на отечественном рынке банковских приложений, возможность построения подобной банковской сети представляется чистой утопией. Единственным реальным средством собрать такую структуру и обеспечить ее функционирование является монитор транзакций или аналогичное коммуникационное ПО класса middleware. При этом сама по себе проблема скоростной связи, например, в Москве, где, по разным оценкам, "крутится" от 60% до 70% российских денег, практически решена силами таких фирм, как "Голденлайн", "Макомнет" и др. Тем более досадно, что ни одна известная отечественная банковская система не в состоянии использовать возможности, предоставляемые современной технологией связи. Уходящее поколение банковских систем просто создавалось в расчете на иные экономические и технические условия эксплуатации. И решения, заложенные в эти программные комплексы, не дают им вобрать в себя новые подходы к межфилиальному взаимодействию.
В используемых ныне отечественными фирмами-разработчиками СУБД часто (практически всегда) отсутствуют средства поддержания целостности базы данных (система поддержки транзакций, средства автоматического восстановления данных и архивации базы данных). Как следствие, в большинстве систем реализуются самодельные средства (или не реализуются совсем), которые заведомо не достигают уровня поддержания целостности лучших профессиональных СУБД.
Хотя принципы объектно-ориентированного анализа и моделирования бизнес-процессов давно уже разработаны, объектно-ориентированные средства описания и моделирования документооборота, доступные администратору системы, не присутствуют ни в каком виде ни в одной известной автору коммерческой системе. Банк, купивший систему без средств описания потоков документооборота, не имеет возможности настроить ее на свои специфические потребности.
Открытость систем. Главное условие выживаемости банка — это поиск новых источников дохода и сокращение расходов, что означает постоянное изменение технологии работы, что в свою очередь, предъявляет к банковской системе требование мобильности. В хороших западных банковских системах всегда имеется множество "точек входа" со стандартным программным интерфейсом (для доработки системы программистами конкретного банка под свои специальные задачи) и/или расширенными средствами настройки документооборота. Отечественные же системы почти лишены таких возможностей, или предоставляют весьма убогий программный интерфейс. Но большой банк может довольствоваться закрытой системой только в одном случае — если она писалась специально для него. Однако и в этом случае со временем возникнут проблемы. В итоге на рынке банковских систем наблюдается следующая картина. Широко тиражируются системы, сделанные изначально для одного какого-нибудь крупного банка, а остальные покупатели, небольшие и средние банки, вынуждены копировать технологию работы того первого большого банка.
Из всего вышеописанного мы для себя сделали следующий вывод. Имеющиеся системы рассчитаны на нижнюю часть спектра российских банков, и такое положение заставляет коллективы разработчиков солидных банков, в сотрудничестве с сильными командами фирм — системных интеграторов, создавать свои собственные системы. Часто они при этом изобретают велосипед, но велосипед надежный и удобный, приспособленный к нуждам именно этого банка. Иногда возможности такой системы выходят за рамки "родного" банка.
Такая программная система, разработанная в Управлении Автоматизации АКБ "РПБ" в сотрудничестве со специалистами из фирмы Jet Infosystems и названная нами "RP/3", и является основной темой данной статьи. Ниже будет коротко рассказано о создании этой системы и об итоге этой работы.
Ввиду сложности комплекса RP/3, в рамках данной статьи мы сможем описать только общие задачи и свойства системы.
Подготовка к реализации проекта
При создании большой новой системы необходимо определиться в следующих основных вопросах.
Постановка задачи
Необходим богатый опыт работы программистов как в банковской области, так и в области реализации больших проектов. Также необходим выделенный постановщик задачи, способный общаться на одном языке и с бухгалтером, и с программистом. Роль постановщика состоит в описании основных бизнес процессов.
Мы считаем, что оптимальный цикл разработки таков: постановка задачи — проект — кодирование — отладка — постановка задачи — проект — ... и так далее по кольцу. При этом эффективность команды разработчиков в значительной мере зависит от времени прохода по одному витку цикла.
Общая архитектура проекта
Нами (коллективом разработчиков АКБ "РПБ") в ходе консультаций со специалистами Jet Infosystems была выбрана архитектура "клиент-сервер" с использованием монитора транзакций. При этом общее распределение вычислительной нагрузки таково: сервер приложения занимается ответственными вычислительными задачами (быстрые транзакции, генерация отчетов, поддержка логической целостности базы данных, реализация алгоритмов обработки данных, баланс загрузки), а приложение-клиент нацелено на создание максимально дружественного интерфейса. Интерфейс программы и алгоритмы обработки данных принципиально разделены.
Сейчас на рынке средств быстрой разработки проектов (RAD) имеется множество так называемых языков 4 поколения. Мы пришли к выводу о нецелесообразности использования такого средства в данном проекте по следующим причинам.
- Принципиальная ориентация языков 4GL на совмещение в коде программы средств внешнего представления данных и средств их обработки. Мы считаем, что это крайне неэффективно и усложняет разделение труда между разработчиками, сопровождение и модификацию крупного проекта.
- Ограниченные возможности и выразительные средства таких языков. 4GL дает возможность быстро создать небольшую программку для складского учета. Он не требует высокой квалификации программиста и избавляет его от необходимости знать многие тонкости. Но для профессионала это уже не является заметным преимуществом, а упрощенная структура языка не позволяет ему пользоваться многими достижениями в области технологии программирования, которые реализованы в языках класса C++. Как следствие, для квалифицированного программиста наступает момент, когда использование 4GL тормозит работу.
Ускорение кодирования не вносит существенного вклада в скорость создания большого приложения. Собственно кодирование занимает максимум 10% времени работы опытного разработчика, и сокращение этого времени даже в 10 раз не становится решающим фактором. Остальные 90% времени у команды программистов занимает постановка задачи, создание проекта, обсуждение общей архитектуры, моделирование, отладка, написание спецификаций. По нашему мнению, использование быстрого средства разработки может затормозить эти остальные 90% работы из-за бедных возможностей таких средств.
На Рис. 1 приводится планировавшаяся нами общая архитектура программной системы (итоговый вариант полностью совпадает с запланированным). В соответствии с трехуровневой моделью организации логики приложения, в обработке информации участвуют три программные подсистемы:
- Программа-СУБД CA-OpenIngres на компьютере-сервере
- Серверный программный комплекс, размещенный на компьютере-сервере. В общем случае этот сервер может не совпадать с сервером, на котором работает СУБД. Серверный комплекс принимает (средствами монитора транзакций, в нашем случае — TUXEDO) и обрабатывает запросы клиентской программы. В такой схеме серверная программа берет на себя сложную обработку данных, а клиентская управляет пользовательским интерфейсом. Серверы приложений работают на UNIX-сервере и связаны сетевым протоколом TCP/IP с клиентскими компьютерами, работающими под MS-Windows 3.1 (имеется версия клиентской программы для Windows NT). Подобная схема позволяет совместить высокую надежность и эффективность обработки данных, так как отвечающая за работу с данными серверная часть расположена на мощной RISC/UNIX платформе, а клиентская — на привычной Windows-платформе.
- Клиентский комплекс, работающий на компьютере-клиенте.
Программа-клиент оперирует объектами — например, объект лицевой счет. Обращения к СУБД скрыты в методах классов и осуществляются посылкой запроса серверной части банковского программного комплекса. На центральной машине монитор транзакций принимает запрос, определяет его адресата и передает для выполнения конкретному серверному процессу. Этот процесс для выполнения запроса может обращаться к СУБД, к любым системным ресурсам и к другим программам-серверам, в том числе, возможно, находящимся на других центральных машинах (в другом филиальном "кластере", например).
Мы предполагали создать следующие группы серверных приложений.
- Группа, предоставляющая конечному пользователю гибкую настраиваемую систему просмотра базы данных.
- "Машина проводок", объединенная с системой документооборота.
- Система жесткой (встроенной в программный код) основной финансовой отчетности.
- Система создания произвольных отчетов.
- Система поддержания справочников.
- Система встроенной электронной почты.
- Контрольно-статистическая система.
В целом нам удалось в процессе разработки выдержать такую схему. Но серьезной настройке были подвергнуты внутренние составы каждой из групп. В основном изменения шли по линии снижения среднего времени отклика системы.
Используемая СУБД
Для реализации конкретного проекта, по совокупности качеств (общие возможности, соответствие промышленным стандартам, поддержка, ценовая политика, простота инсталляции и эксплуатации) специалистами Jet Infosystems была рекомендована новейшая реализация СУБД Ingres в версии OpenIngres. В целом такое решение себя оправдало. Но при создании системы было принято решение не использовать без особой необходимости специализированных функций OpenIngres для сохранения возможности переноса системы на другие СУБД (например, Informix или Oracle).
Аппаратно-программная платформа
Приложение-клиент создавалось для среды MS-Windows 3.1 с использованием всех возможностей этой графической оболочки по организации недорогого пользовательского интерфейса. Самую же ответственную часть, сервер приложения, мы реализовали, используя мощные средства разработки, предоставляемые ОС UNIX. В качестве конкретного ее воплощения была выбрана платформа Sun, операционная система Solaris 2.x.
Надежность и возможности ОС UNIX нами были оценены очень высоко. После реализации этого проекта мы пришли к уверенности, что UNIX сейчас (и в обозримом будущем) представляется единственно возможным реальным выбором для создания крупных проектов.
Современные реализации ОС UNIX имеют развитый графический интерфейс на основе X-Window. UNIX позволяет пользователю (особенно такому требовательному, как системный администратор) иметь одновременный доступ к самым разным способам представления информации и манипулирования ею.
Solaris 2.x был выбран как самый "открытый и стандартный" UNIX. Здесь сыграла роль и великолепная совместимость (бинарная и на уровне исходных текстов) решений фирмы Sun Microsystems — от дешевых рабочих станций до корпоративных серверов. Это было очень важно для реализации подлинно масштабируемого проекта. Хорошая операционная система UnixWare фирмы Novell в данном случае оказалась менее привлекательной из-за ее узкой направленности на платформу Intel. Требование открытости системы заставило нас выбрать Solaris, который работает на таких основных платформах, как SPARC, Intel, а теперь еще и PowerPC.
Solaris 2.x предоставляет программисту возможность использовать все имеющиеся ныне достижения в области операционных систем. Как "правоверный" UNIX, Solaris реализует механизм вытесняющей многозадачности. При этом операционная система оптимизирована для использования компьютеров с симметричной многопроцессорной архитектурой (в том числе и на платформе Intel), для которых дает почти линейное ускорение выполнения задач с ростом числа процессоров. Естественно, Solaris поддерживает многопотоковые приложения.
Solaris удовлетворяет всем существующим ныне стандартам UNIX-систем. Для работы большой организации важно то, что все средства поддержки работы в локальной и глобальной сетях встроены в операционную систему. Удобный графический интерфейс способствует повышению производительности труда программиста. Для Solaris создано большое число серверных приложений.
Среди мониторов транзакций для UNIX абсолютное лидерство по числу установок и объему продаж удерживает TUXEDO фирмы Novell. Кроме того, он обладает самым простым API-интерфейсом среди мониторов транзакций. На TP-мониторе TUXEDO, версии для Solaris 2.x, мы и остановили свой выбор.
TUXEDO поддерживает распределенные транзакции, прозрачное взаимодействие программ в разнородной сети, обмен сообщениями с гарантированной доставкой, программный интерфейс DCE RPC и множество других средств для облегчения жизни разработчику сложного программного продукта. В принципе, программист избавляется от необходимости обязательного использования многочисленных сетевых и системных программных интерфейсов ОС UNIX, так как TUXEDO содержит все средства для организации распределенной обработки данных.
В качестве метода обработки данных мы были вынуждены искать необходимый в банковской системе компромисс между системой оперативной обработки транзакций (OLTP) и системой поддержки принятия решений (DSS), поскольку банковская специфика требует обоих подходов. Например, движение платежных документов в организации — это сравнительно простые и быстрые транзакции, а расчет показателей деятельности банка за определенный период — это система поддержки принятия решений. К сожалению, эти подходы вступают в противоречие друг с другом в области оптимизации алгоритмов. Современные производители СУБД утверждают, что их продукты одинаково хорошо поддерживают оба режима работы, но проблема остается в способе представления данных. На наш взгляд, нам удалось успешно решить эту проблему.
Организация работы
Проектирование и создание больших систем имеет существенное отличие от создания небольших и средних систем. Оно заключается в том, что сложность большой системы становится самостоятельным фактором. Сложность большого проекта превосходит обычные человеческие возможности и вызывает необходимость применения особых приемов организации разработки программного продукта. Ниже приведены основные принципы построения такой системы.
Наилучший результат получается при работе меньшего числа лучших людей. Если обеспечить соответствующими условиями работы небольшой коллектив высококвалифицированных специалистов и организовать взаимодействие между ними, то работать они будут существенно эффективнее, чем большое число средних программистов. При большом количестве работников сложность управления коллективом множится на сложность самого проекта и превышает мыслимые размеры. Могут позволить себе задействовать сотню и больше программистов в одном проекте лишь фирмы масштабов и опыта IBM, AT&T или Novell. При меньших возможностях фирмы попытка создать проект силами такого большого коллектива приведет к неуправляемости и неустойчивости проекта и к исчезающе малой производительности труда разработчиков.
Мы были далеки от мысли, что обладаем значительным know-how в области управления проектами и решили ограничиться небольшой (до 10 человек) группой профессионалов. Конечно, для обеспечения гладкого функционирования такой группы нужна поддержка работников иных специализаций — системных администраторов, например. Такая группа является самоорганизующейся и, методами проб и ошибок, как показывает опыт, выдает нужный результат. Попытка увеличить группу хотя бы до 12-14 человек приведет к неизбежному разрастанию коллектива до 25-30 человек (за счет управленцев) из-за необходимости организовывать сложное взаимодействие между ними, при этом общая производительность труда группы разработки не повысится.
Как уже упоминалось, важным является наличие постановщика задачи. Это снижает непроизводительные затраты труда на организацию взаимодействия программистов с заказчиком. Полностью исключить контакт программист-заказчик все-таки было бы вредно. В отрыве от заказчика программист создает такие великолепно-абстрактные продукты, как 'grep' и 'awk'. Такие программы прекрасно решают поставленные перед ними задачи. Автор статьи ими сам с удовольствием пользуется. Но вот обычные пользователи (не программисты) почему-то пользуются простыми программами производства Microsoft и Symantec, и ни в какую не желают писать командные скрипты для 'awk'. Поскольку большинство больших проектов пишутся для таких вот простых людей, программист должен иметь некоторое представление об их менталитете, что достигается непринужденной беседой с заказчиком.
Строгая сегментация задачи позволяет сильно снизить общую сложность системы. При увеличении количества сильносвязанных компонент в системе ее сложность растет экспоненциально, а при добавлении слабосвязанных — линейно. Поэтому мы следили за тем, чтобы части системы были максимально независимы и взаимодействовали по строго определенному протоколу. Выбранная нами архитектура проекта с монитором транзакций разграничила клиентскую и серверную части проектов. Кроме того, специальные методы применялись для более мелкого деления программ. Другая связанная проблема — повторное использование кодов. Пока она решается волевым назначением кода повторно используемым. К сожалению, создание программ обработки данных для реляционной базы данных не позволяет в полной мере использовать объектный подход (в серверной части программы) без потери эффективности работы программы. Иной подход, ориентированный на потоки данных, по мнению специалистов, меньше подходит для реализации больших проектов. Поэтому мы были вынуждены искать разумный компромисс, что привело к некоторому гибридному варианту. С появлением объектно-ориентированных вариантов СУБД лидирующих производителей положение может упроститься.
Существующие системы создания пользовательского интерфейса позволяют использовать объектный подход в полной мере, чем мы с удовольствием и воспользовались при реализации клиентской части программы.
В процессе создания проекта мы пришли к выводу, что существующие инструменты создания приложений выгодны для группы разработчиков. Вложенные средства с лихвой окупаются экономией затрат труда. Так что мы старались не экономить на инструментах.
К счастью, многие существенные для программиста утилиты встроены в операционную систему UNIX и часто полностью покрывают все запросы разработчика.
Примененная нами схема циклической разработки, когда в изменении находятся и постановка задачи, и проектирование, и программирование, и тестирование привело к быстрой "оборачиваемости" информации в проекте. Ни на одном этапе информация не задерживалась, и сразу становилась доступной заинтересованным лицам. А, по нашему мнению, скорость прокрутки информации является решающим фактором для скорости создания приложения.
Какие мы использовали подходы
Обеспечение максимальной надежности
Наш выбор состоит в том, чтобы критические участки комплекса использовали по возможности готовые решения. Так обстоит дело в обеспечении физической целостности базы данных ("удар" держит СУБД OpenIngres), в механизме передачи сообщений (тут работает монитор транзакций и протокол TCP/IP), а также в экранном интерфейсе (здесь мы использовали библиотеку Microsoft MFC). В тех же случаях, когда критическими являлись участки кода самой программы, мы применяли следующие принципы:
- все важные изменения в базе данных делаются с применением протяженных (multistatement) транзакций;
- все критические участки располагаются в серверной части комплекса;
- сервер приложения функционирует в надежном UNIX-окружении;
- сервер приложения расположен на RISC-компьютере.
Поскольку бесполезно добиваться надежной работы от приложения, работающего под управлением MS-Windows, мы решили вопрос надежности в этой области кардинально. Сбой клиентского приложения вообще не влияет на целостность базы данных и на работу остальных пользователей, так как клиентское приложение не взаимодействует напрямую с СУБД. Если "упала" клиентская программа, следует просто осуществить ее перезагрузку.
Обеспечение "прозрачного" выполнения всех корректных банковских операций
Для удовлетворения этому требованию нам пришлось погрузиться в детальный разбор алгоритмов бухгалтерии. Некоторые сложившиеся у нас к тому времени стереотипы по поводу построения базы данных пришлось пересмотреть. Особые сложности возникли с внесением изменений в базу данных задним числом. Нам удалось построить структуру данных таким образом, чтобы подобные изменения корректно отрабатывались без всяких "откатов", что особенно важно в валютной части программы из-за усложнений, вносимых переоценками. Как следствие, наша система позволяет работать любому количеству пользователей в любом количестве операционных дней параллельно (конечно, "задним числом" могут работать только пользователи с достаточными полномочиями).
Необходимость исключить особые режимы и периоды технологических работ привела к построению сложной системы блокировок базы данных. Все действия в базе данных были разбиты на три крупные группы ("не требующие никаких блокировок", "требующие блокировки на чтение", "требующие блокировки на запись"), и в дальнейшем производилась настройка конкурентности запуска процессов из разных групп для исключения взаимного влияния. В результате все административные работы в СУБД выполняются на фоне обычной ежедневной деятельности.
Совместная работа валютного и рублевого управлений банка
Мы использовали схему многовалютной базы данных, при которой имеются независимые плоскости счетов для каждой из валют и все операции совершаются в рамках одной плоскости. Но такая общепринятая международная практика вступает в противоречие с используемыми в отечественной бухгалтерии алгоритмами, например, конвертации. Для решения этой проблемы нами было использовано понятие счетов-проекций для некоторых валютных счетов (например, для группы 76-х счетов). В результате мы получили возможность совершать любые требуемые операции, не нарушая при этом баланса по каждой отдельно взятой валюте.
Связь с филиалами
Связь с московскими филиалами и отделениями осуществляется через выделенные линии "Голденлайн" и маршрутизаторы Welfleet. Организация обмена между клиентской и серверной частями программы через высокоуровневый протокол позволила свести трафик в сети к минимуму и осуществить прозрачную работу в глобальной сети. Проводившиеся нами опыты показали, что такой подход гораздо эффективнее (и проще), чем варианты с терминальным доступом по выделенной линии (например, X-терминал или способы эмуляции удаленного доступа в MS-Windows).
Программа-сервер является, с точки зрения программы-клиента, высокоуровневым сервером базы данных. Эта "СУБД" понимает и выполняет такие высокоуровневые команды, как "создать документ", "выполнить такой-то отчет" и т.п. В результате, например, при вводе документа, по сети передается только один пакет, хотя в системе эта операция может вызвать сотни обращений к СУБД в случае сложной финансовой транзакции.
Мы считаем, что в области масштабируемости организации межфилиальных взаимодействий мы добились неплохих результатов. Если иметь в виду время прохождения платежей из филиала в филиал, составляющее доли секунды, то, по предварительным расчетам, вычислительный центр в Москве на основе ЭВМ класса Cray-6400 или SPARCcenter 2000 способен обеспечить работу в единой базе данных нескольких десятков филиалов. В нижней части спектра масштабируемости SPARCserver 20 обеспечивает работу 2-3 средних филиалов или 3-5 небольших отделений.
Открытость алгоритмов обработки данных
Для выполнения этой задачи нами применялись:
- схема объектной организации документооборота;
- настраиваемый план счетов;
- настраиваемые способы ведения счетов.
Программные спецификации, прилагаемые к системе, дают возможность дорабатывать ее в соответствии с собственными представлениями программистов других банков о том, что и как должна делать банковская программа. Спецификации позволяют создавать новые программные модули в таких системах, как DOS, MS-Windows, UNIX. Дополнительно прилагается С-подобный язык скриптов (командных файлов) и интерпретатор этого языка. Это средство позволяет организовывать сложную пакетную обработку данных (например, связь с системой "клиент-банк").
Безопасность и контроль прав доступа
Права доступа пользователя хранятся в специальной таблице в базе данных. Для каждого пользователя может быть предусмотрена гибкая система контроля прав в зависимости от выполняемых им действий. В общем случае каждый пользователь обладает уникальными, присущими только ему правами в системе, и таким образом настраиваются рабочие места пользователей в зависимости от их функций.
Каждое действия пользователя (каждое обращение к серверу) вызывает проверку полномочий пользователя на данное конкретное действие. Эта проверка совершается оптимальным образом и не влияет на производительность системы. В случае если пользователь не имеет полномочий на совершение действия, ему выдается соответствующее сообщение. Если же полномочия имеются, на время совершения действия пользователь получает "билет", в котором детально описаны особенности полномочий данного пользователя на данное действие (например, имеет ли пользователь право создания валютных документов). Сразу после выполнения действия "билет" уничтожается. По сети "билет" не передается и недоступен для прослушивания.
Для настройки безопасности документооборота система позволяет определить положение пользователя в потоке документов и доступную ему информацию. В процессе своего существования документ фиксирует пользователей, совершавших над ним действия, а также даты этих действий.
Результат проекта. Что "умеет" система RP/3
Система, создававшаяся и тестировавшаяся в течение 1994 года, была введена в промышленную эксплуатацию 4 января 1995 года в валютном управлении АКБ "РПБ". 18 сентября началась эксплуатация системы во всех функциональных и территориальных подразделениях банка. Все фундаментальные алгоритмы (связанные с движением денежных сумм в банке) прошли серьезную и длительную проверку в реальных условиях. Время показало, что выбранная схема себя оправдала.
Внедрение системы RP/3 в АКБ "РПБ" было сопряжено с трудностями, связанными с коренной перестройкой методов работы бухгалтерии банка в результате перехода на новые принципы организации труда. Теперь основным показателем качества и скорости выполнения работы являются интегральные показатели, а не отдельно взятые операции. Поясним на примере. Ранее высокой скоростью работы программы называлась способность программы быстро ввести в базу данных платежный документ. Не принималось во внимание то, что потом на работу с этим документом и на обработку порождаемой им информации уйдет большое количество рабочего времени. Система RP/3 создавалась в расчете на сокращение общего количества времени и сил, затрачиваемого работниками банка на обработку платежных документов и связанных с ними отчетов.
В банке много разнообразных рабочих мест и сложно описать все типичные режимы работы. В качестве примера вкратце опишем типичный рабочий день рублевого операционного отдела АКБ "РПБ" (BackOffice).
Рабочий день для программной системы RP/3 начинается на 1 час раньше, чем для "живых" работников банка. Примерно с 8 часов утра она начинает звонить в МЦИ и РКЦ для получения утренней информации. Процесс этот протекает в "сотрудничестве" с внешними программами дозвона, взаимодействие с которыми осуществляется с помощью встроенного интерпретатора C-подобного языка макросов. Написанные администратором системы "сценарии работы" (или, иначе, "скрипты") выполняют вызовы внешних программ, первичную обработку результатов полученной по модему информации, автоматический ввод документов в базу данных. Автоматически выполняются и некоторые нетривиальные действия: например, вводится в базу данных информация о новых банках и производится частичная или полная оплата поступивших документов, а также делается попытка корректно отреагировать на нестандартные ситуации, часто возникающие при связи с РКЦ или МЦИ. К приходу основной массы работников банка частично или полностью обработанные документы уже находятся в базе данных. Для клиентов, находящихся на специальном обслуживании, уже готова выписка по результатам утренней связи.
Далее, в течение рабочего дня операционисты производят разбор поступивших по почте сообщений и "разносят" их в базе данных, а также принимают и вводят в базу данных платежные поручения от клиентов банка. Платежи, приходящие от клиентов по модемной связи, обрабатываются автоматически. В определенные моменты времени происходят сеансы связи с РКЦ и МЦИ для отправки и получения информации о движениях денежных сумм.
Межфилиальных платежи внутри РПБ представляют собой движения средств в единой базе данных АКБ "РПБ" и происходят с повышенной (по сравнению с межбанковскими платежами) скоростью.
В течение рабочего дня операционисты делают массу различных отчетов. Спецификации этих отчетов заранее создаются администратором системы, который не является программистом. В случае появления необходимости в новом отчете или изменения требований к уже существующему, администратор имеет возможность оперативно на эту ситуацию отреагировать.
Операционистом становятся видимыми и доступными для обработки документы, порождаемые другими подразделениями (например, кассовые документы). Документы, не предназначенные для обработки рублевым операционным отделом (например, большинство валютных документов) невидимы для операционистов этого отдела.
В конце рабочего дня происходит проверка документов и распечатка выписок. Закрытие и повторное открытие операционного дня может быть выполнено в произвольный момент в будущем.
Другие отделы банка (бухгалтерия, валютное управление, дилинг, биржевой отдел, кредитный отдел, касса, SWIFT и др.) работают по специфической для них схеме и имеют собственные потоки документов, пересекающиеся друг с другом.
Кратко опишем подсистемы программного комплекса.
В системе нет отдельных АРМов, есть единое настраиваемое рабочее место сотрудника банка. К такому решению мы пришли на основании личного опыта эксплуатации банковских программных комплексов. Поэтому для описания возможностей системы мы пользуемся термином "режим работы", а не "рабочее место".
Подсистема ведения счетов
План счетов заполняется и модифицируется администратором. Счета в системе группируются по балансовым счетам 1-го и 2-го порядка, по субсчетам, по филиалам, отделениям, подразделениям, по классам. Полный список группировки счета представлен на Рис. 2, а на Рис. 3 представлен некоторый примерный счет.
Для реализации гладкого взаимодействия валютных и рублевой плоскостей счетов мы ввели понятие счета-проекции. На такой счет автоматически проецируются рублевые обороты некоторых валютных счетов (например, счетов валютных позиций) и это позволяет автоматизировать операции по конвертации средств, не нарушая валютных балансов.
Применение счетов-проекций может быть и более широким. Например, счета по обслуживанию физических лиц могут проецироваться на один интегральный счет.
Система платежного документооборота
Документ в системе представляет собой объект некоторого класса с возможностью настройки его свойств. На Рис. 4 представлена запись в таблице классов для "поручения входящего", на Рис. 5 — список возможных состояний документа этого класса, на Рис. 6 — список возможных изменений ("переходов"), которые документ может претерпевать в процессе своей "жизни". "Переходы" являются аналогами методов класса в объектно-ориентированных языках программирования. При этом поддерживаются такие свойства, как наследование и перегрузка функций.
По желанию администратор может просматривать список "переходов" в виде графа, и такой граф для "поручения входящего" представлен на Рис. 7.
Внешний вид "поручения входящего" представлен на Рис. 8. На Рис. 9 показан вид обобщенного документа.
Класс документа "поручение входящее" создан и настроен администратором системы без участия программиста.
Система платежного документооборота тесно связана с системой учета кассовых операций, системой учета валютных контрактов и системой картотек. Поддерживается отмена любых операций. Обеспечивается прозрачная работа задним числом с пересчетом показателей. При этом не требуется совершать "откат", одновременно в системе может работать произвольное количество пользователей с произвольным количеством разных операционных дней.
Подсистема учета валютных контрактов
Общий вид валютного контракта представлен на Рис. 10. Система позволяет отслеживать валютные контракты и выдавать необходимую отчетность по ним. Тесная связь с платежным документооборотом позволяет полностью автоматизировать этот процесс и исключить необходимость в какой-либо перекачке данных из одной подсистемы в другую.
Подсистема учета кассовых операций
Позволяет создавать кассовые счета и учитывать на каждом из них обороты по различным кассовым символам. Не требует специальных трудоемких действий, так как интегрирована с документооборотом.
Подсистема картотек (справочников)
В картотеках учитываются клиенты, валюты, страны, банки, связи между банками, связи между банками и клиентами. Ведение картотек неразрывно связано с платежным документооборотом.
Встроенная электронная почта
Каждый клиент имеет почтовый ящик и может обмениваться файлами и сообщениями любого размера и формата с другими клиентами. Подсистема интегрирована с документооборотом. Типовой экран — на Рис. 11.
Вспомогательные подсистемы для администратора
Это система создания скрипов импорта-экспорта, система гибких отчетов, система настройки прав пользователя, система трассировки обмена. Пример настройки прав некоторого пользователя приведен на Рис. 12.
Перспективы
В области автоматизации банковской деятельности невозможно продвинуться настолько далеко, чтобы можно было успокоиться. Задача автоматизации крупного банка такова, что она способна поглотить любое количество человеко-лет рабочего времени, и при этом конца будет все же не видно. Руководитель банковского проекта вынужден строго подходить к расстановке приоритетов решаемых задач. Любой банковский проект представляет собой лишь некоторое приближение к идеалу, к "полной системе". Поэтому так важна "открытость" системы, позволяющая ей работать вместе с другими, дополняющими ее, программными комплексами.
Первая очередь системы была введена в промышленную эксплуатацию в РПБ 4 января 1995 года.
18 сентября введена в эксплуатацию вторая очередь системы, которая включает в себя полный рублевый документооборот.
В момент написания статьи вторая очередь функционировала во всех московских филиалах банка и в его центральном отделении. Единая база данных позволила достаточно просто получать интегрированные экономические показатели по банку в целом, не только по отдельным филиалам.
Для 3-й очереди системы запланированы следующие нововведения.
Документооборот, включающий в себя не только платежные документы, но и любые бумажные формы с возможностью их гибкой настройки. Интеграция в банковскую систему всех потоков документов в банке. Создание хранилища исходных образов документов (вместо бумажного архива), что позволит не держать огромные неудобные бумажные архивы в каждом филиале банка и даст возможность организовать быстрый поиск нужной информации.
Создание аналитической подсистемы для углубленного анализа показателей деятельности банка. Система прогнозирования показателей. В текущей версии системы анализ показателей производится с помощью специальных отчетов. В третьей версии эти функции будут поддерживаться ядром системы.
Система автоматизации деятельности кредитного отдела.
