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