Так сложилось, что моя карьера — сначала разработчика, затем архитектора, технического директора и наконец предпринимателя, развивалась преимущественно в околофинансовом секторе. Большую часть своего трудового пути я писал софт или работал в банках, брокерах и схожих с ними компаниях. Своим опытом столкновений с типичными проблемами этого сектора я и хотел бы поделиться с уважаемыми хабравчанами.
В общественном сознании образ банкира, трейдера или брокера, сформирован очень завидно. Человек — хозяин жизни в дорогом костюме, рассекающий на блестящей мощной машине, непоколебимо уверенный в себе и обладающий некими мистическими экономическими знаниями. Точно знающий, что и как нужно сделать, чтобы деньги, которых у него и так куры не клюют, превратились в еще больше денег.
При помощи своих трейдерских терминалов, BI систем, систем риск-менеджмента и прочего пугающе хитроумного программного обеспечения, этот ослепительный финансист может делать фантастические вещи – например, предсказывать будущее рынков, зарабатывая на движениях которовок и курсов. Либо с пугающей точностью рассчитывать свои риски при, гарантированно оставаясь в плюсе, или творить другую хитроумную финансовую магию.
Само собой разумеется, в воображении большинства этот преуспевающий финансовый воротила совершенно точно знает, сколько денег у него есть на сегодняшний день. А так же кому, что и сколько должны ему и должен он. В любой момент его надежный, не знающий сбоев софт (ведь это системы где деньги почти в каждой переменной!) предоставит ему эту информацию во всех деталях и разрезах. По первому запросу выдаст все необходимые цифры и нарисует красивые графики в реальном времени.
Те из вас, кто работал в околофинансовых компаниях и имел дело с кодом ядра (Core Banking, OLTP или их аналог) – уже наверняка недобро ухмыляются, вспоминая что-то свое. Потому что реальность бесконечно далека от картинки, возникающей в воображении обывателя, когда он слышит словосочетание «финансовая компания».
Горькая правда заключается в том, что компании, управляемые этими акулами бизнеса в дорогих костюмах, в большинстве случаев лишь очень приблизительно могут узнать, сколько у них денег в данный момент и что с этими деньгами (а следовательно, и с компанией) происходит. За фасадом из лоска, солидности и профессионального выражения лиц зачастую скрывается путаница в отчетах, ошибки на счетах клиентов, сбои в системах и нервные ругательства разработчиков, пытающихся заставить работать код всего этого хозяйства работать. Чтобы понять, отчего так происходит, рассмотрим упрощенный бизнес-процесс и его реализацию в большинстве финансовых учреждений.
Типичная процесс типичной финансовой компании выглядит примерно следующим образом: Клиенты взаимодействуют с системой, меняя значения балансов на счету (внося и изымая средства, используя продукты, меняющие состояние счета). Эти операции выполняет система, научно называемая OLTP — Online Transaction Processing, призванная производить некие операции со счетами на лету.
В подавляющем большинстве достаточно сложных систем, OLTP не может ни предоставить данные для системы репортинга, ни даже дать ответа на вопрос “сколько денег на данный момент в системе и как они распределены” до тех пор, пока не будет произведен EOD. EOD — End Of Day, набор процедур, которые служат для закрытия бухгалтерского дня и получения по нему финансовых результатов, а так же для расчета результатов работы финансовых продуктов. Например, в большинстве банков именно в течение EOD рассчитываются интрессы по вкладам клиентов. EOD выполняется в сисеме как правило в нерабочие часы — ночью. Всвязи с чем многие интернет-банки взависимости от технической продвинутости частично или полностью недоступны в ночное время.
Таким образом, при стандартном подходе к проектированию системы, прибыль за день возможно оценить только после проведения EOD. Кроме того, для получения результатов за минувший день, часто привлекаются живые люди, для внесения поправок, ввода коэффицентов — словом, для всего того что еще не автоматизировано или носит характер “временных нюансов". Например, если необходимо учитывать не только результаты работы кода внутри своей системы, но еще и состояние счетов фирмы у контрагентов, которые не подключены к системе через API.
Итогом всего этого процесса — бухгалтеры тратят уйму времени чтобы свести несходящийся баланс, прибыль международной финансовой компании с учетом всех поправок зачастую считается в экселе, а отчеты показывают цифры, носящие скорее индикативный характер. Цифры полученные у себя в системе, как правило, сходятся с цифрами у контрагентов лишь с определенной погрешностью — эту ситуацию принято считать нормальной. Плохо, когда они не сходятся вовсе, что тоже случается. Тут мы переходим к главному, а именно — к рассмотрению одной из причин, почему так происходит.
Представим что у нас есть достаточно опытный и профессиональный программист (или команда), которому дали задание реализовать некий финансовый продукт. Например, срочный вклад — т.е. код должен обеспечивать начисление процента по вкладу, соответствующего условиям заключенного между клиентом и банком договором, которые программист получает в виде технического задания. Разработчик (аналитик) составляет на основании текста задания модель (в лучшем случае) и приступает к ее реализации в коде. Код, сильно упрощая, в конечном итоге сводится к замене некой величины в базе данных новой, вычисленной величиной. Нечто вроде
UPDATE accounts SET account_value = v_new_account_value WHERE customer_id = v_customer_id;
Значение поля account_value заменено на новое, соответсвующее вычисленным значениям. А значит клиент увидит в своем интернет-банке верное состояние своего счета. И эта, вполне логичная и работающая реализация, открывает приоткрывает дверь в ад.
Рассмотрим эту строчку более пристально с точки зрения концепции и философии всей системы. Мы положили на счет клеинта деньги, которые взялись как бы ниоткуда — из формулы и модели. Что как мы понимаем, не является адекватным отображением того, что происходит в реальности — в Ньютоновском пространстве предметы не возникают ниоткуда и не исчезают никуда. Они лишь перемещаются и меняют свою форму и состояние.
Как показывает практика, постепенно, с ростом функционала, сложности и объема кода в системе, разрозненные операции с появлением денег неоткуда и исчезанием их в никуда НЕМИНУЕМО приведет к ошибкам, искажениям и как следствие — к катастрофическим финансовым и репутационным потерям компании.
Избежать ситуации можно в том случае, если осмыслить процесс реализации функционала не как изменения состояния счетов, но как транзакции — т.е. перемещение средств или активов между счетами внутри системы. При этом в качественной реализации такой архитектуры сама возможность изменения значения без произведения двусторонней транзакции должна быть исключена — ядро предоставляет api, на основе которого реализуется высокоуровневая логика функционала продукта. При этом полностью берет на себя все, что связано непосредственно с изменениями значений.
Помимо резко повышающейся надежности, такой принцип очень близок к стандартному бухгалтерскому принципу двойной записи. А это означает что мы можем создать на базе такой концепции полноценный General Ledger, с нативной реализацией баланса. Что облегчает и работу с рапортами, и интеграцию разнообразных бухгалтерских систем в получившееся ядро. Дополнительно мы получаем гораздо более стройную систему с четким абстрагированием архитектурных уровней.
Вдоволь насмотревшись на то, как компании бегают кругами по граблям, мы с коллегами решили создать свою фирму и занялись разработкой подобного ядра, а так же проектов на его основе. Описанный принцип является только одним из множества других, положенных в основу нашего продукта. Если статья вызовет интерес и позитивную дискуссию — продолжу рассказ о других типичных ужасах и бедах финансового сектора, а так же предлагаемых путях их разруливания.
Автор: MartinKiuru
