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

Пример различий построение обычных систем, которые ориентируются на текущую информацию, и финансовых систем.

Создается система финансового учета и аудита. Система, что называется, все в одном. Система разрабатывается, принимается заказчиком, развивается и дорабатывается. Через пару лет заказчик придумывает разделить весь бизнес процесс на две обособленные составляющие, а именно: финансовая служба делится на две части: финансовую и бухгалтерию. Под это дело планируется разделение систем: заказчик хочет чтобы старая система осталась, но некоторый функционал (связанный с бухгалтерской деятельностью) полностью проходил в 1С-Бухгалтерии. И тут сразу же встает вопрос интеграции двух систем. 1С-Бухгалтерия — замечательная финансовая система, вернее даже не 1С-Бухгалтерия, а весь фреймворк. Я даже не буду говорить про существенные проблемы 1С: часть встроенного функционала настолько “вшита” что изменить ее без последствий в будущем не получится; очень сложно интегрировать хоть один справочник из внешней базы. Скажу только что “на лету” подгружать в нее все изменения из основной системы — довольно нетривиальная задача. Но вернемся к нашей системе и зададимся вот каким вопросом: коль скоро у нас теперь не одна система, а целых две (три, четыре, пять,..) то что делать с сущностями, которые становятся общими для этих систем. Мы даже можем опустить те сущности создание, редактирование и удаление которых разрешено только в одной из систем (тут бизнес процесс можно расписать даже на уровне баз данных). А вот что делать, скажем, с общими для обеих систем справочниками? Ведь пользователи — это такие люди, которых хлебом не корми — дай только задвоить какую-нибудь информацию. Результаты этого могут быть если не катастрофическими, то отберут довольно много человеко-часов, которые потребуются на решение этих, казалось бы, маленьких проблем. А еще окажется что выяснилось это в конце декабря, когда начали собирать отчетность за год, а данные, скажем, по договорам расползаются. Пользователи же, отвечающие за эти данные, конечно же не помнят по какой причине несколько месяцев назад они сделали именно то что сделали. Логика product owner’а обычно сводится к тому что “это проблема системы, вы за нее отвечаете — вы и решайте проблему”, забывая что проблема может быть не столько в системе, сколько в данных. Всего бы этого не случилось при одном условии — архитектура системы и регламент взаимодействия были бы продуманы с самого начала.

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

В этот раз я хотел рассказать о проблеме, устранение которой на поздних этапах проектирования финансовой системы будет наиболее дорогостоящим и трудозатратным.

Рассмотрим пример.
Допустим имеется несколько таблиц в базе данных вашей системы. Одна из них — справочник юридических лиц. Вам как разработчику/аналитику необходимо спроектировать функционал для работы с некоторым типом документов. Для примера предположим что вам необходимо разработать функционал для создания и редактирования платежных поручений. Допустим 1 платежное поручение должно иметь следующие поля:

1. уникальный номер
2. дата и время создания
3. дата и время оплаты
4. юридическое лицо (контрагент) которому была произведена оплата
5. сумма
6. тип платежа

Сразу отмечу что почти никогда не стоит связывать уникальный номер документа с id записи в таблице БД. Дело тут вот в чем: пользователи имеют свойство ошибаться. Логика пользователей иногда весьма своеобразна, к примеру, периодически им легче удалить неправильно созданный документ и создать его по новой (особенно это касается новых сотрудников, которые боятся “накосячить”). После подобных действий у вас в системе будет множество пустых “дыр” между номерами документов. Казалось бы мелочь, но любая проверка со стороны “заинтересованных” лиц найдет в этом тайный умысел. (Если хотите реальных примеров, погуглите “Прайм-ТАСС подало в суд на мэрию Москвы”. Вся их доказательная база — номера документов шли по порядку, но в общественном доступе есть только часть из них). Лучше всего, по нашему мнению, вновь создаваемому документу присваивать номер = максимальный уникальный номер в системе по данному типу документов + 1.
Но вернемся к нашему примеру. Обратим внимание на поле №4 — юридическое лицо. Коль скоро у нас имеется справочник юридических лиц, то очевидным является записывать в это поле ссылку на запись в этом справочнике.
А теперь представим себе несколько возможных ситуаций:
1) Платежное поручение было создано в 2009 году. Платеж был произведен ООО “Кровать”. В январе 2010 фирма была переименована в ООО “Стулья”. Получается что если мы откроем форму платежного поручения в конце 2010 года, то увидим что платеж был произведен фирме, которой в 2009 году физически не существовало.
2) Допустим в марте 2010 года произошло слияние ООО “Кровать” и ЗАО “Диваны”, результатом стало ОАО “Диваны и кровати”. Что могут сделать пользователи? А они могут переименовать фирму ООО “Кровать” в ОАО “Диваны и кровати”, а еще они могут переименовать ЗАО “Диваны” в “Диваныи кровати”. Самое интересное начнется при первом же отчете, когда окажется что все платежи между разным юридическим лицами (3мя фактическими и 4мя в базе) перемешались и отличить их могут только люди, которые производили оплату (которые, к сожалению, попали под сокращение штата и уже несколько месяцев не работают в вашей фирме).

