SOA-архитектура – современная вершина эволюции. Лучшая статья (12-18.04.11) в «Творчестве без купюр»

Константин Фильчагин

Когда и мы, и банковские информационные технологии в России были совсем юными, основной парадигмой была борьба с лоскутной автоматизацией. Считалось, что для того, чтобы все информационные системы банка быстро и хорошо работали, они должны войти в состав единой АБС или, по крайней мере, быть разработкой одной компании. Но сегодня стало очевидно, что одна, даже самая хорошая автоматизированная система, не покрывает растущий перечень банковских продуктов, к тому же «монстроидальность» системы часто мешает модифицироваться под меняющиеся требования.

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

SOA-архитектура необходима каждому банку, который думает о завтрашнем дне

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

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

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

SOA-архитектура - это именно то, что нужно

Если банк планирует развиваться и при этом не быть заложником отдела автоматизации, ссылающегося (и часто справедливо) на сложность внедрения новых систем и невозможность изменения технологий работы старых, то SOA-архитектура - это именно то, что нужно. SOA-архитектура - это современная вершина эволюции развития ИТ-решений для бизнеса. Она изначально создавалась для быстрого реагирования на изменения требований рынка и безболезненного наращивания сервисов, предоставляемых клиентам. Я не буду вдаваться в технические нюансы, но SOA позволяет выбрать для банка лучшее программное решение и с минимальными усилиями его интегрировать в банковскую информационную систему. Кроме того, одной из составных частей новой архитектуры являются средства управления, мониторинга и анализа бизнес-процессов (BPM-системы) - вершина айсберга SOA. Использование BPM-систем позволяет организовать более эффективное взаимодействие между бизнесом и ИТ банка, лучше эксплуатировать существующие и ускорить разработку новых продуктов.

Другой пример - российские «дочки» иностранных банков. Зарубежные финансовые структуры чаще всего приходят на российский рынок со своей методологией, продуктовым рядом и своим стандартным программным обеспечением, всем тем набором, который успешно используется во многих странах мира. И сталкиваются с особенностями российского законодательства и правил бухгалтерского учета. Решений в данной ситуации много - от работы параллельно в двух системах и до локализации зарубежного банковского ПО, но самым проверенным и эффективным способом оказалась интеграция западной и российской АБС в соответствии с принципами SOA-архитектуры. В этом случае за правила российского бухучета и отчетность для ЦБ РФ отвечает российская АБС, а фронтальное решение, продуктовый ряд и управленческую отчетность обеспечивает западное ПО.

Перейти на SOA-архитектуру «в одиночку» у банка вряд ли получится

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

Таким образом, внедрение SOA-архитектуры - это длительная и кропотливая работа, требующая от всех участников проекта высокой квалификации и занимающая большое количество времени, причем очень важную роль играет первичная проработка и проектирование системы. Исправление просчета, допущенного на этапе проектирования решения, обходится в большие потери времени и, соответственно, денег. В частности, в одном из проектов специалисты банка, разрабатывавшие схему интеграции АБС и ДБО для частных лиц (работающую в режиме 7х24), не предусмотрели хранения данных во время технологических остановок АБС, что могло привести к утере информации о платежах клиентов. Наши технологи предложили направить информационные потоки через внедряемую параллельно CRM-систему, в которой и так должна отражаться информация обо всех частных клиентах, продуктах и операциях.

Роль интегратора

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

Наша компания, увидев преимущества этого подхода, одной из первых стала продвигать принципы SOA на рынке ИТ-услуг для финансового сектора России. В 2000 году, когда рынок подобных решений еще не был достаточно развит, мы выпустили свой продукт для построения SOA-архитектуры - шину данных eXtream, в которой использовали международный финансовый стандарт обмена сообщениями - FDX на основе XML-сообщений. И если в 2002 году мы каждому клиенту рассказывали о перспективности подобных решений и преимуществах интеграции различных сервисов при помощи ESB, то на сегодня все наши клиенты, как минимум, знают все «за» и «против» сервисо-ориентированной архитектуры, и около трети из них полностью или частично ее используют. Это - очень обнадеживающая тенденция.

