журналы подразделения новости подписка контакты home

архив
2001 год
2002 год
2003 год
2004 год
2005 год
2006 год
2007 год
2008 год
2009 год
2010 год
рубрики
ИТОГИ И ТЕНДЕНЦИИ

Международные банки

БАНКОВСКИЕ СИСТЕМЫ

БАНКОВСКИЙ СЕРВИС

ИНФОРМАЦИОННЫЕ СИСТЕМЫ

ПЛАТЕЖИ

Банковское оборудование

ЭЛЕКТРОННЫЕ ДЕНЬГИ

Новые рыночные страны

Банковское регулирование

гостям
Агентство "Стандарт" предлагает вам подписаться на экномические журналы – лидеры в своей области.
























"Банковская практика за рубежом" – №11, 2005

ИНФОРМАЦИОННЫЕ СИСТЕМЫ

В поисках универсального рецепта

Преимущества и недостатки сервисно ориентированной архитектуры корпоративной IT-системы

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

Предел возможного

Частичная доработка действующей в реальных условиях IT-системы в большинстве случаев помогает решать лишь ограниченное число проблем. При этом, неоправданное расширение количества дополнительных программных модулей делает ее крайне громоздкой, что, соответственно, влияет на быстродействие осуществляемых операций и на качество работы в целом. Одним из возможных выходов из сложившейся ситуации может стать построение информационных бизнес-систем, имеющих сервисно ориентированную архитектуру (Service-Oriented Architecture – SOA).

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

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

История SOA насчитывает не один год, причем, появление интернет-технологий лишь стимулировало развитие данного направления. В свое время началом отсчета послужило обещание CORBA сделать возможной совместную работу программного обеспечения, созданного на разных гетерогенных платформах. Эта же проблема взаимодействия разных продуктов присутствовала всегда, так как было достаточно много абсолютно непохожих популярных разработок. В итоге была сформулирована задача создания практичной архитектуры, которая была бы простой и быстродействующей, а также обезопасила бы интеграцию систем и входящих заявок («applications» – «информация, поступающая на вход системы»).

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

Суровая проза жизни

Бизнес-задачи, стоящие перед IT-службами, зачастую одинаковы. Руководство компании всегда стремится к лучшему использованию IT, большему коэффициенту окупаемости инвестиций, интеграции исторически обособленных систем и более высокому быстродействию новых систем. Тем не менее, есть и различия, поскольку реальные жизненные условия, в которых работает фирма, все более усложняются.

Например, ограниченность бюджета во многих компаниях не дает возможности заменить устаревшие системы, вынуждая к их модернизации. В то же время, дешевый доступ к Интернету полностью обеспечил создание новой бизнес-модели электронного банковского бизнеса (она уже реализуется многими компаниями, оттого по возможности может быть оценена). Расширение за счет слияний и приобретений предполагает, что все IT-службы, заявки и инфраструктуры должны быть объединены.

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

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

Усиливает данную проблему и объединение отдельных систем. Любая организации в своей деятельности сталкивается с задачей интеграции того или иного вида. Это может произойти из-за слияния компаний, союза с новым партнером либо необходимости объединить существующие системы. Если n прикладных систем должны быть непосредственно связаны, это обусловит n (n-1) связей или интерфейсов (на рис. каждая стрелка представляет такой интерфейс).

Следовательно, если другая прикладная система n+1 должна быть объединена с данной, возникнет необходимость, чтобы 2n новых интерфейсов, которые будут произведены, были зарегистрированы, проверены и поддержаны. Исходя из рис. набор из пяти заявок требует 20 прямых интерфейсов, а дополнение шестой потребует уже десяти новых интерфейсов! Помимо этого, алгоритм каждой из существующих заявок должен быть изменен, чтобы включить новые интерфейсы, что обусловливает дополнительные затраты. Таким образом, формулируется задача поиска оптимального решения, которое производит минимальное число интерфейсов (n) для n заявлений лишь с одним новым интерфейсом для каждой дополнительно добавленной системы. К сожалению, такое решение не может быть реализовано лишь прямой связью.

Архитектурные

перспективы

За прошедшие десятилетия в технологии разработки программного обеспечения было использовано несколько моделей программирования. На определенном этапе Java-технология обеспечила программирование на нейтральной платформе, XML ввел самоописание, что упростило работу с данными. Позже интернет-разработки дали возможность взаимоувязывать заявки в объекте, моделируя нейтральный путь. Используя обыкновенную XML-базирующуюся передающую схему, Java-программы могут работать с DCOM-базирующимися, CORBA-ориентированными или даже с программами на языке COBOL. CICS- или IMS-трансакции на универсальной ЭВМ в Сингапуре могут быть вызваны COM-базирующейся заявкой, поддерживаемой Lotus Script, размещенным на сервере Domino в Мюнхене. Оптимальными для работы будут такие условия, когда место формирования заявки, язык и маршрут сообщения не станут иметь важного значения.

Вероятнее всего, в качестве наиболее приемлемого стандарта эффективного, надежного, масштабируемого и расширяемого взаимодействия «машина-машина» будут приняты интернет-системы.

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

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

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

