I am on the first four hours of a twenty hour trip to Sydney, Australia for a short but informative speech at a business intelligence (BI) conference. This flight should give me plenty of time to catch up on my reading and writing.
Last month, I was sitting in on a business continuity educational session for the company where at some point during the session the speaker threw up a slide showing the business continuity management (BCM) maturity model. Now, most of us have heard of the capability maturity model for software (CMM or SW-CMM) application development. The CMM is a model for judging the maturity of the software processes of an organization and for identifying the key practices that are required to increase the maturity of these processes. The CMM is organized into five maturity levels: initial, repeatable, defined, managed and optimizing. Predictability, effectiveness and control of an organization's software processes are believed to improve as the organization moves up these five levels. While not rigorous, the empirical evidence to date supports this belief. The BCM model provides many of the same guidelines and benefits to the disaster recovery (DR) world.
Should meta data management have a maturity model? That would of course require the creation of a governance committee which might not be a bad idea. However, since this is a monthly column, please allow me a few moments to throw out a model that might provide some insight into the various levels of implementation.
Figure 1: Meta Data Management Maturity Model
This hypothetical model shown in Figure 1 is broken into three vertical sections. The first section describes the six different levels of maturity. The second section describes the program basics which will include senior management commitment, professional support and architecture governance. The third section describes the program development within meta data and should include extended participation from the business and IT, integrated planning and cross-functional utility.
Self- Governed Level
The self-governed organization will have a limited amount of program basics and program development components. This does not mean that they don’t have meta data. There is never a question whether or not an organization has or produces meta data, the question is do they manage the information effectively. In my past days with the AS/400, we did a very good job of managing the localized meta data, but I would classify us as a self- governing organization. Our focus did not move beyond the application and many of the meta data services were below the radar scope of the enterprise. We simply managed the meta data because it was the right thing to do.
Supported Self-Governed Level
Supported organizations will have some support from the senior management as well as someone who understands the value of meta data to the organization. This expert may be homegrown or a hired consultant. Organizations that have a knowledgeable meta data resource can find solid value by deploying those skills in the database organization, Web development group or the document management organization. If you don’t have a meta data expert within your organization then I would suggest you follow the advice of Woody from Toy Story:
Has everyone picked a meta data buddy?
What? A meta data buddy? You can't be serious.
Well, I didn't know we were supposed to have one already.
A meta data buddy. If you don't have one, get one!
Centrally Governed Level
On this level, central governance is the establishment by an enterprise meta data group. This group will require some level of commitment from senior management as well as the support from the architecture community. This support can simply be an acknowledgement from the different architecture segment teams of the importance of meta data or a fully functional meta data management segment team. The principles of meta data are universal and should fall under an architecture guidance model.
The ability to reach this level may be as much as result of the skills of the leadership within meta data. We have all units participating as well as senior level commitment. The architecture could either be full- blown data architecture or simply a meta data management segment team. There very well may be a huge role for marketing and branding required in order to get the level of involvement required. I can almost guarantee that if you reach this level you have done a solid sales job or someone has a heavy hammer on anyone not in compliance.
At this point, each and every project must address the meta data issue and there are no exceptions. Most organizations have no problem ensuring architecture, design, development, database design and many other areas are addressed within the software development cycle (SDLC). The meta data engine is running on all cylinders at this point; the only step that remains is an expansion into all of the functional areas.
Each and every possible function of meta data is addressed. From the database meta data to the Web page and XML tag management. Each and every dimension of meta data is managed at the enterprise level and support for a true corporate index of information, a virtual asset catalog of all the content within the enterprise.
Can nirvana be reached? Can the path to nirvana be attained one level at a time? Has anyone actually reached the synergistic level? On that last question, I think I can safely say that no one has. The main reason is that the scope of meta data is ever expanding. As soon as you think you have all angles covered, then boom another one pops up. The real value of this hypothetical model is to review the dimensions of meta data. If you take a look at those vertical elements you see some basic questions that all of us should ask about our project or group.
- Is the project supported, endorsed or promoted by senior executives?
- Do you have the necessary knowledge of meta data in your organization?
- Does your architecture support meta data management and to what extent?
- Is everyone participating?
- Is meta data addressed in the project planning cycle?
- Do you have all of the functional areas covered?
If nothing else, this model is certainly thought provoking. What changes would you make in the model? Can this model be adapted in a data warehouse implementation or is it just applicable at the enterprise level? Hmmm, maybe your organization can answer that question.
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