В 2007 году мы провели тщательный анализ поставщиков SOA-платформ, оценили плюсы и минусы нашего решения в сравнении с промышленными решениями крупнейших мировых производителей SOA-платформ и пришли к выводу, что продукты мировых поставщиков SOA-платформ для финансового сектора удовлетворяют всем требованиям бизнеса, и продолжать поддерживать свое решение нам не имеет смысла. В ближайшее время мы планируем заменять свое решение аналогичными решениями от Sonic Software Corp, Oracle и IBM.

Расскажите коллегам:
Эта публикация была размещена на предыдущей версии сайта и перенесена на нынешнюю версию. После переноса некоторые элементы публикации могут отражаться некорректно. Если вы заметили погрешности верстки, сообщите, пожалуйста, по адресу correct@e-xecutive.ru
Комментарии
IT-менеджер, Москва

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

Консультант, Москва

Раз. Автоматизация - это не стратегия, а инструмент ведения бизнеса. И любая ERP-система - ну, грубо говоря, что набор пассатижей и гайковёртов для сервис-центра, экскаватор и бетономешалка для строительной организации, и т.п.
Два. СОА, как маркетинговое детище ИБМ, красиво на бумаге - но на практике из неё получаются весьма сложные и дорогостоящие монстры.
Три. А как, извините, банки работали 50 и более лет назад???

