Традиционно на первом этапе DQS подключается к системе MDM, поскольку управление качеством мастер-данных считается более приоритетным, чем операционки.
Возможно, я не совсем чётко эту мысль выразил. На первом этапе, конечно, функция контроля качества данных должна жить в MDM.
А следующим логичным шагом будет контроль качества в других, не мастер-данных. И тут пригодятся наработки и опыт, полученный в MDM.
А что DQ нужно пускать перед MDM — отличный подход, спасибо за него!
Система распознавания человека по движениям, по походке уже запущена во всех крупных городах. Вас распознают по слабому прихрамыванию на правое колено и привычке несимметрично махать руками.
Коммерческие (экспортные) перспективы у БН-1200 и СВБР-125 такие же, как у БРЕСТа, к сожалению.
И пример про самолёт в теме про реактор неуместен.
Но вы правы, что не всё так однозначно.
Но не потому что А380 неэкономичный, а потому что в мире объективно мало маршрутов, на которых его можно загрузить.
И отказываются не в пользу суперсоников, а лишь немного меньших B777 и A350.
бигдата в 2021 году еще хайп, а не обязательный инструмент
Благодаря вашему посту могу добавить ещё один критерий в список — оперирование широкими и заведомо неконкретными понятиями.
Какая там, в финтеке, Big data, обычный матан и матстат. Навёрнуты тонны костылей, чтобы реализовать тривиальные алгоритмы, многие из которых остаются неизменны со времён фортрана. И толпа аналитиков, которые пытаются в этом болоте что-то выудить, совсем как в заглавной картинке. Она неспроста стала мемом.
Набор скриптов, обеспечивающих преобразование информации из 100500 разных форматов в требуемый для ESB.
К БД вам полный доступ не дадут, только к определенной выгрузке.
Не хочется выступать в роли К.О., но это говорит, что за изменения взялся человек без нужных полномочий. Вряд ли проекты уровня внедрения ESB вообще могут быть реализованы без поддержки топ-менеджмента компании. А в этом случае не бывает аргументов, типа «мы вам то-то не дадим». Что потребуется, то и дадут.
И можно пример «правильного» применения ESB.
Если вопрос про мой личный опыт, могу привести примеры в ЛС.
Так ведь главное преимущество ESB — наличие огромного множества коннекторов ко всему подряд. Ничего писать не надо, оно уже есть из коробки, только настраивай потоки (поля, если необходимо, трансформацию, обогащение), обычно этим занимается системный аналитик.
Даже если нужно написать новый коннектор, это делается однократно, а не для каждого взаимодействия отдельно.
Опять пишем сервера на А для Е(С), потом клиент Е(С), потом сервер Е(С), потом клиента С(Е).
Возможно, я не прав, но могу предположить, как такое получилось. У человека, который управляет ESB (это роль не столько техническая, сколько управленческая: общаться и договариваться), не хватило полномочий, чтобы продавить «правильное» применение ESB. Грустная ситуация.
Главное заблуждение при внедрении шины, это то что можно избежать комбинаторного взрыва при интеграции.
Честно говоря, я не вижу, каким образом при правильном применении ESB можно получить комбинаторный взрыв. На практике с таким не сталкивался.
С микросервисами — многократно, с ESB — нет.
Любую здравую идею можно довести до абсурда. А в случае полной смены команды риски возрастают многократно.
У меня есть опыт успешных применений ESB, лишённых описываемых вами проблем. Работать над этим пришлось, конечно, много. Затраты превысили десяток человеко-лет. В самом объёмном примере в контуре больше 20 систем и 400 сущностей.
И до сих пор у банка «А где ответ на запрос то?» -> «А мы не знаем… не можем найти какая шина куда отдала и кому вообще».
Судя по всему, в этом и заключается проблема. Пытались решать?
Можно привести шуточную аналогию с вопросом «кто виноват во всём этом бардаке?»
Виноват тот, кто не смог декомпозировать бардак на отдельные проблемы и решить каждую из них подходящим способом.
Управление качеством данных складывается из двух функций, если хотите, из двух разных отделов. Один из них должен придумывать правила. Второй — технически обеспечивать работу правил, т.е. чтобы все правила реально работали, люди не пытались «хакнуть систему» и вводить некорректные данные.
Возможно, я не совсем чётко эту мысль выразил. На первом этапе, конечно, функция контроля качества данных должна жить в MDM.
А следующим логичным шагом будет контроль качества в других, не мастер-данных. И тут пригодятся наработки и опыт, полученный в MDM.
А что DQ нужно пускать перед MDM — отличный подход, спасибо за него!
Более того, для хождения галсами обязательно наличие опоры (воды), поэтому у яхт такой большой киль.
Грустное следствие: под солнечным парусом в космосе лавировать не получится, фантаст в рассказе про гонки нас обманул.
И пример про самолёт в теме про реактор неуместен.
Но вы правы, что не всё так однозначно.
— это грубая ошибка. Винительный падеж, себя можно проверить вопросами «кого? что?»
Т.е. «не теряйте дар речи».
И отказываются не в пользу суперсоников, а лишь немного меньших B777 и A350.
Благодаря вашему посту могу добавить ещё один критерий в список — оперирование широкими и заведомо неконкретными понятиями.
Какая там, в финтеке, Big data, обычный матан и матстат. Навёрнуты тонны костылей, чтобы реализовать тривиальные алгоритмы, многие из которых остаются неизменны со времён фортрана. И толпа аналитиков, которые пытаются в этом болоте что-то выудить, совсем как в заглавной картинке. Она неспроста стала мемом.
Не хочется выступать в роли К.О., но это говорит, что за изменения взялся человек без нужных полномочий. Вряд ли проекты уровня внедрения ESB вообще могут быть реализованы без поддержки топ-менеджмента компании. А в этом случае не бывает аргументов, типа «мы вам то-то не дадим». Что потребуется, то и дадут.
Если вопрос про мой личный опыт, могу привести примеры в ЛС.
Даже если нужно написать новый коннектор, это делается однократно, а не для каждого взаимодействия отдельно.
Возможно, я не прав, но могу предположить, как такое получилось. У человека, который управляет ESB (это роль не столько техническая, сколько управленческая: общаться и договариваться), не хватило полномочий, чтобы продавить «правильное» применение ESB. Грустная ситуация.
С микросервисами — многократно, с ESB — нет.
Можете в общих чертах описать кейс, пожалуйста?
У меня есть опыт успешных применений ESB, лишённых описываемых вами проблем. Работать над этим пришлось, конечно, много. Затраты превысили десяток человеко-лет. В самом объёмном примере в контуре больше 20 систем и 400 сущностей.
Судя по всему, в этом и заключается проблема. Пытались решать?
Виноват тот, кто не смог декомпозировать бардак на отдельные проблемы и решить каждую из них подходящим способом.
Управление качеством данных складывается из двух функций, если хотите, из двух разных отделов. Один из них должен придумывать правила. Второй — технически обеспечивать работу правил, т.е. чтобы все правила реально работали, люди не пытались «хакнуть систему» и вводить некорректные данные.