Diasoft Flextera vs CFT MCA - битва началась (часть 1)

Немного истории (для начала)

Думаю ни для кого не секрет, что Diasoft и CFT являются практически единственными игроками на российском рынке АБС. Иностранные производители пока не могут конкурировать с ними. Почему? Казалось бы и системы у них намного лучше как в функциональном так и в технологическом плане. Посмотрите на тот же Диасофт наиболее популярной сейчас версии 3.6.8, установленной в большинстве клиентов этой компании - это же, говоря откровенно, прошлый век в архитектуре ПО. 2-х слойное приложение: толстый клиент, разработанный на Delphi, и база данных, в хранимых процедурах которой содержится вся логика приложения.

У CFT в этом плане получше конечно. То что сейчас называется ЦФТ-Платформа 1 это 3-х уровневое приложение, полностью построенное на технологическом стеке Oracle. Оракловая база, оракловый сервер приложений, клиент. Есть да же веб-клиент, работающий через Tomcat. Но проблема оставалась та же - слой бизнес-логики так же лежит в СУБД.

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

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

Тут есть интересная особенность которая всех сильно запутывает и видно когда люди начинают говорить друг с другом про разные вещи. Если выделить два разных понятия: слой - логическое деление, и уровень - физическое деление, то 3-х слойное приложение вполне себе может быть 2-х уровневым :)

Ведь в 3-х слойном приложении мы выделяем 3 слоя: клиент с отображением данных, бизнес логика и слой хранения данных. При достаточно четком и красиво реализованном логическим делением, мы можем физически разместить 2 последних слоя на одном уровне - уровне БД и получится уже 2-х уровненное приложение :) НО! размещая логику приложения в хранимых процедурах БД мы получает проклятие всех архитекторов - ЖЕСКОЕ СВЯЗЫВАНИЕ. Хранимые процедуры навсегда поселяются на данных, на структуре БД и разделить их в будущем становиться практически невозможно.

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

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

1) банки уже накопили достаточно большой объем информации в своих учетных системах т.к. уже достаточно долгое время (15-20 лет) находятся на рынке

2) объем бизнеса вырос, количество клиентов, операций, пользователей сильно выросло а время существованию компаний

3) появилась географическая распределенность, выросло количество филиалов, точек клиентского обслуживания и т.д.

4) очень высокая нагрузка на приложения

5) необходимость интеграции с множеством сторонних приложений в инфраструктуре предприятия - инфраструктуры разрослись, обросли дополнительным специфичным ПО заточенным под какие-то отдельные функциональности

И если смотреть вопрос именно с точки зрению такой окружающей среды, сразу натыкаемся на следующие минусы архитектуры:

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

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

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

С интеграцией то же проблемы - архитектура обязывает нас хранить все данные необходимые для работы в БД. А ведь современное предприятие давно уже оперирует такими понятиями как SSoT, когда какие-то референсные справочники лежат в отдельных, специализированным системах. Получается приходиться плодить дополнительные синхронизации между системами, поддерживать эти механизмы, следить на консистентностью данных и т.д.

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

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

Почему же эти системы такие какие-они есть? Просто потому что сделаны достаточно давно, когда коньюктура рынка, клиентов и заказчиков была иной нежеле сейчас. А сейчас компании-клиенты уже явно “переросли” те архитектурные возможности, которые предоставляют обе вышеупомянутые платформы. Они выросли, а платформы нет.

Поэтому правильнее задавать вопрос - почему же эти платформы до сих пор такие какие они есть? Но ответ на него лежит не в области технологии, а в области бизнеса. Менять их коренным образом было не выгодно экономически, нужно было накопить критическую массу клиентов которым бы были нужны и просто необходимы другие архитектурные подходы.

У иностранных банков давно все по другому. Их истории насчитывают по 50-100 лет развития, они намного больше и системы которые им предлагают западные поставщики технически находятся на совсем другом уровне. Взять тот же Temenos - уже много лет как построена на классической 3-х уровневой архитектуре, с веб-сервисами, с жестким разделением клиентов (которых огромное количество и они уже превратились там именно в “каналы доступа” к системе) логики и данных. Все взаимодействие построено на базе web-сервисов, что предоставляет прекрасные возможности для интеграции.

Но в России внедрений западных систем катастрофически мало, даже несмотря на все их плюсы. Потому что не доросли :) Хотя наши банки и достаточно большие, все таки к внедрению зарубежных систем они еще по видимому не готовы. Много унаследованных подходов этому мешают, от которых надо будет отказываться. Например все таки банки привыкли что АБС это и GL для компании - это просто, удобно при одном юр лице с филиалами и одинаковым учетом. Ну и конечно наши регуляторные требования - не секрет что без полной поддержки со стороны производителя всех требований нашего ЦБ внедрять систему рискованно. А поддержка всех требований ЦБ это для иностранного производителя во первых переделка существующего функционала и адаптация его к российским условиям а во вторых наличие выделенной команды которая будет постоянно отслеживать изменения законодательства и готовить обновления. И при высокой стоимости систем и всех описанных особенностях пока банки не готовы их внедрять, а производители пока не готовы рискнуть и выйти на российский рынок с полноценными предложениями.

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

А то что они сейчас нам предлагают попробую описать в следующем посте.