В экономическом контексте SOA можно трактовать в качестве «прикладной архитектуры, в пределах которой все функции определены как независимые операции с четкими invokable интерфейсами (интерфейс, для методов которого доступна RTTI – информация о типах на этапе выполнения), находимыми в заданных последовательностях, с тем чтобы сформировать бизнес-процессы». В данном положении необходимо обратить внимание на следующее:

1. Все функции считаются операциями (т.е. просто деловые функции, хозяйственные операции, составленные из функций низшего уровня, и функции обслуживания системы).

2. Все операции независимы. Они работают как «черные ящики», т.е. выдают ожидаемый результат, не показывая сам процесс обработки.

3. В самом общем смысле интерфейсы должны быть invokablе. На архитектурном уровне не существенно, каковы они – местные (в пределах системы) или отдаленные (в систему поступают извне), какая к сети подключена схема или какой протокол используется, какие компоненты инфраструктуры обеспечивают связь.

Таким образом, интерфейс становится центром системы, определяя тем самым необходимые параметры и природу результата. В общем, операции действительно независимые, они могут быть управляемыми.

Популярность SOA

в банковской сфере

По данным исследования, проведенного компаниями

BearingPoint и Datamonitor, ведущие банки намерены наращивать использование SOA и менеджмента бизнес-процессов. Потребность в преобразовании наметила тенденцию к гомогенизации финансовых продуктов, что заставило банки обратить внимание на свой самый важный актив – информацию.

Управление отношениями с клиентами ставит банки перед необходимостью формирования единого представления клиента независимо от канала получения информации. Некоторые такие проекты создавались многие годы. Например, отделение Deutsche Bank согласно программе Future initiative, которую планируется завершить в 2007 году, в пределах своей основной инфраструктуры будет содержать перепроектированный интернет-банк, аналитическую платформу по управлению отношениями с клиентами и консультативную службу.

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

Архитектуру систем предприятия считают наиболее важным элементом в процессе преобразования. Больше половины респондентов в исследовании

BearingPoint и Datamonitor назвали сервисно ориентированную архитектуру крупным достижением в банковских услугах, и почти все они осуществили SOA.

В то же время, не все эксперты одинаково положительно оценивают возможности SOA, хотя и увеличивается число банков, реализующих серьезные проекты в этой сфере. Политику финансовых институтов понять можно. С позиции операционной системы, банки настолько законсервированы и загнаны в жесткие рамки, что изменить что-либо здесь сложно. Сами бизнес-процессы в течение последних 20 лет претерпели незначительные изменения. Ручные процессы были автоматизированы изначально, а последующие системы во многом копировали своих предшественниц. Изменялся лишь уровень сложности. Дженс Хенкер, партнер компании Accenture, в качестве примера приводит банк, входящий в ТОР-100, предлагающий на сегодняшний день более 350 финансовых продуктов, причем, этот показатель в 1985 году не доходил и до 100. Этот банк имеет 43 различных операционных счета и свыше 40 процессинговых центров. Не удивительно, что контакт с банками усложняется, в связи с чем падает качество обслуживания клиентов. До сих пор многие учреждения не могут сформировать единого представления клиента.

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

Для сравнения имеет смысл обратить внимание на опыт других отраслей экономики. Банки до сих пор сохраняют 80% своих операций внутри самой организации, пытаясь, в основном, действовать самостоятельно. В сферах электроники и автомобиле-строения сопоставимые данные свидетельствуют соответственно о 20 и 25%. Однако, никакие операции не могут быть вычленены и собраны в ином месте, если нет возможности прозрачных разрывов потока. Жесткие связи в общей цепи – главное препятствие в банковской отрасли.

Появляющиеся ныне проекты реконструкции всего предприятия имеют ряд общих черт. Здесь изменения предполагают ломку жестких структур обособленных подразделений, в результате чего общая деятельность перемещается в центральные офисы, которые могут стать центром привлечения инвестиций и повышения квалификации сотрудников. Эта задача, как правило, исходит из тенденции старта с уровня данных и моделирования процессов. Планирование существующей структуры с целью поиска оптимального варианта, ликвидация обособленных подразделений и интеграция бизнес-структуры – ключевые его этапы. Сроки, необходимые для преобразования всего предприятия, обычно составляют 5-7 лет (предусматривается поэтапное внедрение проекта).

Проект, реализация которого была начата в текущем году в британском Standard Bank, попадает в описываемую категорию. Банк стремится построить систему, которая базируется на CMF (основном файле клиента), используемом в операционных системах. Главная цель проекта – формирование максимально точной, ориентированной на клиентов, модели бизнеса.

Волна интереса со стороны банков к модернизации подогревается и самими провайдерами программного обеспечения. Появляются продукты для банковской отрасли от все новых и новых производителей. Кроме того, традиционные поставщики обновляют уже существующие разработки. Самый наглядный пример – компания Misys, усовершенствовавшая свою давнюю разработку Midas. Новое решение сориентировано на мультиюридическое лицо и предполагает централизованную обработку данных в отделе банка по трансакциям. Кроме того, здесь можно работать с различными языками – от RPG до Java. В первую очередь, новинка заинтересовала банки, имеющие многочисленные Midas-сайты. Сейчас Misys стремится сделать нечто подобное и с ориентируемым на розничную продажу программным пакетом Equation.

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

Людмила Тарнавская,
по материалам The Banker, IBM.com

 
© агенство "Стандарт"