Implementing a metadata management strategy
A user opened up a can of worms when they asked a broad, open-ended question about metadata. It gave resident metadata expert Debbie Hamel a chance to flex her meta-muscles. Below is part one of Debbie's answer and there are links to the rest of the answer if you would like to learn more about metadata management.
We are working on the strategy for metadata management within the largest bank in Slovakia. The bank is absolutely new to metadata. Should we propose modeling tools (like ERWin, Rational Rose, etc.) and recommend a one year period for implementing the internal procedures for SW developers and DB architects, or should we go for full Repository (CA Repository, ASG Rochade, etc.)? There will be no more than 50 people approaching the Repository.
I t's wonderful to hear that the largest bank in Slovakia is working on a metadata management strategy. As an advisor, I wish I had several days to spend discussing this question with you and your organization to determine more specifically what your goals are and how they can best be achieved. Then, since strategy and its implementation are iterative processes, I wish I could discuss progress and issues every couple weeks during the project for adjustment and refinement. But, since this is just a brief Q&A, let's split this into the following areas:
- Metadata management strategy considerations
- Software products
- Challenges, issues & lessons learned
Part one of Debbie Hamel's reply follows:
1. METADATA MANAGEMENT STRATEGY CONSIDERATIONS
WHY: What brought you to the point that you are now moving ahead with metadata? Let's assume that like everyone else, your company wants to achieve its goals faster and more efficiently. Creating an understanding and centralizing core information and definitions will improve the coordination of processes, people and technology. But, there must be a clearly defined purpose and goal that has influenced the decision to improve your business and technical understanding of key information. Is it, for competitive intelligence because another bank is entering your territory, growing, and/or threatening your client base? Are you trying to create business critical web applications reusing as much information as possible? Another common reason for addressing metadata is in conjunction with a data warehouse. This might be for improved reporting to understand what products are selling in which regions and why. Perhaps the motivation is a horizontal opportunity of funds from an internal evangelist who has helped others understand metadata benefits? Whatever the reason it must be clearly defined, signed off on and supported throughout the organization in order for best success. Many consulting and product companies have template implementation plans that can help get you started.
WHAT: What are the primary goals of your metadata management strategy? Reduction of redundancy, reuse of fields, business and data elements for physical, logical and conceptual needs? Is it because new definitions keep forming and existing definitions keep changing as your business evolves? For example: Sales was defined in July 2000 as "dollars from products and services sold." But, now, in July 2001, accounting has come back and the new definition for Sales to be used in the corporate sense is "dollars collected into the company bank account from products and services sold." Put a stake in the ground on what sales means to the bank, conceptually, logically and physically and manage version and changes. This example aside, clearly define the goals, timelines, team.
WHO: Who is your audience? Usual users and beneficiaries of metadata are business analysts, software development architects and engineers. Will they incorporate your new rules, processes, products into their everyday steps? What are the skills of the team? How much training will be needed, can it be online, or must it be instructor led? And, how available and active will the SW developers and DB architects be? This is crucial to your success. Designers need to know what data they have, where they want it to be stored, how to move it, clean it, maintain it, and guide users to it.
WHEN: Are deadlines for deliverables defined? Are there phases? Will the right people be available to ensure they are met?
HOW: Remember building and implementing Metadata Management is an imperfect and ever-changing process. In general, tools speed up the work that needs to be conducted in an area significantly over time once you have absorbed the costs for the software, the implementation, the training and the maintenance. Good products like those you mention have been around for a number of years - you will find that with the repository products, there are as many success stories as there are people dissatisfied with the results. Make sure to figure out how this is impacting and fitting in to your company before and during your strategy design and rollout.
Continue on to Part 2: Software products - repository & analysis modeling and design
Debbie Hamel is a Principal for Discovery Logic. Ms. Hamel is a business leader who combines her information technology skills in knowledge management, metadata, data management and electronic business strategies with executive leadership, sales, marketing and international background. Ms. Hamel served as cofounder, member of the board, and EVP of XMLSolutions. Previously, She was VP of International Operations for PLATINUM technology.
What did you think of Ms. Hamel's advice? Email and tell us what you think.