This column is the third installment in a walk through of the key tasks in each of the five fundamental phases of a project plan to build a meta data repository: Orientation, Feasibility, Design, Construction, and Rollout. This month we will target the first two key deliverables of the Design phase (see Table 1): “Meta Data Tool Evaluation & Selection” (Table 1: Task 3.1) and the “Construct Integration Architecture Document” (Table 1: Task 3.2). We will cover the “Create Detailed Design Documents” and Train Development Staff” tasks (Tasks 3.3 and 3.4 respectively) in next month’s column.

Table 1: Design Phase Tasks

Design Phase

The purpose of the design phase is to document the specific processing and reporting requirements of the meta data repository project. The key deliverables in this phase are an evaluation of meta data tools, construction of the integration architecture document, and detailed program design specifications.

Evaluate & Select Meta Data Tools

One of the primary activities of the Design phase is evaluating and selecting appropriate meta data tools–both access and integration tools. Although all meta data tools have some drawbacks, I believe that such tools are beneficial for most meta data repository implementation projects and generally advise my larger clients (Global 2000) to purchase these tools and incorporate them in their meta data architecture. On the other hand, if the company is relatively small and/or has a limited IT budget, it may not be practical to purchase these tools, and then spend the necessary time and effort to learn to use them effectively. In these situations some companies may find it beneficial to manually integrate all of the meta data sources and build their own custom reports.

Create Meta Data Integration Architecture Document

The repository architect is responsible for creating the integration architecture document, which provides a detailed technical outline of the repository architecture. Because meta data tools play an important role in the repository architecture, this document should be created in concert with the tools evaluation. The major sections of the integration architecture document are nearly identical to those of the project scope document, with the exception of the first two sections. 

• Meta Data Integration Architecture
• Future Meta Data Repository Releases 
• Critical Success Factors 
• Risk Factors 
• Assumptions
• Issues
• Sign-off Sheet

Meta Data Integration Architecture Section

The meta data integration architecture section is the key portion of this document. Its presents the release one technical meta data architecture along with detailed descriptions of the various sources of meta data, how they will be technically integrated.

This section walks through each of the meta data sources and specifically explains what meta data is being brought into the repository, how the meta data will be integrated, and how often the meta data will be updated in the repository. Let’s use a custom data dictionary as an example. In the meta data integration architecture section, I would state: “the custom data dictionary contains business field definitions, that are embedded in a third-party packaged application which uses a non-open database structure and is located on an IBM mainframe. The meta data repository team will use COBOL (Common Business Oriented Language) and JCL (Job Control Language) to extract the data and FTP to transfer the information to the Windows NT directory where we will integrate it into the meta data repository.”

Any meta data tools that are being used will be presented in this section. With this presentation it is important to list out the strengths and shortcomings of the tool(s), and why the tool was chosen. This is done to officially document the reasons for the decision. All too often tools are selected, then the technical environment changes, then the tool is no longer as useful, and begin to question why a specific tool was selected. This clearly documents the process and reasoning behind the selection.

Future Meta Data Architecture Section

Because the first release of a meta data repository project does not usually implement all of the desired functionality, it is necessary to document the plan for handling the remaining requirements in future project releases. This section provides a picture of the future meta data repository.

This section does not have to include a detailed discussion of each projected meta data source, it is vital to highlight any anticipated future changes to the current architecture. These changes may include moving from the current front-end to a corporate portal concept, or to technically integrate new sources of meta data into the repository. This section is intended to keep the focus on the future of the repository in the forefront and to reduce as many “throw away” efforts as possible. Keep in mind that this intended architecture could change during the next release of the repository. However it is critical not to skip this step as it greatly helps to have these drivers captured here as they help to insure that the repository’s architecture built in release one has the architectural needs of the future releases in mind.

The critical success factors, risk factors, issues, and signoff sections are familiar to most IT professionals so I will skip these sections. The sign-off section for this document however, differs somewhat from the project scope document sign-off; here, the sign-off should be limited to the project champion, the project manager, and the repository architect.

Next month, we will complete the Design phase.