Master Person System

Entita dat o osobách (dále také jen „Party“) je obvykle klíčová pro jakýkoliv obchodní informační systém. Party může reprezentovat fyzické osoby (např. leady, zákazníky) nebo právnické osoby (např. dodavatele, odběratele).

Obvyklými motivy pro zavedení Master Data Management pro entitu Party je řešení následujících problémů a potřeb:

• řešení problémů s kvalitou osobních dat,
• potřeba unikátnosti Party v rámci celého informačního systému klienta,
• potřeba konsolidace atributů Party z více systémů,
• vytváření tzv. „zlatých záznamů“ Party jako nejlepší reprezentace osoby.

Master Person System je naším řešením pro Master Data Management pro entitu Party. Naše řešení není samo o sobě jediným kompaktním produktem, ale spíše souborem nástrojů, které jsme úspěšně implementovali a využili a které budeme aplikovat v našich budoucích projektech.

Klíčové benefity

• Náš přístup k řešení reflektuje úspěšnou dodávku analogického řešení pro Master Data Management pro doménu Party pro přední českou finanční instituci.
• Náš přístup jsme připraveni realizovat ve variantě Cloud i variantě On-Premises; předpokládáme, že klient si vybere vhodnější variantu dle jeho specifické situace.
• Implementace našeho přístupu staví na enterprise technologiích, které dodávají silní vendoři s celosvětovou působností (nenavrhujeme řešení na lokálních nebo našich technologiích).
• Pro všechny navrhované technologie existuje a lze předpokládat, že existovat bude, široká nabídka odborných kapacit v konkurenčním prostředí.
• Navrhované varianty řešení jsou otevřené v tom smyslu, že pro budoucí změny a rozvoj aplikační logiky bude mít klient flexibilitu ve výběru dodavatelů (ne vendor lock-in).
• Navrhujeme řešení, které splní specifické podmínky a požadavky klienta (nikoliv „one size fits all“ přístup).

Klíčové koncepty

Náš přístup k systémovému řešení výše uvedených problémů a potřeb je zavedení systému pro centralizovanou konsolidaci. Schéma níže ilustruje fundamentální změnu koncepce konsolidace, kterou naše řešení přináší – přechod od fragmentované konsolidace k centralizované konsolidaci.

Master Person Systém (MPS) k řešení uvedených problémů a potřeb přistupuje následujícím způsobem:

• Kvalita dat: Systém MPS při vytváření zlatého záznamu zohledňuje datovou kvalitu zdrojových dat, referenční data (externí registry, interní číselníky) a zásadně přispívá k zvýšení datové kvality osobních dat díky centralizované konsolidaci.
• Potřeba unikátnosti Party napříč informačním systémem klienta: Systém MPS koncipujeme jako řešení, které je integrované s ostatními systémy klienta a vytváří zlaté záznamy, které jsou unikátní v rámci celého informačního systému.
• Potřeba sjednocování (konsolidace) atributů Party z více systémů a vytváření zlatého záznamu: Systém MPS je integrovaný s primárními zdroji dat a implementuje mechanismy pro vytváření, udržování a distribuci zlatých záznamů.

---

Systémová integrace

Master Person System zpracovává data osob z primárních zdrojů osobních dat, distribuuje zlaté záznamy odběratelským systémům a poskytuje rozhraní pro správu zlatých záznamů.

Schéma níže zachycuje typické integrace, kde některé systémy jsou pouze primárními zdroji dat, některé systémy konzumenty konsolidace (zlatých záznamů) a některé systémy zároveň primárními zdroji dat a konzumenty konsolidace.

Integrace zdrojů osobních dat

• Web Services: Vyhledání, vytvoření a aktualizace zlatého záznamu voláním Web Services metod (seznam metod viz níže)
• Near Real-Time: Příjem zpráv (Kafka) při změnách osob v primárních zdrojích dat pro následné zpracování změn v konsolidaci
• Batch: Dávková integrace změn osob v primárních zdrojích dat pro následné zpracování změn v konsolidaci; Batch integrace je volitelná, doplňková k Near Real-Time.

Integrace s odběrateli zlatých záznamů

• Near Real-Time: Při změnách zlatých záznamů (změnách konsolidace) jsou odesílány zprávy (Kafka) pro následné zpracování změn v odběratelských systémech.
• Batch: Dávková integrace změn zlatých záznamů pro následné zpracování změn v odběratelských systémech; Batch integrace je volitelná, doplňková k Near Real-Time.

Metody Web Services API

Pro interakci prostřednictvím Web Services poskytuje Master Person System API s následujícími metodami:

• Vyhledání zlatého záznamu na základě předaných atributů
• Vytvoření zlatého záznamu na základě předaných atributů
• Aktualizace zlatého záznamu dle předaných atributů
• Manuální spojení dvou záznamů osob jako vztahujících se k identické osobě
• Manuální rozpojení spojení osob (na základě dodatečné informace)
• Kontrola datové kvality předaných osobních údajů vůči datům v Master Person System a/nebo datům získaným z externích registrů
• Získání podezřelých spojení pro posouzení a rozhodnutí o spojení
• Potvrzení podezřelých spojení (s nižší než minimální požadovanou důvěryhodností)