Так сложилось, что моя карьера — сначала разработчика, затем архитектора, технического директора и наконец предпринимателя, развивалась преимущественно в околофинансовом секторе. Большая часть моей профессиональной деятельности прошла в проектировании и написании софта для банков, компаний-брокеров и схожих с ними компаниях. Об одной из наиболее типичных технических проблем финансового сектора я и хотел бы рассказать уважаемым хабравчанам.



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

Несколько месяцев назад на Хабре был опубликован материал, в котором описывался алгоритм движения денег в банковской системе. Однако привычные нам банки — не единственный инструмент, которые жители разных стран мира используют для работы с финансами.

Одна из таких финансово-расчетных систем получила название «Хавала». Она зародилась в Индостане задолго до появления банковской системы западного образца (по разным оценкам, она работала уже в 8 веке), и до сих пор используется многими гражданами стран Среднего Востока, Африки и Азии в качестве альтернативного инструмента расчетов.

Фото из Гугла, это не мама автора

Моя мама начала работать в одном из крупнейших банков ЕС ещё до моего рождения, а я всегда был неравнодушен к её специальности, особенно в последние годы, поскольку сам стал программистом. Меня много раз просили взять у нее интервью, и я, наконец, решил это сделать.

Объясню немного

Мир банковского программного обеспечения — это другая вселенная. Она сильно отличается от той, к которой привыкло большинство из нас. Я публикую этот пост на HN и на Reddit. Публикую интервью не в виде вопросов-ответов, а в виде рассказа. Я добавил некоторые вопросы и ответы в нижнюю часть поста.

1991

Год, когда она начала внутреннее обучение в банке Nordea, который тогда назывался Nordbanken (Северный банк). В 2001 году его переименовали в Nordea. Во время обучения она должна была проходить различные тесты, в первую очередь тест IQ, чтобы показать, что она обладает интеллектом, достаточным для работы в этой области. Тест на психологическую устойчивость — что у неё достаточно нервов для этой специфической работы и тест на многозадачность, который она завалила с оценкой 22/100. Остальные тесты она прошла успешно и заняла одну из 16 доступных позиций.

Должность звучала «как программист мэйнфреймов IBM на языке COBOL», и до сих пор, уже 25 лет, моя мама работает на этой должности в том же банке.

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

Финансовая справка: я никаким образом прямо или косвенно не задействован в сфере криптовалют и вообще в инвестировании в компании, работающие с распределенными реестрами.

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

Эта статья назревала давно: уже больше пяти лет мне задают вопросы, которые укладываются в один из трех шаблонов:

• Как вы относитесь к блокчейну? Почему хорошо / почему плохо?
• Стоит ли инвестировать в (название криптовалюты)?
• А правда, что блокчейны делают (полезную вещь) для (группы людей)?

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

В блогосфере уже и так хватает отличных технических и полемических текстов, которые досконально объясняют, почему в сфере криптовалют всё, говоря попросту, очень плохо. Поэтому я зайду с другого угла: начну с финансовых сложностей, для которых лично мне хотелось бы получить решение, а потом, двигаясь от общего к частному, разъясню, почему блокчейн, на мой взгляд, не способен адекватно с ними справиться.