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 Figure 1): meta data tool evaluation and selection, and constructing the integration architecture document. Next month's column will cover creating detailed design documents and training development staff.
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 and Select. 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 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 (see December 2000 column).
Figure 1: Design Phase Tasks
Create Information 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 tool 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. The major sections of the information architecture document are:
Meta data integration architecture
Future meta data repository releases
- Critical success factors
- Risk factors
- Sign- off sheet
The meta data integration architecture section is the key portion of this document. It presents the technical meta data architecture along with detailed descriptions of the various sources of meta data and 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. They will use FTP (file transfer protocol) 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 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 and then the technical environment changes. Consequently, the tool is no longer as useful, and one begins to question why the specific tool was selected. This section clearly documents the process and reasoning behind the selection.
Future Meta Data Architecture. 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.
While this section does not have to include a detailed discussion of each projected meta data source, it is vital to highlight any anticipated changes to the current architecture. These changes may include moving from the current front end to a corporate portal concept or technically integrating new sources of meta data into the repository. This section is intended to keep the focus on the future of the repository and to reduce "throw-away" efforts. 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 to insure that the repository's architecture meets the architectural needs of the future releases.
The critical success factors, risk factors, issues and sign-off sections are familiar to most IT professionals, so I will skip these sections with the exception of one note. The sign-off section for this document differs somewhat from the project scope document sign-off. In this case, 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.
This column is adapted from my book Building and Managing the Meta Data Repository (Wiley, 2000). The complete project plan is available on the accompanying CD-ROM.
Register or login for access to this item and much more
All Information Management content is archived after seven days.
Community members receive:
- All recent and archived articles
- Conference offers and updates
- A full menu of enewsletter options
- Web seminars, white papers, ebooks
Already have an account? Log In
Don't have an account? Register for Free Unlimited Access