Metody pro správu konsolidace (např. Manuální rozpojení osob, Potvrzení podezřelých spojení) mohou být volány buď ze specifického front-endu Master Person System, nebo, což doporučujeme, může být správa konsolidace zabudována do systému, ve kterém jsou osoby obecně spravovány – typicky CRM.

---

Modelová architektura

Naše řešení může být implementováno jak v on-premises prostředí (viz příběh klienta), tak v cloudu. Níže je představena modelová architektura varianty řešení Master Person System v cloudu. Výběr technických komponent je proveden dle specifické situace a preferencí klienta.

V představené modelové architektuře je integrace se systémem CRM a ostatními zdrojovými systémy a konzumenty zlatého záznamu řešena s využitím integračních technologií prostředí Azure a existujících on-premises technologií klienta. Konsolidace, vytváření zlatého záznamu, je implementována v Azure SQL Database, s některými částmi konsolidační aplikační logiky v Azure App Service. Řízení rozhraní, obsluha dotazů okolních systémů a řešení manuální verifikace je implementována v Azure App Service.

---

Vnitřní zpracování

Schéma níže zachycuje zjednodušený technický pohled na zpracování konsolidace.

1. Načítání dat ze zdrojových systémů do Landing Layer: Dávkové nahrávání obrazů osobních dat ze zdrojových systémů do vstupní oblasti pro navazující zpracování.
2. Detekce změn a historizace do Stage Layer (Ingestion): V případě dávkového zpracování jsou detekované změny v Landing Layer vs Stage Layer zpracovány a historizovány do Stage Layer. V případě Near Real-Time a Web Services jsou změny zpracovány a historizovány přímo do Stage Layer.
3. Transformace zdrojových dat (Transformation): Před obohacením dat osob o informace z externích registrů (Enrichment) může být nutné některé zdrojové atributy předpřipravit.
4. Obohacení zdrojových dat z externích registrů (Enrichment): S použitím vybraných zdrojových atributů jsou v externích registrech vyhledány informace o zpracovávaných záznamech osob a o tyto informace jsou záznamy obohaceny.
5. Kontrola kvality dat a výpočet důvěryhodnosti (DQ Control & Trust Calculation): Na zpracovávané záznamy osob jsou aplikovány kontroly datové kvality (DQ Checks), které identifikují atributy záznamů, které nesplňují požadovanou datovou kvalitu. Výstup z kontrol datové kvality je využit pro výpočet důvěryhodnosti vstupních dat (Trusts), která ovlivňuje procesy Matching, Merging & Splitting. Zpracovávané změny jsou následně standardizovány na jednotný „formát“ a zpracovány a historizovány do Core Layer.
6. Sestavení skupin záznamů reprezentující každou osobu (Matching): Nad transformovanými, obohacenými, ověřenými a standardizovanými záznamy je zpracován Matching – identifikace skupin záznamů osob, kde každá skupina reprezentuje identickou osobu. Matching je řízen implementovanými pravidly (Matching Rules) a vypočtenými důvěryhodnostmi vstupních dat (Trusts).
7. Vytvoření zlatého záznamu pro každou osobu (Merging & Splitting): Pro každou skupinu záznamů, které reprezentují identickou osobu, je proveden Merging – vytvoření zlatého záznamu, který nejlépe reprezentuje danou skupinu záznamů. Merging je řízen implementovanými pravidly (Merging Rules) a vypočtenými důvěryhodnostmi vstupních dat (Trusts). V rámci tohoto kroku může docházet i zpracování rozdělení dříve spojených osob – Splitting.
8. Obohacení zdrojových dat z externích registrů (Enrichment): V důsledku Merging může obecně docházet k tomu, že pro výsledný zlatý záznam lze dotazem do externích registrů získat nové informace. V rámci tohoto kroku obohacení dochází k registraci nových zlatých záznamů pro odběr aktualizací informací z registrů.
9. Nahrání zlatých záznamů do jádra (Loading Golden Record): Po aktualizaci obohacení změněných zlatých záznamů z externích registrů jsou tyto změny zpracovány a historizovány do Core Layer.
10. Distribuce konzumentům: Do odběratelských systémů jsou změny zlatých záznamů distribuovány mechanismy Near Real-Time a Batch. Specifické požadavky na strukturu a formát informací o konsolidaci jsou řešeny na integrační vrstvě.

V rámci výše uvedeného zpracování jsou využívány konfigurace (Configuration) a produkována operační metadata (Operational Metadata).

Configuration

• DQ Checks Configuration: Nastavení pravidel pro kontrolu datové kvality
• Trusts of Matching Attributes per Source: Nastavení důvěryhodností zdrojových dat
• Matching Rules: Nastavení konsolidačních pravidel
• Merging & Splitting Rules: Nastavení pravidel pro vytváření zlatých záznamů

Operational Metadata

• Data Preparation Log: Evidence zásahů do dat v rámci zpracování konsolidace
• DQ Issue Log: Evidence nálezů datových nekvalit (= nesouladů s DQ Checks)
• Matching Log: Evidence spojení a rozpojení, včetně manuálních zásahů
• Merging & Splitting Log: Evidence vytváření zlatých záznamů
• Suspected Matches – dohromady pro podezřelá spojení i podezřelá nespojení
• Log: Technický log ze zpracování (úrovně Trace, Debug, Info, Warn, Error, Fatal)