How do you or your organization use this solution?
Please share with us so that your peers can learn from your experiences.
We use DI for Data Governance as part of a large system migration supporting application refresh and multi-site consolidation. Metadata Manager is utilized to harvest metadata which is augmented with custom metadata properties identifying rules criteria which drive automated source to target mapping. Custom build code generation connector then automates forward engineering code generation groovy. We've developed a small number of connectors supporting this 1:1 data migration. It's a really good product that we've been able to make very good use of.
Our clients use it to understand where data resides, for data cataloging purposes. It is also used for metadata harvesting, for reverse engineering, and for scripting to build logic and to model data jobs. It's used in multiple ways and to solve different types of problems.
We have many use cases. We have a use case to understand our metadata, understand where it is, and understand where our authoritative data systems are. We need to understand the data systems that we have. We also need to link the data models that we have to these data systems so that we know which data models are supporting which database applications. We're also linking our business data models to our physical implementation so that our data governance team is driving our data and our understanding of our data. That is one use case for the Metadata Manager. Another is the creation of automated reports that will show the changes that are made in production after a production release. Our use cases for the Mapping Manager are around understanding where our data movement is happening and how our data is being transformed as it's moved. We want automated data lineage capabilities at the system database environment table and column levels, as well as automated impact analysis. If someone needs to make a change to a specific column in a specific database, what downstream applications or databases will be impacted? Who do we have to contact to tell that we're making changes? When thinking about the Mapping Manager, we do have another use case where we want to understand not only the data design of the mapping, but the actual implementations of the mapping. We want to understand, from a data design standpoint, the data lineage that's in the data model, as well as the data lineage in a source-to-target mapping document. But we also want to understand the as-implemented data lineage, which comes in our Informatica workflows and jobs. So we want to automatically ingest our Informatica jobs and create mapping documents from those jobs so that we have the as-designed data lineage, as well as the as-implemented data lineage. In addition, with regard to our data literacy, we want to understand our business terminology and the definitions of our business terms. That information drives not only our data modeling, but it drives our understanding of the data that is in our datastores, which are cataloged in the Metadata Manager. This further helps us to understand what we're mapping in our source-to-target mapping documents in the Mapping Manager. We want to associate our physical columns and our data model information with our business glossary. But taking that a step further, when you think about code sets, we also need to understand the data. So if we have a specific code set, we need to understand if we are going to see those specific codes in that database, or if we are going to see different codes that we have to map to the governed code set. That's where the Codeset Manager comes into play for us because we need to understand what our governed code sets are. And we need to understand and automatically be able to map our code sets to our business terminology, which is automatically linked to our physical tables and columns. And that automatically links the code set values or the crosswalks that were created when we have a data asset that does not have all of the conforming values that are in the governed code set. We also have reporting use cases. We create a lot of reports. We have reports to understand who the Data Intelligence Suite users are, when they last logged in, the work that they're doing, and for automatically assigning work from one person to another person. We also need automated reports that look at our mappings and help us understand where our gaps are, where we need a code set that we don't already have a governed code set for. And we're also creating data dictionary reports, because we want to understand very specific information about our data models, our datastores, and our business data models, as well as the delivery data models. We are currently using the * Resource Manager * Metadata Manager * Mapping Manager * Codeset Manager * Reference Data Manager * Business Glossary Manager.
This solution is still an experiment for us. My company is in the process of defining the data governance process, which is not settled right now. We have used erwin DG for the purpose of getting acquainted with data governance from a technical point of view. We want to see how it fits in our organization because data governance is neither IT nor a business matter. It is in-between. We have to put the proper organization in place in order for an IT solution to meet all the requirements. This has been in the works for almost two years now, where we have been formerly under an experiment with erwin DG. We are not fully using it as we would if it were in production running regular operations. What we have done with the tool is have a metamodel for our data and try to see how it fits with the requirements of our project, businesses, and IT. We have two cases that are fully documented under erwin DG. What we are trying to do right now is to integrate all our regulatory obligations, including laws and regulations at the French and European levels. This would enable us to make a bridge between the businesses and the law. This is a SaaS solution maintained by erwin.
We don't have all of the EDGE products. We are using the Data Intelligence Suite (DI). So, we don't have the enterprise architecture piece, but you can pick them up in a modular form as part of the EDGE Suite. The Data Intelligence Suite of the EDGE tool is very focused on asset management. You have a metadata manager that you can schedule to harvest all of your servers, cataloging information. So, it brings back the database, tables, columns and all of the information about it into a repository. It also has the ability to build ETL specs. With Mapping Manager, you then take your list of assets and connect them together as a Source-to-Target with the transformation rules that you can set up as reusable pieces in a library. The DBAs can use it for all different types of value-add from their side of the house. They have the ability to see particular aspects, such as RPII, and there are some neat reports which show that. They are able manage who can look at these different pieces of information. That's the physical side of the house, and they also have what they call data literacy, which is the data glossary side of the house. This is more business-facing. You can create directories that they call catalogs, and inside of those, you can build logical naming conventions to put definitions on. It all connects together. You can map the business understanding in your glossary back to your physical so you can see it both ways.
We're a medical company and we have our own source systems that process claims from multiple organizations or health plans. In our world, there are about 17 different health plans. Within each of those health plans, the membership, or the patients, have multiple lines of businesses, and the way our company is organized, we're in three different markets with up to 17 different IPAs (Independent Physician Associations). While that is a mouthful, because of data governance, and our having own data governance tool, we understand those are key concepts and that is our use case: so that everybody in our organization knows what we are talking about. Whether it is an institutional claim, a professional claim, Blue Cross or Blue Shield, health plan payer, group titles, names, etc., our case represents 18 different titles. For us, there was a massive number of concepts and we didn't have any centralized data dictionary of our data. Our company had grown over the course of 20 years. We went from one IPA and one health plan to where we are today: in five markets, doing three major lines of businesses, etc. The medical industry in general is about 20 years behind, technology-wise, in most cases; there are a lot of manual processes. Our test use case was to start from fresh after 20 years of experience and evolution and just start over. I was given the opportunity to build a data strategy, a three-year plan where we build a repository of all sources of truth data used in governance. We have our mapping, our design, our data linkage, principles, business rules, and data stewardship program. Three years later, here we are.
The three big areas that we use it for right now: metadata management as a whole, versioning of metadata, and metadata mappings and automation. We have started to adopt data profiling from this tool, but it is an ongoing process. I will be adding these capabilities to my team probably in Q1 of this year.
What do you like most about erwin Data Intelligence (DI) for Data Governance?
Thanks for sharing your thoughts with the community!