For those less than more entrenched in the world of data management and governance, we should define what we mean by the term metadata, and there are actually couple of flavors. When we use the term metadata, literally this means data about data. It's used to help describe a company's information from a combination of technical, business, and operational perspectives. Now what we're referring to here are, any and all information about the actual data itself, that describes the nature or characteristics or meanings of the data that are not necessarily apparent just by looking at the data itself. These different types of metadata will usually be owned and managed by different organizational governance roles like those we discussed in organizational structure section. When combined, they will help make up the full understanding of our data and information. So this is looking at the typical types of metadata. Business metadata obviously is being looked at from a business perspective, business users application owners, executives, risk assessment organizations, and here we're defining business definitions around our content as well as the policies and rules of behavior around those. So in this case, we'd be looking at perhaps say a particular element, that may be a customer name, a customer address, and at the data level, it may be hard to discern. But from a business perspective, we give that a very specific business definition, and wherever that particular element exists, how many times in a given system or across different systems in the enterprise, we can connect that data element to an actual business definition and connect the policies and rules of behavior to that business definition such that we know how it should be treated, what the correct behaviors are for that data across the enterprise. Technical metadata is down at that lower level and of course is the domain and interest of the technical organization data storage, data engineers, application development personnel, modeling personnel, technical architects. Anyone in the organization responsible for building and developing and maintaining systems of records, and warehouses in integration designs. And of course the purpose here is to create that building block, that understanding at a detailed technical level. What data is in what systems, and this would include things like the classifications of that data in each of those stores, the actual data definitions themselves, so that the table definitions and the different attributes, the structural information, how perhaps any data is derived either within a given entity or a system or across systems and any dependencies and relationships between that information. Finally operational metadata is just that, it can be of interest to both business and technical roles within the organization, and most typically it's about the information, the processing flows, application data integration and this would include; all the details about that data movement across the organization including the frequency and record counts of movement. Making this information invisible both from the results and the statistics perspective across the organization. This is often what we refer to when we say lineage in terms of data governance and data management. To provide another example maybe more tangible in the context of this training, let's say we have a name in a database column. Looking purely at the data, we'd have no idea if this particular name is a customer name, a vendor name, an employee name? The technical metadata would provide some answers to this, maybe the data type, the different domains through which this data belongs, relationships of that data to the other, other entities within the data stores, schema details. Let's say now we link that particular piece of information to some business metadata to find a business term defined as customer name, and a classification at a business level of personal data and identifier, and it might be then used to associate to some other terms such as a relevant GDPR or personal data term. This gets me to the next levels of understanding of this information and helps me create transparency against all my data so that I can look at it from a variety of angles and investigate its meaning. Once I connect all of these business language terms to some of our organizational policies and rules, then I know, as well, what are the correct behaviors for handling and treating this information. I have a much more complete picture of what the data is, where it is, what it represents, and ideally how it should be treated and processed and secured within your organization. Upon examining the related processing integration flows that involve this data, I can also see how a particular piece of information moves perhaps from say some production environment into a non-production environment or one of our analysis zones, and in the process of that data movement, am I applying the policy prescribed correct masking or de-identifying techniques to that data. I now have auditable capability to go back to my compliance organizations and say yes, I understand the data, I understand the nature of the data, the sensitivity of the data, and I can show you how that data is processed throughout the organization and how it's being appropriately treated. All of this understanding connectedness is what eventually supports all the principles of privacy behaviors and auditability, and these all support what we mean when we say privacy by design.
