BLOG
FORRETNINGS-IT

Blog: En pragmatisk tilgang til MDM

De fleste mennesker er overbevist om at den centraliserede styremodel er den ideelle, men samtidig også den mest problematiske at implementere. Det er ikke nogen undskyldning for ikke at gøre noget!

Jeg har ofte haft lejlighed til at betragte projekter, som er løbet ind i alvorlige problemer med data – typisk på grund af forskelle i de forskellige kildesystemer. Kravet er at kunne identificere det samme objekt i forskellige systemer, og problemet kan dukke op i forskellige typer projekter, som Analytics/BI projekter, Big Data projekter, projekter der integrerer nye front-end systemer, projekter der skal konsolidere eller erstatte back-end systemer, osv.

Kort og godt: alle IT projekter.

Master Data Managements status i dag

Personligt har jeg kun hørt om meget få organisationer med succes på alle MDM fronter.

Organisationerne har tacklet Master Data Management på forskellig vis. Nogle organisationer trækker på deres eksisterende ressourcer for at håndtere MDM, som regel ved at lade nogle ansatte rense og migrere data manuelt. Denne metode lider under at være pivåben for menneskelige fejl, der forårsager yderligere komplikationer, og metoden er heller ikke nem at skalere når forretningsbehovet ændrer sig. Mange organisationer implementerer specifikke data management værktøjer til at hjælpe med integration og datavask. Men integrationsværktøjer kan ikke altid klare store datamængder og er også ofte begrænset i antallet af filtyper og datakilder, de kan håndtere.

En anden strategi er der anvendes, selv om den almindelige mening er at den giver dårlige resultater, er punkt-til-punkt integration, almindeligvis kaldt specialudvikling, hvor udviklerne skriver og implementerer specialkode i hvert enkelt end-point for at skabe konnektivitet. Men det kræver dyb viden om de enkelte end-points, og jo flere der er – og kommer – af dem, jo mere mareridtsagtig bliver opgaven. Og, efterhånden som organisationerne tager mobile, cloud og SaaS applikationer i brug til at bære forretningen, jo mere komplicerede bliver deres IT-økosystemer. Med flere og flere end-points, der skal forbindes, bliver punkt-til-punkt integration en kompleks og skrøbelig “spaghetti arkitektur”.

Hvorfor er MDM så vigtigt?

Når en organisation starter på rejsen fra det reaktive til det proaktive, skifter kravene til data fra den traditionelle hændelsesbaserede adfærdsanalyse til forudsigende analyse af kundeadfærd med tilhørende forskrifter til adækvate forretningssvar.

Dette kræver at data kan identificeres på tværs af alle systemer, både internt og eksternt.

Nogle organisationer benytter sig af et skift til “customer centricity” for at starte på Customer Data Integration (CDI), som er et specielt tilfælde af Master Data Management med kun et enkelt datadomæne, som kan hjælpe til at opnå et 360° customer view til at forøge væksten på toplinjen.

Andre organisationer forsøger at optimere værdikæden ved at fokusere på product master data management, for på denne måde at reducere omkostningerne og forbedre lønsomheden.

For de fleste firmaer skal disse aktiviteter gennemføres meget hurtigt, for at kunne konkurrere med nystartede virksomheder, der ikke er tynget af fysiske aktiver og andet arvegods, der skal afskrives.

Gartner Group’s model

Gartner Group opstiller en model med 4 forskellige ”styles” til MDM Hub-implementeringer:

  • Consolidation Style
    MDM Hub er referencesystemet til rapporteringsformål, der holder alle master data der ikke har brug for at kommunikere med back-end systemer.
  • Registry Style
    MDM Hub er referencesystemet, men lagrer kun et indeks, der bruges til at kalde det relevante back-end system for at få et komplet master data sæt.
  • Coexistence Style
    MDM Hub er referencesystemet og lagrer alle master data uden behov for at kalde back-end systemerne – et system til indgange opdaterer MDM Hub’en og den opdaterer i sin tur alle de andre back-end systemer.
  • Centralized Style
    MDM Hub er både referencesystemet og indgangsvejen – og opdaterer de nødvendige data alle back-end systemer.

De fleste, jeg har talt med, er overbevist om at Centralized Style er den ideelle løsning, men også den mest problematiske af implementere. Det er ingen undskyldning for ikke at gøre noget!

Hvordan skal det så gribes an?

Hvis du står med et enkelt, højt performende system til master data indgange for hvert data domæne, og hvis det system er et strategisk valg i firmaet – så er det en Registry style MDM Hub, jeg vil anbefale. Det er let at implementere, og du har ikke brug for avancerede datakvalitets­værktøjer til at hjælpe med datavask og -konsolidering på tværs af de forskellige systemer.

Men uheldigvis er hvis’et ovenfor sjældent opfyldt. I stedet for vil jeg foreslå en Centralized style MDM Hub – men vil forsøge at undgå at re-implementere hele systemlandskabet i et enkelt, stort projekt.

En simpel og bevist måde at gøre netop det på er at starte med at bygge en MDM Hub i Coexisting style og så efterhånden inkludere flere og flere back-end systemer med automatiseret synkronisering af master data på tværs af systemerne gradvist. Til en start kan du mappe master data helt manuelt, eller du kan bygge et lille mapping tool, der håndtere de oplagte tilfælde, og så lade de komplekse ting håndteres manuelt. Om nødvendigt kan du så supplere med et specialværktøj til datavask, hvis business casen for det har en positiv NPV.

MDM løsningen kan så gradvist forbedres til også at omfatte inkludere UI drevne MDM opgaver.

Hvis du bygger sin MDM løsning på en Staged Event-Driven Arkitektur (SEDA), kan du bygge sig en MDM løsning, der er robust, responsivt og fejltolerant, startende i det små med Coexisting style, gradvist vokse og forbedre, for så at ende op med en Centralized style MDM Hub. For så at gøre det simplere, kunne du så ikke undvære SEDA? – Jo, men hvis du blot bruger traditionel SOA eller EDA, mister du noget robusthed og fejltolerance. Mit råd er at bruge SEDA, fordi som jeg ser det, er MDM og hele mellemlagsarkitekturen vitale komponenter i enhver type forretning, uden undtagelse.

Med denne tilgang håndterer du problemerne et efter et i en prioriteret sekvens, og uden noget Big Bang. Det er faktisk en tilgang, der egner sig særlig godt til agile og DevOps, når der skal bygges en løsning med stor fleksibilitet.

MDM Hub’ens lager er en naturlig del af dit Business Data Lake eller datavarehus – det er faktisk sådan, at hvis du har et eksisterende datavarehus, så er der en høj chance for at de nødvendige lagringsstrukturer allerede er på plads. Spørgsmålet er om dit datavarehus kan håndtere det transaktionspres, som en nær realtids load som en MDM løsning genererer. Et moderne real-time datavarehus er i stand til at håndtere dette, ligesom en Business Data Lake kan det, men mere modne (læs: gammeldags) datavarehuse, der er designet til batchopdateringer, kan måske ikke opvise den nødvendige performance.

Og hvis du så ikke har nogen af disse strukturer til rådighed, anbefaler jeg at du benytter lejligheden til at starte på at bygge din egen Business Data Lake.

 

Erik Haahr
Erik Haahr
Managing Consultant
+45 52189364
Erik Haahr
Erik Haahr
Managing Consultant
+45 52189364
todo todo