Organizations are driven by their mission and the underlying strategies to accomplish that mission. Organizations that fail to understand their mission and strategies will at best flounder and at worst fail. The outline in the following article will help an organization manage its metadata about itself (mission, strategies, etc.) as well as help an organization identify and document correlations between strategic-level objects and the assets (business, data, and information technology) required to accomplish them. Moreover, this article provides insights into the integration of these areas with an analysis of the business processes within the organization and how they relate to the organizational structure. Together, strategy, processes, data, and technology will ultimately allow an organization to achieve success.
Efficient operations are predicated on knowing what resources are available, where they are located, how to access them, and who is responsible for them. With that in mind, a metadata governance (MDG) tool is mandatory to manage the metadata about an organization. An MDG tool will allow an organization to build an inventory of its assets, regardless of the actual asset type. With the tool, an organization can define the types of resources it wants to inventory (e.g., system, database, API, database, files), the type of information to be retained about these resources, (e.g., name, size, location, ownership, growth patterns) as well as the relationships between the asset types (e.g., system uses database).
These tools do not replace existing document management systems but rather act as metadata repositories, tracking information about the assets while not storing the assets themselves. The MDG can be viewed as a data catalog somewhat akin to a library catalog system. In the library, a patron can look up a book by author, title, genre, etc.; similarly, in a data catalog, an analyst can look up datasets related to topic X or all systems that use field Y, but not actually have access to the content (or value of either), thereby protecting the data itself from unauthorized access.
By working with C-level managers to determine and document organizational mission, strategies, inhibitors, business processes, and structures in a complete and comprehensive manner, a picture of an organization can be developed. In conjunction with the “business” side of the organization, technologists document the systems, databases, and other technologies that are in place. Working with data owners and stewards to identify the data used within the organization, the meaning of the data, and the flows of the data between organizations and processes provides an understanding of the data and processes in place.
This approach integrates C-level strategic planning and enterprise architecture into a single methodology, ensuring the strategic plan can be supported by the enterprise architecture. The architecture planning methodology requires that the technology and other assets must be directly linked to the mission, strategy, and other planning objectives of the strategic plan. Each of the strategic objects, along with technology and business objects will be loaded into a specialized database for management and analysis.
Imagine the power of an organization that could cross-reference missions, strategies, inhibitors, technology, organizations, reports, and data to determine whether its financial and human resources are being deployed optimally. The ability to perform the necessary cross-referencing and act on the knowledge gained from the information exists, and this paper will show you how to get there.
Project Charter and Roll-Out
The initial step in any project of this type is to work with key organizational officials (champions) to identify and document what the project will accomplish and what it will not. Nothing dooms a project to failure faster than fuzzy goals and objectives.
Based on the project charter, the team should identify specific areas in which the tool and methodology will be piloted first, and then perform a slow roll-out throughout the remainder of the organization. The area could be a specific technology(ies), or organization(s) or functional areas. Best practices suggest performing a targeted roll-out across a narrow area and then broadening the scope into other areas as interest permits. By concentrating on a specific area, corrections and additions can be easily made without placing extra pressure on the organization as a whole. Once the underlying model, reports, and diagrams have been stabilized, a planned, controlled roll-out can be executed.
Asset Definition
The charter and roll-out plan will provide the implementers with guidance as to the types of information to be tracked within the MDG tool. At this point, the enterprise architects will work with the champion, managers, analysts, and users to determine the specific information to be gathered, or in other words, to be developed into an enterprise architecture. For instance:
- If building a common vocabulary is the
focus area, what information is to be retained about a business term? Most
likely, the organization is interested in the term’s name and definition. Other
characteristics to be considered are:
- Synonyms
- Acronym
- Owning organization
- If documenting technology is the focus
area, what information is to be retained about a system? Most likely, the
organization is interested in the system’s name and definition. Other characteristics
to be considered are:
- Links to databases and files
- Underlying technology
- Links to business processes being implemented
- Security level
Asset Ingestion
Once the items about which the metadata are gathered (previous step), it is necessary to determine how to ingest the data into the DG tool. Just as each asset type has its own characteristics and relationships, each will have its own ingestion method.
- Business terms, glossaries, and data dictionaries can be ingested manually or through an automatic form depending on how they are stored. One method is to use an OCR-based tool that will read PDF and Word documents and convert them into machine-readable format for ingestion into an MDG tool.
- Typically, technology assets (system, database, schema, table, column, etc.) can be ingested via an automated ETL method such as those made by Informatica, AWS, Microsoft, and Oracle.
- Policies, directives, and other guidance are often stored online within an organization, and therefore the contents will not be brought into the MDG tool — however, the metadata about the guidance will be brought in and therefore be able to be cross-referenced against other assets.
- Organizational data (organization tree, job descriptions, etc.) is typically paper-based and will have to be manually input into the tool in order to be referenceable.
The assets listed above will be cross-referenced (System USES database; Database CONTAINS Schema, etc.) to enable users to trace the interconnections between items. In addition to a mapping between technology assets, data governance tools can be used to cross-reference other assets to technology assets (Security Policy GOVERNS Database, Department MANAGES System, etc.) as well as between non-technology assets (Policy GOVERNS Organization, Directive DEFINES Business Term, etc.).
Check back in the next issue of TDAN for part two of this article, which will focus on asset analysis (lineage and provenance, data analysis, data value assessment, data quality, data usage) and data retrieval, shopping, and suggestions.
Image used under license from Shutterstock
