Comments 61
Есть ПИН клиента (по которому однозначно определяется его тип, а их чуть больше, чем «физик» и «юрик»). Есть счет клиента (20-значный и 13-значный — спутать их трудно т.к. они отличаются как размером, так и структурой). 13-значка вообще больше для внутреннего использования. 20-значный же содержит в себе счета 1-го и 2-го порядков, валюту счета…
И вот точно ни разу не сталкивался с тем, чтобы приходилось переспрашивать «а что вы имели ввиду»).
Статья все-таки о том, как найти взаимосвязи, а не четко определить смысл.
И тут речь идет о маппингах, где сотни полей, разного смысла. И смысл непонятен интегрально. И команда состоит из людей, не всегда ясно понимающих суть из-за специфики. А так-то конечно, хороший банковский аналитик аналитик все сопоставит. Но вот где они?
Т.е. проблема скорее управленческая — как выстроить рабочий процесс от хотелок бизнеса до внедрения продукта в бой.
Часто бывает так, что команда, вновь заходящая не ищет уже существующую сущность, а придумывает свою. И вот таких команд уже 10-ки
А вот для этого и нужно согласование BRD и FSD на соответствие стандартам банка.
И еще раз с вами соглашусь, что нужны стандарты и правила. Но, допустим, есть некое типовое решение или схема, а банк решает некую нестандартную ситуацию, которая в эту схему не вписывается… как тут быть?
Своя команда быстрее реагирует на любые проблемы. И ее легче заставить играть по одним правилам.
Новые технологии и новые идеи? Вы о чем вообще? Где-то на фронтах — да, там может что-то быть. Но мы-то работаем в глубоком бэке на уровне ядра АБС. Там все технологии диктуются платформой, на которой все это работает. И идея там одна — все должно работать максимально эффективно и максимально надежно.
С нуля никто ничего не делает. Есть АБС, мы ее адаптируем под наши условия и расширяем ее возможности.
А стандарты и правила нужны для того, чтобы все хорошо стыковалось между собой и ядром АБС. Ну вот например — читать из таблиц можно как угодно, но писать в них (за исключением каких-то временных или промежуточных) можно только через специальные модули внешнего ввода. Которые обеспечивают журналирование всех действий и всю логику работы с таблицей (такой модуль может одновременно работать с несколькими связанными таблицами, вести архивы, обеспечивать откат и т.д. и т.п. Это стандарт. Есть еще «нефункциональные требования» которые диктуются эффективностью.
Есть стандарты на взаимодействия со внешними системами…
Ну вот вы приходите в новый отдел, а вам говорят, что для организации работы агента на станции нужно задать локацию, в которой приманучены модели концепций для инстансов рутера.
И не дай бог вам подумать, что рутер — это брокер. Или L3-железка с портами.
Одно могу сказать — любой рабочий процесс начинается с установки общих для всех правил игры — стандартов, терминологии… Причем все это должно документироваться.
И чем крупнее команда, тем это важнее.
Мое мнение обычно расходится с трендом (что негативно отражается на карме :-)
Цель нашей работы — предельная эффективность и надежность кода (на уровне ядра АБС). Там где это достигается микросервисом — будет микросервис. Где иными подходами — будут иные подходы.
Про нормализацию БД слышали? Так вот у нас она нарушается. Просто потому, что нормализация ради нормализации часто дает проигрыш в эффективности и скорости работы. И там где это критично нормализация нарушается. Сознательно.
Микросервис это, как-правило, бесплатный брокер типа Кафка и написанные на Java алгоритмы. Почему Кафка? да потому что это фриварное решение… можно годами спорить о фриварных решениях. И микросервисах и правилам обращения с ними в банках, я напишу отдельную статью. Пока просто захотелось поделиться впечатлениями от составления маппингов)
У нас никакой джавы, никакой кафки. Джава есть наверху где-то, на уровне WS и выше.
Кафка тоже вроде есть где-то.
У нас никаких модных слов. Сплошной легаси. Погуглите про платформу IBM i, язык RPG, очередь MQ от IBM. И АБС MiSys Equation. Вот это то, с чем мы работаем. Все это стоит безумных денег (кластер из трех PowerS928 на бою, на каждом по 16 12-ядерных SMT8 и по 2.5ТБ оперативки). Но все это сопровождается поддержкой от производителя. Быстрые консультации по любым вопросам, заказ выездного аудита по производительности с выявлением потенциальных проблем и т.п. Никакой фриварь такого не предоставит.
Я не буду приводить примеры того, что мы делаем для оптимизации эффективности работы — они слишком специфичны и требуют понимания того как устроена и работает платформа IBM i, но поверьте — там такие тонкости, на которые 95% обычных разработчиков просто не обращают внимания.
Так что все модное — это там, наверху. Но все оно опирается на наш легаси.
Я нигде не писал что мой подход единственно возможный всегда и везде. Но, извините, вызывает недоумение когда человек с опытом работы на фронте, пытается рассуждать о работе на стороне глубокого бэка (на уровне ОС примерно). Поверьте, тут свои подходы и свои проблемы. И свои требования.
Я не берусь судить о проблемах фронта. Но зато очень хорошо знаю что случается когда один из тысячи процессов бэка вдруг начинает тормозить систему настолько, что все запросы от внешних систем начинают отваливаться по таймауту.
Это так, к слову.
Я не считаю себя архитектором, но некоторый опыт в построении архитектуры распределенных систем у меня таки есть.
И в этом свете мне кажется что данная статья — это истороия большого архитектурного факапа, который пытаются облечь в обертку из модных слов. Вместо того, чтобы сесть и разобраться в истинных причинах. И выработать стандарты взаимодействия различных частей системы.
Да, это может быть больно. Поначалу. Но в конечном итоге это только повысит устойчивость системы в целом.
А пока вы этого не сделаете, можно сколько угодно рассуждать о семантике, онтологии и даже микросервисах. Но распределенная система, части которой не связаны едиными стандартами обмена данных, развалится очень быстро.
Ну и все это должно документироваться на всех этапах.
И в этом свете мне кажется что данная статья — это истороия большого архитектурного факапаЯ тоже согласен, что в статье пытаются решить организационную проблему техническими средствами, но многие ваши комментарии имеют рефрен «а вот у нас нагрузки, ответственность, IBM i, RPG, база на уровне ОС и традиции, проверенные десятилетиями». У многих (большинства) других людей тоже нагрузки и ответственность, но справляются как-то, и даже используя более современные и не привязанные к вендору технологии.
Правда в том, что вы не заставите всех в банке говорить на одном языке. Хотя бы потому что в нем сталкиваются ай-тишники и гумманитарии, экономисты и пиарщики и клиенты всех самых разных мастей. Общий стандарт для банка это такая же утопия как «эсперанто» или «всемирное построение коммунизма». Никогда не будут люди говорить на одном языке на Земле. Поэтому чем крупнее банк, тем более обречена на забвение идея об общих стандартах или словарях.
Правда в том, что вы не заставите всех в банке говорить на одном языке.Почему? Про это было написана куча книг, в том числе про DDD, помимо программистов есть куча вспомогательного народа, основная обязанность которого переводить с языка потребителя на язык программиста… Это управленческая задача, причём эта задача решается при изготовлении любого сложного технического решения.
Ок. Допустим, вы все-таки утвердили единый словарь предприятия и каким-то образом заставили говорить всех на одном языке. Как тот самый новояз из «1984» Д. Оруэла. И что… наступает нехватка слов., скудность мысли. Банк чахнет. Конечно, я утрирую, но надеюсь мою мысль вы поняли.
И вот вы, все это хозяйство хотите заставить говорить на одном языке?Да. Для этого начальство и нужно. Пока всё хорошо, начальником может быть котик, а вот когда начинаются проблемы, которые по каким-то причинам не закрыты регламентом, нужно начальство. Чтобы или договариваться (даже если собеседник не хочет), или брать на себя ответственность («Мы подумали и я решил»).
Конечно, крупные банки начинают «играть в Вавилон», почему? да потому что, крупный банк имеет много подразделений, дочерних структур и с этой проблемой сталкивается, вот и начинают вкладывать средства в её решение. И, к сожалению, я не посмотрел в какой сфере вы работаете, и какой пример бы вам подобрать, но в крупном банке уровня ТОП-5 довольно сложно контролировать все из одной точки, хотя бы потому что в нашей стране есть разные часовые пояса, что накладывает дополнительный отпечаток на деловой оборот.
Я, когда программирую, занимаюсь или микроконтроллерами, или обработкой изображений. С МК всё понятно: договорились, в каких попугаях считаем величины, и пишем адаптер-конвертер. С изображениями тоже не очень сложно: пока заказчик не ткнёт в картинку и не скажет — «объект вот это!», делов не будет, словесные описание почти всегда не работают.
Давайте сравним работу банка с разработкой технического изделия, пусть будет самолёта. У вас есть куча требований от различных контролирующих организаций, есть сопромат, есть законы физики, есть внутренние требования к разработке и много всякого прочего, что ставит кучу ограничений. И внутри вы должны решить, какие потребительские качества получающегося продукта должны превалировать. Собсно, тут сверху и спускается, что
микроконтроллера один папа.У микроконтроллера один папа (и то не всегда), только один он никому не нужен. А вот когда собираются механик, электрик, схемотехник и программист — тогда получается продукт. и да, продукты «давайте прикрутим сюда
В банке, с его многочиленными подразделениями, все перемешаноЯ плохо понимаю, как это вообще может быть. В одной системе работаете-то, и не первый год, значит есть как минимум внутренний регламент (про совместные ценности и прочие баззворды пока забудем), на основании которого пишется ТЗ. Не берутся же задачи и команды из воздуха, чтобы через какое-то время раствориться обратно?
Не берутся же задачи и команды из воздуха, чтобы через какое-то время раствориться обратно?
В условиях крупных компаний это частое явление. И вот когда уже совсем плохо, тут и появляется консалтинговая компания Accenture. Спасибо за ваши комментарии! Мне стало понятно, что проблему надо описывать подробнее и подробнее объяснять, откуда она взялась.
тут и появляется консалтинговая компания Accenture.По-моему, консалты, сторонние аналитики и SAP приходят, когда деньги ещё есть, а единого сквозного управления уже нет. Временное улучшение от них может быть, а вот постоянное — только если владелец не верит в магию и не готов ограничиться перестановкой кроватей.
Проблема не в команде, а во взаимодействии между командами, у каждой из которых свои concern. И вы можете сколько угодно называть всех вместе одной командой, но на самом деле, если цели разные, то и команды разные. И языки. Включая тонкую омонимию, разные онтологические модели и т.д. Это очень тяжело преодолевать.
Онтология — не наука, а направление философской мысли. Это означает, что они только задают вопросы, а не дают ответы.
Вот, видите, вы уже начинаете вкладывать свой смысл в слова.
Онтология — это направление мысли. Это не "концептуализация спецификаций", это (цитата из Википедии): "Онтология, таким образом, представляет собой попытку наиболее общего описания универсума существующего, который не ограничивался бы данными отдельных наук и, возможно, не сводился бы к ним. "
Как бы спецификации тут явно лишние.
На самом деле, избыток онтологии приводит к вопросам философского характера, ответы на которые явно не являются бизнес-процессами.
Скорее, задача сводится к поиску правильных названий (вторая сложная проблема, да). Желательно, без размножения стандартов. Это требует огранизационных усилий и убедительности. Хорошо придуманное название сжирает конкурентов в силу удобства и точности.
И да, онтология действительно задает впросы. Консалтинговые компании дают ответы. Моя статья — попытка дать ответ математически.
Онтология — это направление мысли. Это не "концептуализация спецификаций", это (цитата из Википедии):
Ну, не совсем. Это слово может означать вполне конкретный артефакт с "описанием мира", слов, используемых для этого описания и так далее. Для их создания таких артефактов даже специальные редакторы есть. Вот только я подозреваю, что понимает, как ими пользоваться на пользу дела, приблизительно никто даже среди их создателей.
Условно говоря так — вот в прошлой жизни делали распределенную систему мониторинга инженерного оборудования зданий. Состояла она из трех частей — сеть контроллеров, верхний уровень которой был доступен для обмена, набор интерфейсных клиентов для взаимодействия с пользователем и микроядро, которое отвечало за реализацию отношения «многие [контроллеры верхнего уровня] ко многим [интерфейсные клиенты]» Каждая часть делалась разными людьми (я занимался разработкой микроядра).
Так вот были жесткие договоренности по форматам протоколов обмена. Они соблюдались неукоснительно. Что происходит внутри каждой части — это уже ответственность разработчика. Но протоколы должны соблюдаться.
Сейчас в принципе ситуация похожая. Есть АБС. Она работает по своим правилам и поддерживается командами бэкенда. Есть клиентские сервисы (тот же инетбанк или мобильный клиент). Есть еще внешние системы. И есть четкие стандарты — для инетбанка и мобильного клиента есть REST API, которое опирается на вебсервисы. Ведсервисы дергают на нашей стороне определенные универсальные интерфейсы для которых мы пишем соответсвующие сервисмодули. Тут все стандартизировано. Ни один вебсервис не пройдет в разработку до согласования — стандартное имя, мнемоника, сервисмодули и т.п. Сделали WS, сделаи сервисмодули, прописали все в настроечных таблицах и все работает.
С внешними системами общение идет через очереди (WBI-MQ). Тут тоже все стандартизовано — есть универсальный «читатель» MQ и стандарт обработчика MQ сообщений. Тут аналогично — есть формат сообщения, под него пишется обработчик со стандартным интерфейсом, регистрируется в настроечной таблице и вперед.
Внутри своей части каждая команда работает по своим правилам. Но взаимодействие между компонентами системы стандартизовано.
Внутренние стандарты есть система соблюдаемых всеми договоренностей, которые всех в той или иной степени устраивает.
Вот у нас есть архитектор, отвечающий за WS. Он разрабатывает стандарты на WS. У нас есть свои архитекторы на уровне ядра. Они разрабатывают стандарты на те модули, которые (в нашем случае) будут отвечать на нашей стороне на запросы через WS.
Если фронту нужен новый WS, они пишут т.н. INI на него с описанием что будет на входе, что на выходе, имя WS, имя сервис-модуля который будет его на нашей стороне обслуживать (за этим они идут к нам — мы это имя выдаем).
Если все написано по стандарту, INI согласуется и все это запускается в работу. Если нет — извините. Извольте соответствовать нашим требованиям.
Тут каждый отвечает за свою часть и формирует правила, которые обеспечивают эффективность и устойчивость его части.
Я уже описывал ситуацию с распределенной системой — внутри совей части делай что хочешь, но протоколы взаимодействия изволь соблюдать. Иначе тебя просто не поймут на той стороне.
Ужас, а не статья.
Автор. По моему у Вас проблемы с семантическим кошмаром. Наплодили сущностей. Всё в кучу.
Бритва Оккама вам в помощь.
Часто бывает так, что команда, вновь заходящая не ищет уже существующую сущность, а придумывает свою.
Или смотрит на существующую сущность с сотней полей и глубиной в 30 уровней. Говорит "Да вы с ума сошли, нам тут все эти мегабайты непонятных данных не надо. А надо вот это поле и вот это на 10 уровне вложенности". После чего придумывает свою сущность с этими двумя полями.
Три простых метода справиться с любой проблемой:
0) Игнорировать.
1) Объявить несущественной.
> вы находитесь здесь <
2) Объявить проблему личной проблемой того, кто про неё рассказывает.
Получиться хороший анализатор бреда заказчика!
Решение задачи, которое вы предложили, называется в народе character-level embedding ;)
Основной недостаток: не может найти близость слов типа "курица" и "цыпленок". Советую посмотреть в сторону word2vec (есть готовые модели для русского, но лучше учить на нескольких гигабайтах специализированных текстов).
Я думаю, что широкому кругу данный метод знаком под названием «поиск Манхетенского расстояния». И на новизну мы тут, ни в коем случае, не претендовали. Более того, вторая ссылка к статье как раз ссылается на источник, в котором есть наиболее стройное описание математики. А вообще, методы векторизации известны давно. Я, например, сталкивался с ними в бытность занятий теоретической физикой.
Да. Вы правы, «курица» и «цыпленок» никаким математическим методом не зацепить. И собственно говоря, контекст нашей работы на это и указывает. Было бы все так просто, консалинговые компании заставили бы аналитиков делать маппинги в банках за еду. Но нет. Всегда есть «курица», «яйцо», «цыпленок», «петух», а также «курятник». Как раз об этом и наш посыл. Работа не про метод, но про явление «семантического безумия» в ИТ-системах банков.
Спасибо за рекомендации испрользовать word2vec. Мне знакома данная библиотека. Может быть, я как нибудь напишу об опыте её использования. Однако, наша компания говорит о том, что каждый банк уникален, как и каждый клиент. И важнейшей задачей тут является сохранение уникальной идентичности бизнеса клиента после внедрения какого-либо ИТ-решения. А когда ты используешь готовые библиотеки, ты уже загоняешь его в некоторые рамки… Поэтому, мы всегда копаем до асфальта и начинаем от Адама и Евы, получая уникальные результаты.
Как по мне, это скорее Евклидово расстояние, нежели чем Манхэттенское ;)
Дело как раз в том, что word2vec и его аналоги умеет находить семантическую близость между словами. Рекомендую зайти на https://rusvectores.org/ и поэкспериментировать. Год назад я встречал статью в Nature, в которой авторы смогли предсказывать химические свойства соединений с помощью эмбеддингов. Поэтому я думаю, что для вашей задачи это тоже может дать гораздо больше, чем простой подсчет символов.
Кстати, по NLP советую глянуть книгу С. Николенко с соавторами, "Глубокое обучение", она гораздо лучше чем та, что вы цитировали (мне лично книга Бенгфорта с компанией показались слишком слабой работой и изрядно устаревшей в момент написания).
И последнее: для NLP и машинного обучения в целом лучше говорить не о библиотеках и алгоритмах, а о данных и моделях. Вот например коллеги из Яндекс совершенно открыто рассказывают об основных алгоритмах, которые у них крутятся, т.к. их петабайт данных и моделей на их основе все равно больше ни у кого нет! И данных банков тоже нет больше ни у кого.
Ок… я зашел, на указанный вами ресурс. И что же я получил? я ввел в строку «номер счета клиента», и что получил? «Модели неизвестно такое слово»… Хотя ресурс и правда интересный и наверное его можно применять для решения задач составления маппингов. Особенно он будет полезен, когда необходимо будет проводить глобальную оцифровку разных видов деятельности, и особенно если дело касается так называемого «интернета вещей».
Для меня не секрет, что word2vec использует обучающие модели, а мы в своей работе не использовали обучение, а применяли чистую векторизацию. Еще раз прошу вас осознать тот факт, что мы работаем в пределах замкнутого предметного поля (конвейер на котором живут микросервисы как правило затрагивает «семантическую вселенную» довольно в ограниченном масштабе) и «глубокое обучение» нам по-хорошему не очень то и нужно. У нас и так соответствие между атрибутами найдется в 80% случаев, а где не найдется, ну там и нужны будут аналитики… И интересовала больше кластеризация, для дальнейшей перегонки в классы JAVA и таблиц баз данных. И это правда не химия, не поиск новых материалов — это банкинг. И я прекрасно осознаю, что банкинг это не масштаб журанала Nature. Хотя, в целом конечно, вы правильную и интересную вещь говорите — создать обучающую модель для составления маппинга. Возможно, что мы находимся на старте и позже вернемся к этой идее… И возможно опубликуемся где-нибудь в SCOPUS, изложив всю математику. Но, пока, мы на хабре…
Алгоритм Jerdella: решаем проблемы семантического безумия в IT-системах банков