soa что это в финансах
Общество актуариев (SOA)
Опубликовано 16.06.2021 · Обновлено 16.06.2021
Что такое Общество актуариев (SOA)
Сообщество актуариев (SOA), уходящее корнями в 1889 год, насчитывает более 31 000 членов во всем мире, это крупнейшая профессиональная организация такого рода в мире.1
Разрушение общества актуариев (SOA)
Общество актуариев (SOA) занимается исследованиями в области актуарных наук, профессионального развития и образования, а также профессиональных стандартов. Члены SOA обладают глубокими знаниями в области математики, статистики и управления бизнесом во многих отраслях, включая страхование жизни, здоровья и имущества, банковское дело, инвестиции, правительство, энергетику, электронную коммерцию, маркетинг, льготы для сотрудников, разработку продуктов, управление рисками предприятия, прогнозная аналитика, консалтинг и многое другое.
В этих отраслях актуарии работают над анализом рисков, используют методы моделирования и анализа данных на больших наборах данных, чтобы обнаруживать модели прогнозирования и взаимосвязи для использования в бизнесе, помогают устанавливать политики и уровни компенсации, а также обеспечивают широкий надзор за бизнесом и менеджментом, среди прочего.
Миссия организации – «продвигать актуарные знания и повышать способность актуариев предоставлять экспертные консультации и соответствующие решения финансовых, деловых и социальных проблем». Концепция SOA заключается в том, чтобы актуарии были ведущими профессионалами в области измерения и управления рисками.
Сервис-ориентированная архитектура (SOA)
Сервис-ориентированная архитектура (service-oriented architecture, SOA) придумана в конце 1980-х. Она берёт своё начало в идеях, изложенных в CORBA, DCOM, DCE и других документах. О SOA написано много, есть несколько её реализаций. Но, по сути, SOA можно свести к нескольким идеям, причём архитектура не диктует способы их реализации:
SOA — это набор архитектурных принципов, не зависящих от технологий и продуктов, совсем как полиморфизм или инкапсуляция.
В этой статье я рассмотрю следующие паттерны, относящиеся к SOA:
Общая архитектура брокера объектных запросов (CORBA)
В 1980-х началось активное использование корпоративных сетей и клиент-серверной архитектуры. Возникла потребность в стандартном способе взаимодействия приложений, которые созданы с использованием разных технологий, исполняются на разных компьютерах и под разными ОС. Для этого была разработана CORBA. Это один из стандартов распределённых вычислений, зародившийся в 1980-х и расцветший к 1991 году.
Стандарт CORBA был реализован несколькими вендорами. Он обеспечивает:
Сегодня CORBA всё ещё используется для разнородных вычислений. Например, он до сих пор является частью Java EE, хотя начиная с Java 9 будет поставляться в виде отдельного модуля.
Хочу отметить, что не считаю CORBA паттерном SOA (хотя отношу и CORBA, и SOA-паттерны к сфере распределённых вычислений). Я рассказываю о нём здесь, поскольку считаю недостатки CORBA одной из причин возникновения SOA.
Принцип работы
Сначала нам нужно получить брокер объектных запросов (Object Request Broker, ORB), который соответствует спецификации CORBA. Он предоставляется вендором и использует языковые преобразователи (language mappers) для генерирования «заглушек» (stub) и «скелетов» (skeleton) на языках клиентского кода. С помощью этого ORB и определений интерфейсов, использующих IDL (аналог WSDL), можно на основе реальных классов генерировать в клиенте удалённо вызываемые классы-заглушки (stub classes). А на сервере можно генерировать классы-скелеты (skeleton classes), обрабатывающие входящие запросы и вызывающие реальные целевые объекты.
Вызывающая программа (caller) вызывает локальную процедуру, реализованную заглушкой.
Достоинства
Недостатки
Веб-сервисы
Хотя сегодня можно найти применение для CORBA, но мы знаем, что нужно было уменьшить количество удалённых обращений, чтобы повысить производительность системы. Также требовался надёжный канал связи и более простая спецификация обмена сообщениями.
И для решения этих задач в конце 1990-х начали появляться веб-сервисы.
[Веб-]сервисы можно публиковать, находить и использовать стандартным образом вне зависимости от технологий.
— Microsoft 2004, Understanding Service-Oriented Architecture
Благодаря микросервисам мы перешли в парадигме SOA от удалённого вызова методов объекта (CORBA) к передаче сообщений между сервисами.
Но нужно понимать, что в рамках SOA веб-сервисы — не просто API общего назначения, всего лишь предоставляющие CRUD-доступ к базе данных через HTTP. В каких-то случаях эта реализация может быть полезной, но ради целостности ваших данных необходимо, чтобы пользователи понимали лежащую в основе реализации модель и соблюдали бизнес-правила. SOA подразумевает, что веб-сервисы являются ограниченными контекстами бизнес-субдоменов (business sub-domain) и отделяет реализацию от решаемых веб-сервисами задач.
С точки зрения технологий SOA не просто сервисная архитектура, а набор политик, методик и фреймворков, благодаря которым мы предоставляем и получаем нужные сервисы.
— Microsoft 2004, Understanding Service-Oriented Architecture
Достоинства
Недостатки
Очередь сообщений
У нас есть несколько приложений, которые асинхронно общаются друг с другом с помощью платформо-независимых сообщений. Очередь сообщений улучшает масштабируемость и усиливает изолированность приложений. Им не нужно знать, где находятся другие приложения, сколько их и даже что они собой представляют. Однако все эти приложения должны использовать один язык обмена сообщениями, т. е. заранее определённый текстовый формат представления данных.
Очередь сообщений использует в качестве компонента инфраструктуры программный брокер сообщений (RabbitMQ, Beanstalkd, Kafka и т. д.). Для реализации связи между приложениями можно по-разному настроить очередь:
Запрос/Ответ
Все эти паттерны можно отнести к либо к pull- (polling), либо к push-подходу:
Достоинства
Недостатки
Сервисная шина предприятия (ESB)
Сервисная шина предприятия использовала веб-сервисы уже в 1990-х, когда они только развивались (быть может, некоторые реализации сначала использовали CORBA?).
ESB возникла во времена, когда в компаниях были отдельные приложения. Например, одно для работы с финансами, другое для учёта персонала, третье для управления складом, и т. д., и их нужно было как-то связывать друг с другом, как-то интегрировать. Но все эти приложения создавались без учёта интеграции, не было стандартного языка для взаимодействия приложений (как и сегодня). Поэтому разработчики приложений предусматривали конечные точки для отправки и приёма данных в определённом формате. Компании-клиенты потом интегрировали приложения, налаживая между ними каналы связи и преобразуя сообщения с одного языка приложения в другой.
Очередь сообщений может упростить взаимодействие приложений, но она не способна решить проблему разных форматов языков. Впрочем, была сделана попытка превратить очередь сообщений из простого канала связи в посредника, доставляющего сообщения и преобразующего их в нужные форматы/языки. ESB стал следующей ступенью в естественной эволюции простой очереди сообщений.
В этой архитектуре используется модульное приложение (composite application), обычно ориентированное на пользователей, которое общается с веб-сервисами для выполнения каких-то операций. В свою очередь, эти веб-сервисы тоже могут общаться с другими веб-сервисами, впоследствии возвращая приложению какие-то данные. Но ни приложение, ни бэкенд-сервисы ничего друг о друге не знают, включая расположение и протоколы связи. Они знают лишь, с каким сервисом хотят связаться и где находится сервисная шина.
Клиент (сервис или модульное приложение) отправляет запрос на сервисную шину, которая преобразует сообщение в формат, поддерживаемый в точке назначения, и перенаправляет туда запрос. Всё взаимодействие идёт через сервисную шину, так что если она падает, то с ней падают и все остальные системы. То есть ESB — ключевой посредник, очень сложный компонент системы.
Это очень упрощённое описание архитектуры ESB. Более того, хотя ESB является главным компонентом архитектуры, в системе могут использоваться и другие компоненты вроде доменных брокеров (Domain Broker), сервисов данных (Data Service), сервисов процессной оркестровки (Process Orchestration Service) и обработчиков правил (Rules Engine). Тот же паттерн может использовать интегрированная архитектура (federated design): система разделена на бизнес-домены со своими ESB, и все ESB соединены друг с другом. У такой схемы выше производительность и нет единой точки отказа: если какая-то ESB упадёт, то пострадает лишь её бизнес-домен.
Главные обязанности ESB:
Создавая структуры связи между разными процессами, мы видели много продуктов и подходов, в которых применяются очень развитые механизмы связи. Хороший пример — сервисные шины предприятий, часто включающие в себя сложные средства маршрутизации сообщений, хореографии, преобразования и применения бизнес-правил.
— Martin Fowler 2014, Microservices
У этого архитектурного паттерна есть положительные стороны. Однако я считаю его особенно полезным в случаях, когда мы не «владеем» веб-сервисами и нам нужен посредник для трансляции сообщений между сервисами, для оркестрирования бизнес-процессами, использующими несколько веб-сервисов, и прочих задач.
Также рекомендую не забывать, что реализации ESB уже достаточно развиты и в большинстве случаев позволяют использовать для своего конфигурирования пользовательский интерфейс с поддержкой drag & drop.
Достоинства
Недостатки
Микросервисы
В основе микросервисной архитектуры лежат концепции SOA. Назначение у неё то же, что и у ESB: создать единое общее корпоративное приложение из нескольких специализированных приложений бизнес-доменов.
Главное различие микросервисов и шины в том, что ESB была создана в контексте интеграции отдельных приложений, чтобы получилось единое корпоративное распределённое приложение. А микросервисная архитектура создавалась в контексте быстро и постоянно меняющихся бизнесов, которые (в основном) с нуля создают собственные облачные приложения.
То есть в случае с ESB у нас уже были приложения, которые нам не «принадлежат», и поэтому мы не могли их изменить. А в случае с микросервисами мы полностью контролируем приложения (при этом в системе могут использоваться и сторонние веб-сервисы).
Характер построения/проектирования микросервисов не требует глубокой интеграции. Микросервисы должны соответствовать бизнес-концепции, ограниченному контексту. Они должны сохранять своё состояние, быть независимыми от других микросервисов, и потому они меньше нуждаются в интеграции. То есть низкая взаимозависимость и высокая связность привели к замечательному побочному эффекту — уменьшению потребности в интеграции.
[Микросервисы — это] маленькие автономные сервисы, работающие вместе и спроектированные вокруг бизнес-домена.
— Sam Newman 2015, Principles Of Microservices
Главным недостатком архитектуры ESB было очень сложное централизованное приложение, от которого зависели все остальные приложения. А в микросервисной архитектуре это приложение почти целиком убрано.
Ещё остались элементы, пронизывающие всю экосистему микросервисов. Но у них гораздо меньше задач по сравнению с ESB. К примеру, для асинхронной связи между микросервисами до сих пор применяется очередь сообщений, но это лишь канал для передачи сообщений, не более того. Или можно вспомнить шлюз экосистемы микросервисов, через который проходит весь внешний обмен данными.
Сэм Ньюман, автор Building Microservices, выделяет восемь принципов микросервисной архитектуры. Это:
Сообщество предпочитает другой подход: умные конечные точки и глупые каналы. Микросервисы, из которых собираются приложения, должны как можно меньше зависеть друг от друга и при этом быть очень тесно связанными — они содержат собственную доменную логику и работают скорее как фильтры с точки зрения классического Unix: получают запросы, применяют логику и генерируют ответы. Они оркестрируются с помощью простых REST-подобных протоколов, а не сложных протоколов вроде WS-Choreography или BPEL либо какого-то централизованного инструмента.
— Martin Fowler 2014, Microservices
Достоинства
Недостатки
Антипаттерн: архитектура равиоли (Ravioli Architecture)
Архитектурой равиоли обычно называют антипаттерн микросервисной архитектуры. Равиоли получаются, если микросервисов слишком много, они слишком мелкие и не отражают доменных концепций.
Заключение
В последние десятилетия SOA сильно эволюционировала. Благодаря неэффективности прежних решений и развитию технологий сегодня мы пришли к микросервисной архитектуре.
Эволюция шла по классическому пути: сложные проблемы разбивались на более мелкие, простые в решении.
Проблему сложности кода можно решать так же, как мы разбиваем монолитное приложение на отдельные доменные компоненты (разграниченные контексты). Но с разрастанием команд и кодовой базы увеличивается потребность в независимом развитии, масштабировании и развёртывании. SOA помогает добиться такой независимости, упрочняя границы контекстов.
Повторюсь, что всё дело в слабой взаимозависимости и высокой связности, причём размер компонентов должен быть больше прежнего. Необходимо прагматично оценить свои потребности: используйте SOA, лишь когда это необходимо, поскольку она сильно увеличивает сложность. И если на самом деле вы можете обойтись без SOA, то лучше выберите микросервисы подходящего размера и количества, не больше и не меньше.
Финансовая сфера
Зачем SOA в кризис?
Сервисноориентированная архитектура — это новый и до кризиса весьма модный подход к построению IT-инфраструктуры банка. Сейчас многое изменилось, но, по мнению экспертов, через два года примерно половина российских банков внедрит у себя принципы SOA.
Текст: Александр Головин,
Представим, что банк собирается вывести на рынок новый продукт. При этом выясняется, что имеющиеся автоматизированные банковские системы (АБС) для этого не подходят. Типичная реакция IT-департамента в этом случае будет примерно такой: нужно запланировать шесть месяцев на разработку технического задания и столько же на разработку решения, так что к выводу нового продукта мы будем готовы через год.
Банк «Ренессанс Кредит» в 2008 году смог создать новую АБС для выдачи кредитов через брокера всего за два месяца. Такой оперативности удалось достичь благодаря ранее внедренной так называемой сервисноориентированной архитектуре, или SOA. По словам Ярослава Медокса, директора департамента по развитию информационных систем «Ренессанс Кредита», SOA — это подход, ориентированный на быстрый результат.
Торопиться не надо
Согласно результатам опроса «Значение сервисноориентированной архитектуры для бизнеса», проведенного в 2006 году IBM среди своих заказчиков, 92% из тех, кто приступил к внедрению SOA, надеялись добиться снижения расходов. Половине из них это удалось. Что ж, оптимизация издержек очень актуальная задача в условиях кризиса.
В основе SOA лежат принципы многократного использования функциональных элементов IT и ликвидации дублирования, а также модульный подход к разработке программного обеспечения, основанный на использовании сервисов со стандартизированными интерфейсами. Последнее как раз и обеспечивает возможность не разрабатывать новое приложение с нуля, а быстро собрать его из имеющихся модулей. В вышеприведенном примере с «Ренессанс Кредитом» в процессах продаж кредитов в банке использовались 11 систем. При организации нового процесса все они остались неизменными.
Таким образом, использование SOA позволяет быстро и без лишних расходов адаптировать IT под новые запросы бизнеса. Кстати говоря, до кризиса в российском банковском секторе SOA-проекты были, что называется, «модной фишкой». Может быть, с учетом изложенного, тем, кто не успел заняться внедрением ранее, именно сейчас и стоит поторопиться? Однако Игорь Коваль, исполнительный директор БТА Банка, убежден, что если банк не приступал к реализации данного проекта, то следует дождаться лучших времен и пока обойтись традиционной интеграцией приложений.
Перестройка в головах
Эксперты могут давать различные определения SOA, но суть их сводится к одному: сервисноориентированная архитектура — это идеология или, по выражению Игоря Коваля из БТА Банка, «культура использования технологий», с помощью которой компания создает единое информационное пространство и приобретает качественно новый контроль над бизнес-процессами и управлением. То есть внедрение SOA эквивалентно коренной реорганизации бизнеса. Наверное, кризис — не лучшее время для этого, хотя, возможно, есть исключения.
Разумеется, при построении новой компании имеет смысл сразу использовать сервисноориентированный подход; впрочем, о масштабных startup’ах, особенно в банковской сфере, пока не слышно.
До кризиса в российском банковском секторе SOA-проекты были, что называется, «модной фишкой».
Правда, специалисты IT-депар-таментов банков полагают, что приступить к внедрению SOA в текущей ситуации может заставить срочная необходимость в смене всей
*Мэшап (mashup) — web-приложение, объединяющее данные из нескольких источников в один интегрированный инструмент. Примером потребительского приложения может служить мэшап, который использует данные картографических сервисов для добавления к ним данных о недвижимости с соответствующих порталов.
IT-инфраструктуры организации — тогда, в силу вышеописанных плюсов, также предпочтительно сразу использовать данные принципы, но и это больше из области гипотез. В целом же, как говорит Олег Подкопаев, директор IT-департамента Русфинанс Банка, если в организации существует стабильная ситуация с точки зрения IT и бизнеса в целом и если даже с использованием устаревших технологий взаимодействие между системами вполне прозрачно и достаточно эффективно, затевать переход на SOA-платформу было бы неоправданным расходованием средств и ресурсов. Также это касается и тех случаев, когда основные бизнес-процессы реализованы в одной банковской системе и это не накладывает существенных ограничений на дальнейшее развитие.
Впрочем, по словам Олега Подкопаева («Русфинанс»), еще до кризиса был важен, скажем так, внешний фактор, который сдерживал распространение SOA в банках. Это — недостаток опыта реализации подобных проектов у интеграторов и консалтинговых компаний. Компаний, которые вообще имеют такой опыт, на рынке буквально единицы.
Любопытно, что эксперты, с одной стороны, говорят об отсутствии или нехватке квалифицированных интеграторов, а с другой — обращают внимание на то, что внедренная SOA снижает зависимость банков от поставщиков. Гибкость, которую обеспечивает сервисноориентированный подход, позволяет распределять задачи между разными подрядчиками, каждый из которых будет заниматься тем, в чем обладает наибольшей квалификацией. При этом всегда есть возможность поменять одну из систем, не ставя под угрозу жизнедеятельность всей IT-структуры банка. Да и доверяться целиком и полностью одной компании, как это происходит в обычных проектах по интеграции, тоже нет необходимости. Это, безусловно, снижает риски заказчика.
Кому с SOA жить хорошо?
На вопрос, сколько российских банков на данный момент используют SOA-поход, четкого ответа нет. Так, Игорь Коваль отмечает, что в БТА Банке SOA применяется уже в течение нескольких лет и включает в себя систему управления бизнес-процессами (BPM), единую шину обмена данными (ESB) и обмена сообщениями (MQ). Основной причиной внедрения SOA явилось наличие десятков программных приложений, требующих обмена информацией, а также необходимость создания системы продаж розничных продуктов банка. Что же касается SOA в других банках, то, по его словам, «все технологически заинтересованные» кредитные учреждения в той или иной степени ее применяют.
Олег Подкопаев из Русфинанс Банка называет более точные цифры. По его оценкам, 10–15% банков уже используют SOA, еще 30–40%, что называется, присматриваются и, вероятно, начнут внедрение системно ориентированной архитектуры в течение ближайшей пары лет. В самом «Русфинансе» данный подход внедрен, и за счет этого в 2008 году удалось в короткие сроки реализовать два крупных проекта по интеграции бэк-офисных систем от зарубежных поставщиков.
Вообще, если отрешиться от общеэкономической обстановки, можно выделить тип кредитных учреждений, которые больше других нуждаются в SOA. Это в первую очередь розничные банки. Именно для них важны время внедрения нового продукта, скорость обслуживания клиентов, доступность информации, качество сервиса, а также гибкость, благодаря которой сервисы, образующие один бизнес-процесс, можно запускать в разное время (ведь, например, потребность в проведении транзакции по пластиковой карте может возникнуть только через три недели после ее оформления, принимая во внимание время на производство, доставку и активацию). Все эти преимущества, которые обеспечивает SOA, не слишком актуальны, например, для кэптивных банков. Да и не все универсальные банки оценят их в полной мере.
В пользу SOA есть еще одно соображение, которым, правда, делятся не слишком охотно. Считается, что возможность декларировать соответствие информационных систем банка данным принципам повышает его привлекательность в глазах инвесторов, особенно западных. Впрочем, насколько это актуально в нынешних условиях — большой вопрос.
Олег Подкопаев, директор IT-департамента Русфинанс Банка:
— На данный момент SOA является довольно новым веянием на российском рынке. В основном внимание данной технологии и методологии уделяют компании, активно развивающиеся или выходящие на новый рынок, требующие быстрого изменения бизнес-процессов и, соответственно, информационных систем. Это примерно 10–15% от общего количества. Другие пока присматриваются, ждут реального результата от внедрения SOA-проектов и при положительном варианте развития событий будут готовы в течение ближайших одного-двух лет приступить к внедрению. Таких, я полагаю, 30–40% от общего количества. Остальные же — как правило, крупные компании, достаточно долго присутствующие на рынке, — пока не заинтересованы кардинально менять свой IT-ландшафт (а внедрение SOA — это именно кардинальное, революционное изменение), поскольку при их масштабах и разнообразии систем это потребует действительно крупных инвестиций.
Три источника, три составные части
В начале статьи было приведено категоричное мнение одного из экспертов, что пока с внедрением SOA лучше подождать. Но не все специалисты согласны с этим. Например, Олег Подкопаев из Русфинанс Банка считает, что вообще не следует ставить вопрос с внедрением в зависимость от кризиса. Дескать, мнение, что из-за неблагоприятной экономической обстановки надо менять подход к реализации тех или иных IT-проектов, применять другие технологии, в принципе неверное. Кризис определяет бизнес-задачи, а вот как их решать — с помощью SOA или без — это уже следующий вопрос. Если в условиях кризиса или в любых других условиях есть задачи, которые можно наиболее эффективно решать с использованием SOA — значит так и надо делать.
В любом случае следует понимать, что идеологическая модель SOA имеет три уровня. На высшем уровне находится управление бизнес-процессами. Второй уровень определяет требования к сервисам. Последние представляются в виде понятных бизнесу услуг, которые можно измерить, тарифицировать и т.д. На этом уровне важно выявить повторяющиеся и типовые задачи. Наконец, третий, низший уровень — это собственно техническая сторона вопроса: выбор интеграционной платформы, мэшапов, протоколов и т.д. Как уточняет Олег Подкопаев («Русфинанс»), для того чтобы правильно управлять уровнем бизнес-сервисов, IT-подразделением банка должны быть поставлены необходимые сервисы приложений, далее инфраструктурные сервисы и т.п. Причем KPI каждого сотрудника подразделения привязываются к уровню сервисов, за которые он отвечает. Для достижения максимального результата сервисноориентированный подход должен присутствовать во всех срезах IT-деятельности банка.
Алексей Макеев, директор направления SOA, компания «Неофлекс»
Сегодня один из приоритетов банков — сокращение затрат. Сделать это можно за счет оптимизации самых «дорогих» и трудоемких, на наш взгляд, бизнес-процессов — процессов, обеспечивающих работу с клиентами. На каждом этапе деятельности банка (пресейл, продажи, обслуживание) в выполнении «клиентских» бизнес-процессов участвуют сотрудники разных отделов и несколько информационных систем. То есть речь идет о сквозном, кросс-системном характере бизнес-процессов.
Идеология SOA и ее составная часть — BPM-решение — позволяют описать, автоматизировать сквозные бизнес-процессы и управлять ими. Каждый бизнес-процесс становится прозрачным и понятным. BPM-решение дает уникальную возможность оценить бизнес-процесс в количественных показателях и определить его себестоимость. Есть цифры — есть возможность для оптимизации и экономии. Приведу примеры уменьшения затрат за счет оптимизации бизнес-процессов.
Интеграция информационных систем в архитектуре SOA дает возможность отказаться от ручного труда сотрудников там, где требуется переносить данные из одной системы в другую. Это позволяет сократить персонал.
Для одного банка мы создали фронт-офисное приложение для автоматизации бизнес-процессов call-центра. Теперь операторы центра получают информацию из нескольких банковских систем через единый интерфейс. В результате исчезла необходимость тратить средства на обучение сотрудников работе с несколькими сложными системами и закупку лицензий для доступа к ним.
Еще один наш проект позволил банку отказаться от бумажной технологи выдачи пин-кодов. Сейчас клиент набирает телефонный номер банка и в автоматическом режиме получает пин-код. По оценке банка, экономия оказалась весьма ощутимой.
Все приведенные проекты позволяют не только сократить затраты, но и повысить качество работы с клиентами. А это означает укрепление репутации банка и в перспективе — увеличение объемов продаж.
«Банковское обозрение», №2, февраль 2009 г.