Нач. отдела, зам. руководителя, Москва
Борис Зверев пишет: Два. СОА, как маркетинговое детище ИБМ, красиво на бумаге - но на практике из неё получаются весьма сложные и дорогостоящие монстры.
Реально SOA - это было только начало :) и может быть тормозом (слишком медленно работает) для критических задач. И кстати, Enterprise Service Bus вот что продвигает IBM и не только IBM, а SOA это только часть системы обмена данными, не понял почему автор не упомянул. SOA интересно для распределённых систем, и даже в этом случае, для критических задач разработчик часто выберет решение на сокетах. Да, много лет назад говорили :) что SOA интересно для объединения различных модулей ERP от разных разработчиков, но получилось как в басне Крылова Лебедь, рак и щука.
Нач. отдела, зам. руководителя, Москва
Максим Артамохин пишет: Не очень согласен с тем, что изначально как ''панацея'' предлагается системное решение завязанное на конкретные технологии. На мой взгляд, выбор технологии всегда вторичен.
Конечно, не панацея, просто поддерживается многими разработчиками - в этом плюс. Для обмена данными вполне годится, но внутри любой ИС есть более шустрые технологии, которые можно завязать на ту же Enterprise Service Bus и т.п.. Будет работать быстрее, чем только на SOA
Консультант, Москва
Александр Соловьев пишет: И кстати, Enterprise Service Bus вот что продвигает IBM и не только IBM, а SOA это только часть системы обмена данными, не понял почему автор не упомянул.
Я про ESB слышал от самих ИБМ-овцев ещё лет 6 назад. На картинке всё красиво получалось. Вот только на практике ''конвертеры'' разных ''зоопарков'' к общей шине данных оказались настолько монструозными, что целую линейку аппаратных (''блейдов'' 4 дюйма) и дорогостоящих средств ИБМ стала называть... ''средствами интеграции бизнес-процессов'' (запихнув внутрь аппаратные конвертеры чего-то там в XML, сочтя это ''интеграцией БП'')
Нач. отдела, зам. руководителя, Москва
С аппаратными конвертерами не приходилось иметь дело - только софтовые решения. Если говорить о примерах больших распределённых систем, то на аутсорсинге участвовали в разработке системы ''Одного окна'', которая работает в некоторых Управах г. Москвы. Чтобы понять, о чём идёт речь: разные поставщики обслуживают разные префектуры, ИС разные, и даже написаны на самых разных языках программирования. Но каждая система посылает запросы во все другие, для получения нужной информации – Замечательно работает и, но использовать подобное SOA-решение в локальных системах? - Можно, умеем, но тормоза очень большие. Автор использует в статье для сравнения с SOA совершенно невыразительный пример: ''лоскутная автоматизация'' + ''Если пытаться связать их по старинке, ''точка-точка'' через текстовые файлы''. Термин ''лоскутные'' не слышал уже лет 10 , т.к. он давно потерял актуальность :) А TXT файлы – это конечно один из методов, но кто же сейчас так работает? :) Системная интеграция позволяет находить оптимальные решения и существует Множество методов, для организации обмена данными между различными информационными системами 8) . И даже больше, есть возможность встраивания одного приложения в другое: Например, задача добавить для Windows приложения от сторонних разработчиков преимущества программ на платформе .Net. Это огромная экономия, если учесть, сколько было затрачено на разработку и внедрение этого приложения. Используем такое решение, когда все компоненты ИС Windows и .NET работают в одном окошке - интерфейс общий, и такая ИС работает с очень высокой скоростью. SOA - это ещё не вершина эволюции :D и есть ли она эта вершина 8) . - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -- - - - - - ''И вы не по заслугам именуетесь почетным святым. Вы отшельник, подвижник, но не святой. Не святой. Нет''. Обыкновенное чудо.
Консультант, Москва
Александр Соловьев пишет: С аппаратными конвертерами не приходилось иметь дело - только софтовые решения.
К сожалению, ссылку не сохранил (когда-то, года 3 назад, слушал ИБМ-овский вебинар по этим блейдам), но что-то ''общетеоретическое'' есть тут.
Александр Соловьев пишет: Термин ''лоскутные'' не слышал уже лет 10 , т.к. он давно потерял актуальность
А что плохого в ''лоскутном'' одеяле? ;) Даже если сшить белыми нитками - но аккуратно подобрать лоскуты, то в итоге получится неплохое изделие. Попытка же реализовать всё ''единообразно'' может стать ''безобразной'' - пример из личного опыта с попыткой построить ''универсальную'' АСУ на платформе 1С-УПП. Лоскутность там - просто караул (хотя, вроде бы, единая платформа и одни данные).
Александр Соловьев пишет: Системная интеграция позволяет находить оптимальные решения и существует Множество методов, для организации обмена данными и синхронизации данных в ИС. И даже больше, встраивание одного приложения в другое: Например, задача добавить для приложения на Win32 преимущества программ на платформе .Net.
В общем - да, но по частностям - не бесспорно. Есть, например, такие продукты, которые написаны в совсем другой среде, внешних концов, за которые зацепиться можно, не имеют, а исходников - нет, и переделать сложно (например, какие-то узкоспециализированные решения, в том числе, имеющие ''аккредитацию'' - знаю, что что-то подобное было в области промышленной экологии, когда только один программный продукт имел аккредитацию как ''проверенный и поверенный'', и хочешь-не хочешь, нужно было использовать только его; или приём фискальной отчётности в электронном виде - не просто оговорён открытый формат файла обмена данными, а чётко указан продукт, в котором формируется и в формате - закрытом - которого должны передаваться данные в налоговую инспекцию).
Нач. отдела, зам. руководителя, Москва
Борис Зверев пишет: не просто оговорён открытый формат файла обмена данными, а чётко указан продукт, в котором формируется и в формате - закрытом - которого должны передаваться данные в налоговую инспекцию).
В таких случаях, чтобы было ''без коммерческих тайн'' 8) , показываем примеры интеграции в нашу платформу, в которых в качестве сторонних программ используются игры из стандартной поставки Windows :) . Демонстрируем непосредственную работу с памятью сторонней программы: чтение, запись и управление из платформы. Синхронизации данных быстрее уже не бывает.
Оставлять комментарии могут только зарегистрированные пользователи
Статью прочитали
Обсуждение статей
Все комментарии
Дискуссии
3
Евгений Равич
Хороший пример конспирологии. Есть реальные примеры? Просьба заодно уточнить, что такое "не понр...
Все дискуссии
HR-новости
Половина россиян будут работать в майские праздники

Женщины чаще мужчин сообщали, что не собираются работать в государственные выходные.

Больше 70% россиян работают по выходным и во время отпуска

97% россиян регулярно задерживаются на работе.

В каких городах России наибольший прирост вакансий

В целом по России спрос работодателей за год вырос на 36%.

Исследование: какую зарплату хотят получать россияне

Пожелания по заработной плате мужчин и женщин коррелируются в зависимости от возраста соискателей.