Так сложилось, что моя карьера — сначала разработчика, затем архитектора, технического директора и наконец предпринимателя, развивалась преимущественно в околофинансовом секторе. Большая часть моей профессиональной деятельности прошла в проектировании и написании софта для банков, компаний-брокеров и схожих с ними компаниях. Об одной из наиболее типичных технических проблем финансового сектора я и хотел бы рассказать уважаемым хабравчанам.
В общественном сознании образ банкира, трейдера или брокера сформирован очень завидно. Это человек — хозяин жизни в дорогом костюме, рассекающий на блестящей мощной машине, непоколебимо уверенный в себе и обладающий некими мистическими экономическими знаниями. Точно знающий, что и как нужно сделать, чтобы деньги которых у него и так куры не клюют, превратились в еще большую кучу денег.
При помощи своих трейдерских терминалов, BI систем, систем риск-менеджмента и прочего пугающе хитроумного программного обеспечения, это воплощение архетипа бизнесмена может делать фантастические вещи – например, предсказывать будущее рынков, зарабатывая на движениях котировок и курсов. Возможно он может пугающей точностью рассчитывать свои риски, гарантированно оставаясь в плюсе, или творить другую, недоступную простым смертным, финансовую магию.
Само собой разумеется, большинство людей уверены что этот преуспевающий финансист совершенно точно знает, сколько денег у него есть на данный момент. А так же сколько должны ему, и кому и сколько должен он. В любой момент его надежный, не знающий сбоев софт (ведь это системы, где деньги сидят почти в каждой переменной!) предоставит ему эту информацию во всех деталях и разрезах. По первому запросу выдаст все необходимые цифры и нарисует красивые графики в реальном времени.
Те из вас, кто работал в финансовых и схожих с ними компаниях, и имел дело с кодом ядра (Core Banking, OLTP или их аналог который реализует финансовые продукты) – уже наверняка недобро ухмыляются, вспоминая что-то свое. Потому что реальность бесконечно далека от картинки, возникающей в воображении обывателя, когда он слышит словосочетание «финансовая компания».
Горькая правда заключается в том, что компании, управляемые этими акулами бизнеса в дорогих костюмах, в большинстве случаев лишь очень приблизительно могут узнать, сколько у них денег в данный момент и что с этими деньгами (а следовательно, и с компанией) происходит прямо сейчас.
За фасадом из лоска, солидности и профессионального выражения лиц зачастую скрывается путаница в отчетах, ошибки на счетах клиентов, сбои в системах, не сходящийся баланс в бухгалтерии и нервные ругательства разработчиков, пытающихся заставить код всего этого хозяйства работать. Чтобы понять, отчего так происходит, рассмотрим упрощенный бизнес-процесс и его реализацию в большинстве финансовых учреждений.
Типичный процесс в типичной финансовой компании протекает примерно следующим образом: Клиенты взаимодействуют с онлайн-системой, меняя значения баланса на ее счету (внося и изымая средства, а так же используя финансовые продукты, меняющие состояние счета). Эти операции выполняет система, научно называемая OLTP — Online Transaction Processing, призванная производить некие операции со счетами на лету, реализуя таким образом бизнес компании.
В подавляющем большинстве достаточно сложных и нагруженных систем, OLTP не может ни предоставить данные для системы репортинга, ни даже дать ответа на вопрос “сколько денег на данный момент в системе и как они распределены” до тех пор, пока не будет произведен EOD. EOD — End Of Day, набор процедур, которые служат для закрытия бухгалтерского дня и получения по нему финансовых результатов, а так же для расчета финансовых продуктов компании. Например, в большинстве банков именно в течение EOD рассчитываются интрессы по вкладам клиентов. EOD выполняется в системе, как правило, в нерабочие часы — ночью. В связи с этим многие интернет-банки в зависимости от технической продвинутости частично или полностью недоступны в ночное время.
Таким образом, при стандартном и повсеместно принятом подходе к проектированию финансовых систем, прибыль за день возможно оценить только после проведения EOD и всех его процедур. Кроме того, для получения результатов за закрытый день, часто привлекаются живые люди — для внесения поправок, ввода коэффициентов — словом, для всего того что еще не автоматизировано или носит характер “временных нюансов". Например, если необходимо учитывать не только результаты работы бизнес-логики внутри собственной системы, но еще и состояние счетов фирмы у контрагентов, которые не подключены к системе через API.
Итогом всего этого процесса — бухгалтеры тратят уйму времени чтобы свести не сходящийся баланс, прибыль международной финансовой компании с учетом всех поправок зачастую считается в экселе, отчеты генерируемые системой демонстрируют цифры, носящие скорее индикативный характер. Цифры полученные у себя в системе, как правило, сходятся с результатами у контрагентов лишь приблизительно, с некой погрешностью — эту ситуацию принято считать нормальной. Плохо, когда они не сходятся вовсе, что тоже случается — в таких случаях принято договариваться, а не уточнять методику подсчетов. Тут мы переходим к главному, а именно — к рассмотрению одной из причин, почему так происходит.
Представим что у нас есть достаточно опытный и профессиональный программист ( или команда разработчиков ), которому дали задание реализовать некий финансовый продукт. Например, срочный вклад — т.е. код должен обеспечивать начисление процента по вкладу, соответствующего условиям заключенного между клиентом и банком договором. Положения и условия договора программист получает в виде технического задания. Разработчик (либо аналитик) составляет на основании текста задания модель (в лучшем случае, возможно он просто выпишет текстом некие ценные указания для программиста) и приступает к ее реализации в коде. Код, сильно упрощая, в конечном итоге сводится к замене некой величины в базе данных на новую, вычисленную величину. Нечто вроде
Значение поля account_value заменено на новое, полученное в результате работы созданной бизнес-логики. А значит, клиент увидит в своем интернет-банке верное состояние своего счета. И эта, вполне логичная и работающая реализация, приоткрывает дверь в ад.
Рассмотрим эту строчку более пристально с точки зрения концепции и философии всей системы. Мы положили на счет клиента деньги, которые взялись как бы ниоткуда — из формулы и модели, из получившегося кода бизнес-логики. Что, как мы понимаем, не является адекватным отображением реального мира — в Ньютоновском пространстве предметы не возникают ниоткуда и не исчезают никуда. Они лишь перемещаются в пространстве, а так же меняют свою форму и состояние.
Как показывает практика, постепенно, с ростом сложности системы и ее функционала, объема кода и интеграциями с другими системами, разрозненные операции с появлением денег из ниоткуда и исчезанием их в никуда НЕМИНУЕМО приведет к ошибкам, сбоям в бизнес логике и как следствие — к катастрофическим финансовым и репутационным потерям компании.
Помимо этих опасностей, цифры меняемые самыми разными разнородными и разрозненными блоками бизнес-логики, требуют долгих процедур EOD хотя бы просто для того чтобы собрать полученные цифры в кучу и попытаться выдать на основании их хоть какой-то отчет. Именно поэтому бизнес ждет от IT отчетов за вчера чтобы понять что происходило с бизнесом компании хотя бы день назад.
Между тем, проблема путаницы в деньгах и непонимания состояния собственного бизнеса отнюдь не нова для человечества. С той же самой проблемой столкнулись венецианские купцы в период ренессанса. С ростом торговых оборотов и числа сделок старые принципы ведения дел “на пальцах” уже не годились. В итоге у торговцев возникла ровно та же проблема что и у современного финансового сектора (да, у этих ребят в дорогих костюмах), — путаница в цифрах и отсутствие четкого понимания, сколько денег и в каком виде у них есть на сегодняшний момент.
Проблема торговцев получила свое решение в далеком 1494 году, когда францисканский монах Luca Bartolomes Pacioli опубликовал свой трактат “Summa de Arithmetica, Geometria, Proportioni et Proportionalita”, а точнее — ее главу “De Computis et Scripturis” (О Подсчетах и Записи) которая давала четкие инструкции как вести дела в книгах, а так же “Как торговцу без промедления получать сведения о его активах и обязательствах”. С этого события ведет свою историю принцип двойной записи, повсеместно применяемый и являющий собой основу всей современной бухгалтерии.
Проблема IT финансового мира в том, что разработчики, и даже архитекторы в массе своей редко знают о францисканском монахе и об описанных им принципах. Как результат, мы получаем системы от которых зависит финансовый бизнес, но при этом страдающие от бед, успешно решенных в эпоху Ренессанса.
Возвращаясь из времен культурного расцвета в сегодняшний день, мы можем избежать такой печальной ситуации с IT в том случае, если осмыслим процесс реализации бизнес-логики не через изменения значений в выбранных полях базы данных, но как реализацию в бизнес-логике бухгалтерского подхода. В этом случае мы вводим в OLTP все присутствующие в двойной записи атрибуты, прежде всего — дебет и кредит. При таком подходе абсолютно все операции со счетами реализуются посредством бухгалтерских проводок или иначе говоря, финансовых транзакций. (Важно не путать рассматриваемые финансовые транзакции с термином “транзакция” в программировании. Финансовая транзакция — это перемещение средств или активов между счетами внутри системы).
Пользуясь принципом двойной записи непосредственно в бизнес-логике, мы резко повышаем надежность и адекватность работы нашей системы, т.к исключаем ситуацию, где деньги просто появляются и исчезают в результате UPDATE. Все операции со счетами мы выполняем проводками, т.е. перемещением средств в системе. А это означает что мы резко приблизили нашу модель к реальному миру. Помимо резко повышающейся надежности за счет постоянно гарантированно сходящегося баланса (что означает огромную экономию на ручном труде бухгалтеров), мы получаем в свое распоряжение всю мощь General Ledger и бухгалтерского подхода в работе с цифрами и отчетами.
Вследствие такого подхода к реализации ядра бизнес-продуктов, построение отчетов упрощается как с точки зрения разработки, так и с точки зрения нагрузки. Это открывает путь к реализации EOD-free системы, которая к тому же способна выдавать отчеты в реальном времени — а значит бизнес не будет больше в волнении ожидать результатов вчерашнего дня. Вместо этого он будет располагать информацией на данный момент, и соответственно — чувствовать себя гораздо увереннее, быть в состоянии действовать гораздо эффективнее чем ранее.
Архитектурное ядро, в котором жестко реализован принцип двойной записи, может быть использовано для реализации на его базе практически любых финансовых и околофинансовых продуктов — в системах Core Banking, OLTP, Wealth Management, Treasury, Accounting, Payment Processing, ERP системах и любых решениях, оперирующих некими активами. Имея подобное ядро в виде отдельного базового архитектурного слоя, на котором базируется остальной функционал, мы не только сильно повышаем безопасность всей системы, но еще и добиваемся серьезного снижения затрат с одновременным повышением качества в разработке новых продуктов и сервисов.
Вдоволь насмотревшись на то, как компании бегают кругами по старинным граблям, мы с коллегами решили создать свою фирму и занялись разработкой такого ядра, а так же проектов и систем на его основе в соответствии с особенностями бизнеса заказчика. Описанный принцип является только одним из множества других, положенных в основу нашего продукта. Если статья вызовет интерес и позитивную дискуссию — продолжу рассказ о других типичных ужасах и бедах финансового сектора, а так же предлагаемых путях их разруливания.
В общественном сознании образ банкира, трейдера или брокера сформирован очень завидно. Это человек — хозяин жизни в дорогом костюме, рассекающий на блестящей мощной машине, непоколебимо уверенный в себе и обладающий некими мистическими экономическими знаниями. Точно знающий, что и как нужно сделать, чтобы деньги которых у него и так куры не клюют, превратились в еще большую кучу денег.
При помощи своих трейдерских терминалов, 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 заменено на новое, полученное в результате работы созданной бизнес-логики. А значит, клиент увидит в своем интернет-банке верное состояние своего счета. И эта, вполне логичная и работающая реализация, приоткрывает дверь в ад.
Рассмотрим эту строчку более пристально с точки зрения концепции и философии всей системы. Мы положили на счет клиента деньги, которые взялись как бы ниоткуда — из формулы и модели, из получившегося кода бизнес-логики. Что, как мы понимаем, не является адекватным отображением реального мира — в Ньютоновском пространстве предметы не возникают ниоткуда и не исчезают никуда. Они лишь перемещаются в пространстве, а так же меняют свою форму и состояние.
Как показывает практика, постепенно, с ростом сложности системы и ее функционала, объема кода и интеграциями с другими системами, разрозненные операции с появлением денег из ниоткуда и исчезанием их в никуда НЕМИНУЕМО приведет к ошибкам, сбоям в бизнес логике и как следствие — к катастрофическим финансовым и репутационным потерям компании.
Помимо этих опасностей, цифры меняемые самыми разными разнородными и разрозненными блоками бизнес-логики, требуют долгих процедур EOD хотя бы просто для того чтобы собрать полученные цифры в кучу и попытаться выдать на основании их хоть какой-то отчет. Именно поэтому бизнес ждет от IT отчетов за вчера чтобы понять что происходило с бизнесом компании хотя бы день назад.
Между тем, проблема путаницы в деньгах и непонимания состояния собственного бизнеса отнюдь не нова для человечества. С той же самой проблемой столкнулись венецианские купцы в период ренессанса. С ростом торговых оборотов и числа сделок старые принципы ведения дел “на пальцах” уже не годились. В итоге у торговцев возникла ровно та же проблема что и у современного финансового сектора (да, у этих ребят в дорогих костюмах), — путаница в цифрах и отсутствие четкого понимания, сколько денег и в каком виде у них есть на сегодняшний момент.
Проблема торговцев получила свое решение в далеком 1494 году, когда францисканский монах Luca Bartolomes Pacioli опубликовал свой трактат “Summa de Arithmetica, Geometria, Proportioni et Proportionalita”, а точнее — ее главу “De Computis et Scripturis” (О Подсчетах и Записи) которая давала четкие инструкции как вести дела в книгах, а так же “Как торговцу без промедления получать сведения о его активах и обязательствах”. С этого события ведет свою историю принцип двойной записи, повсеместно применяемый и являющий собой основу всей современной бухгалтерии.
Проблема IT финансового мира в том, что разработчики, и даже архитекторы в массе своей редко знают о францисканском монахе и об описанных им принципах. Как результат, мы получаем системы от которых зависит финансовый бизнес, но при этом страдающие от бед, успешно решенных в эпоху Ренессанса.
Возвращаясь из времен культурного расцвета в сегодняшний день, мы можем избежать такой печальной ситуации с IT в том случае, если осмыслим процесс реализации бизнес-логики не через изменения значений в выбранных полях базы данных, но как реализацию в бизнес-логике бухгалтерского подхода. В этом случае мы вводим в OLTP все присутствующие в двойной записи атрибуты, прежде всего — дебет и кредит. При таком подходе абсолютно все операции со счетами реализуются посредством бухгалтерских проводок или иначе говоря, финансовых транзакций. (Важно не путать рассматриваемые финансовые транзакции с термином “транзакция” в программировании. Финансовая транзакция — это перемещение средств или активов между счетами внутри системы).
Пользуясь принципом двойной записи непосредственно в бизнес-логике, мы резко повышаем надежность и адекватность работы нашей системы, т.к исключаем ситуацию, где деньги просто появляются и исчезают в результате UPDATE. Все операции со счетами мы выполняем проводками, т.е. перемещением средств в системе. А это означает что мы резко приблизили нашу модель к реальному миру. Помимо резко повышающейся надежности за счет постоянно гарантированно сходящегося баланса (что означает огромную экономию на ручном труде бухгалтеров), мы получаем в свое распоряжение всю мощь General Ledger и бухгалтерского подхода в работе с цифрами и отчетами.
Вследствие такого подхода к реализации ядра бизнес-продуктов, построение отчетов упрощается как с точки зрения разработки, так и с точки зрения нагрузки. Это открывает путь к реализации EOD-free системы, которая к тому же способна выдавать отчеты в реальном времени — а значит бизнес не будет больше в волнении ожидать результатов вчерашнего дня. Вместо этого он будет располагать информацией на данный момент, и соответственно — чувствовать себя гораздо увереннее, быть в состоянии действовать гораздо эффективнее чем ранее.
Архитектурное ядро, в котором жестко реализован принцип двойной записи, может быть использовано для реализации на его базе практически любых финансовых и околофинансовых продуктов — в системах Core Banking, OLTP, Wealth Management, Treasury, Accounting, Payment Processing, ERP системах и любых решениях, оперирующих некими активами. Имея подобное ядро в виде отдельного базового архитектурного слоя, на котором базируется остальной функционал, мы не только сильно повышаем безопасность всей системы, но еще и добиваемся серьезного снижения затрат с одновременным повышением качества в разработке новых продуктов и сервисов.
Вдоволь насмотревшись на то, как компании бегают кругами по старинным граблям, мы с коллегами решили создать свою фирму и занялись разработкой такого ядра, а так же проектов и систем на его основе в соответствии с особенностями бизнеса заказчика. Описанный принцип является только одним из множества других, положенных в основу нашего продукта. Если статья вызовет интерес и позитивную дискуссию — продолжу рассказ о других типичных ужасах и бедах финансового сектора, а так же предлагаемых путях их разруливания.
