Comments 13
«С годами компания обычно доходит до того»… Я считаю, что лучше дойти до того, чтобы по тексту ДО ката было понятно о чем речь…
Немного поправила, если и сейчас непонятно — скажите. Тема сложная, о ней не с первого раза получается хорошо написать )
Можно — есть организации, в которых не внедрены НСИ. Внимательно посмотрев, вы обнаружите в этих организациях много маленьких таблиц соответствия между справочниками «Пол», «Образование» и пр. в разных системах. Храниться они будут то в Oracle, то на шине, а то и прямо в коде для загрузок-выгрузок и экспортов-импортов. Потому что таблицы соответствия — это самый естественный способ решения проблемы, когда одинаковый домен для разных людей или систем обозначается по-разному.

А вы в курсе, что есть системы НСИ, где одновременно существуют и мастер-данные, и таблицы перекодировок? И более того, эти самые таблицы перекодировок строятся — и меняются — в процессе эксплуатации системы на основании экспертного заключения о данных из участвующих систем?
В курсе. Основная мысль статьи в том, что мастер-данные можно и не создавать.
В данном случае я под управляемостью понимаю то, что при наличие мастера мы отслеживаем изменения в каждой системе относительно мастера; изменения каждой системы влияют на мастер (или на перекодировку), изменение мастера влияет на каждую систему (или перекодировку), но все эти влияния идут через мастер.

Представьте, что вы гоняете один и тот же справочник через 5 систем. У вас будет, если я не путаю, 24 перекодировки, при этом на каждую систему влияют по четыре других (т.е., каждое изменение в четырех других системах надо анализировать на предмет внесения в перекодировочную таблицу). Когда у вас мастер, то у вас 5 перекодировок (уже экономия) + изменение в каждой системе анализируется на предмет внесения в мастер, и только если оно влияет на мастер, то оно уходит в другие системы.
В децентрализованном подходе изменения отслеживаются в каждой системе относительно друг друга. Казалось бы, их должно быть N*(N-1), то есть в пределе 20 для 5 систем, если мы считаем, в самого себя перекодировать не надо, при этом перекодировка может быть несимметричной.

Но их будет намного меньше. Скорее всего, около 5 и будет. Потому что в реальной жизни относительно каждого справочника каждая система является либо поставщиком данных, либо их потребителем. Редко когда и то и другое. Бизнес-процессы и потоки данных — преимущественно дороги с односторонним движением. То есть если у нас нет потока данных из системы A в систему B, то перекодировки A -> B не будет, и отслеживания изменений относительно этого мэппинга тоже.
Потому что в реальной жизни относительно каждого справочника каждая система является либо поставщиком данных, либо их потребителем.

К сожалению, это далеко не всегда так. Вот у нас тут в проекте есть СЭДО, портал, шарпойнт (это две разных вещи, да), учетная система и система управления процессами. В каждой из них есть справочник типов документов. И между всеми из них гуляют документы.
Если так брутально, то да, будет 20 перекодировок, каждая по нескольку записей. Но это все же редкость, из-за того, что системы сильно дублируют функционал друг друга, и фактически есть несколько копий каждого бизнес-процесса.

Все же мне кажется, что направлений движений документа даже в таком случае будет меньше 20. Зачем, например, двунаправленная связь между СЭДом и Порталом или между Учетной Системой и Порталом?
Потому что документы, созданные на портале, должны лечь в СЭДО, а документы, созданные в СЭДО, должны попасть на портал.
… чтобы удовлетворить всех участников информационного обмена: шину, ETL-скрипты, обслуживающие процедуры реального времени, макросы в Экселе, космическую станцию и пр.

Забыли добавить: "… и небо, и Аллаха!"

А по сути:
Основное назначение Перекодера — хранить в себе копии справочников исходных систем и перекодировки между ними.

Хранить копии справочников всех систем, не похоже на децентрализацию, наоборот, похоже на ленивую-МДМ, у которой избыточность в данных, необходимость синхронизации со всех сторон, еще и мепинг.

Так ли плоха традиционная схема:

— МДМ-система с разными справочниками и классификаторами, которые являются эталонными и имеют все нужные атрибуты у объектов-записей этих контейнеров. Интегрированные сторонние системы имеют на своей стороне нужные полные/частичные копии эталонных справочников, имеют синхронизации.
— Обмен данными осуществляется в едином формате для каждого справочника/классификатора, либо разных, но «перекодировка» осуществляется централизованно, на шине, например.
— Изменение эталонных данных в МДМ-системе осуществляется в наборе воркфлоу или прозрачных потоков изменения данных для нужных интегрированных систем
— Сама МДМ-система заботится о уведомлениях об изменениях в нужные системы.

Плюс ко всему, получаем полнотекстовый поиск по всем данным «из коробки»


Этот плюс, получается, не плюс, а необходимость, когда нет мастер-данных.
МДМ-система с разными справочниками и классификаторами, которые являются эталонными и имеют все нужные атрибуты у объектов-записей этих контейнеров. Интегрированные сторонние системы имеют на своей стороне нужные полные/частичные копии эталонных справочников, имеют синхронизации.


Это только в теории хорошо звучит. На практике

(1) согласование эталонов происходит медленнее, чем изменение бизнес-потребностей, и

(2) внесение изменений в сторонние системы, чтобы они питались эталонами, либо не представляется возможным, либо требует неадекватных усилий.

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

«перекодировка» осуществляется централизованно, на шине, например


Почти всегда есть потоки данных, которые идут мимо шины. Например, ETL для аналитического хранилища. Если его пустить через шину, то за время перегрузки данных они успеют потерять актуальность.
Only those users with full accounts are able to leave comments. Log in, please.