PMIA webinar Dylan Jones and Experian

https://www.youtube.com/watch?v=nkyLg4Cigog
January, 2017

Dylan Jones (in England) is the founder of a couple of websites/companies.

https://www.dataqualitypro.com/
https://datamigrationpro.com/
Integrators can have a "get-out clause"

Lots of customers aren't experts in data migration.

"We're 2 years into a 6 month migration"
Each data migration is different.
And they don't happen all the time, so the knowledge is lost every time.
Create:
Function catalog
Function glossary
Doesn't usually take too long - a few days of workshops.

Can identify high-level gaps between sources and target, at the entity level, early, without going down to the detailed data profiling level.
This is in PRE-migration assessment.

"Broken" relationships between data entities, could be due to loose or manual connections between data in existing systems.
e.g. if there are some columns that are always null, do we really need them?
This is at about 22:00 in the video.

For the Migration Simulation, it doesn't cover all possible data.

He mentions looking at Primary Keys, and Foreign Keys, and maybe a few other core pieces of info.
See if those will work [reminder - this is in context of an Application data migration, not just moving a whole to a new platform]
If you have time after that, could go a bit further with more data

Artifacts:
Comprehensive data dictionary and metadata

Gaps and issues can lead to different resourcing requirements (different types of tools, etc)
Change in use is often a killer for data migrations.
Different functions or new usage of data in a new system, can cause problems if the data quality isn't good enough, for example.
Business Functions:
Might start with a list of "candidate" business functions (from original rough descriptions),
Which is then refined into the list of "actual" business functions.

Then identify the high-level Entities that support the Functions.

Often there will be some big gaps between the Entities that the legacy systems provide, and what the new system requires.
[this seems like you would basically need a full metadata management solution to do this properly, i.e. business glossary (defining the high-level entities), and
then do automated cataloging of all the technical details, and then a way of identifying which of the technical details rolls up to which high-level entities.
And the automation and management of the metadata, segues nicely into his next point, since he is obviously partnering with a software vendor…]
Automation - example, in one project they found data about Equipment in 27 different systems. They used a tool (presumably Experian) and did data discovery
and profiling in 1 day. Doing it manually would be much longer! You need a next-generation tool for data discovery and data profiling.

Have to prioritize as you build data quality rules.

Can't look at every field.
Core data elements.
Build some rules.
DQ Assessment checks how well the data follows those rules.
Filter out of scope:
Record level
Attribute level
Rules level - decide which DQ rules you can live without.
At 33:20 in the video
Identifying stakeholders for each function, is important

Even if you don't know exactly what the exact target system is, this is still useful. You will know the high-level functions and entities that are needed, so can still
discover many of the most critical gaps and issues.
He mentioned this will take "several weeks".