Registry
Figure 1 provides a simple chart describing the evolution of the knowledge store we commonly refer to as a repository. In most cases, I use the word "repository" to mean any application within the metadata space. Repository is a generic term to describe any knowledge container. As Figure 1 indicates, the registry focuses on structured information. Hence, the first repositories were registries because they only contained the information that could be placed in tables and rows.
Figure 1: Natural Progression of the Repository
Structured information may include elements such as name, keywords, description, owner, modified date or version number. The key is that all of this type of information can be easily laid out in a database. One of the most popular registries is the Web Service Registry that operates over the Universal Description, Discovery and Integration (UDDI) standard. For anyone that has reviewed the UDDI standard, you will know that the base metamodel only looks at structured information.
Repository
Eventually, organizations realized that structured information only held a small percentage of knowledge within the corporation. In order to transform a registry to a repository, you only need to add the ability to manage the unstructured information along with the structured data. This may indicate a full content management system or link to the appropriate documentation.
Suppose we have that Web Service Registry described in the previous section. What unstructured information could be added to increase the contextual knowledge of the Web service? How about service level agreements, configuration instructions, UML diagrams, XML structure models or even the business process models? All of this information would be critical to the individual accessing the repository for information and trying to understand the role and value of utilizing the service.
Both the traditional repository and registry can be defined as passive knowledge stores. While I have defended passive repositories for years, active utility is the next stage of value creation. In order to transform the repository into an active application, you need to add automated business and application processes. Business processes include functions such as automated scanning, asset submission, asset consumption, versioning and subscription services. These automate the business functions of the metadata organization. Application automation focuses on the utilization of the actual repository information such as metrics, impact analysis and personalization. These services transform the passive repository into an active one. Most implementations and vendor products have ascended to this third level.
Collaborative Environments
Before moving into Metadata 2.0, I wanted to reflect on another dimension of the transformation we are seeing in the world of metadata related to communication. Traditionally, metadata repositories are built for the data warehouse environment, which creates an environment where only a few people control the inflow of information. Contrary to lofty expectations, the majority of repository users fall short of expectations. When we have a knowledge store where the information is controlled by a few and utilized by a few, then we have created a channel communication.
Ideally, the repository would be utilized by the masses within the organization, which would indicate that we have a communication platform. The harsh truth is that getting metadata information for the business end user is a huge challenge. Take a simple example of a logical model. How many average business users are going to be able to understand "crow's foot" notation?
Therefore, a repository built so that a few people can communicate with a few people is called a channel, and one built so that a few people can communicate with many is called a platform. How about one built in such a way that many people can contribute and many people can use it? Hence, the definition of Metadata 2.0.
Metadata 2.0 is taking the repository to the collaborative stage, as seen at the bottom of Figure 1. Does this mean that all metadata is open for update by anyone in the organization? Maybe one day, but I would start by allowing people to test drive the collaboration components first. Consider the typical repository and think about what collaborative-type functions you could add on top of the controlled metadata. How about these:
- Discussions or Weblogs around data domains;
- RSS feeds for notifications of changes to the environment;
- Collaborative lists for data steward contact information;
- Wiki-based data definitions;
- Self-publishing documentation;
- Virtual communities of practice; and
- Online meetings for content discussions.
Each of these components keeps the traditional command and control model in place. Eventually, you will need to open up the repository to not only universal access but also universal update. Metadata 2.0 describes how Web 2.0 advancements could and should be implemented into the knowledge environment. Success is moving away from the structured and unstructured to a conversation of value. Like Web 2.0, Metadata 2.0 is characterized by open communication, decentralized authorship, freedom to share information and a market for the conversation itself.
The success of Metadata 1.0 revolved around many concepts, including data quality, data stewardship, data architecture, solid metadata applications and business processing. Mathematically, we can write this equation as:
Metadata 1.0 = DQ + DS + DA + MA + BP
In Metadata 2.0, this equation is simply the price of entry. Every metadata environment will be expected to deliver this functionality and value to the business. People, trust and participation will need to be added, and the most critical of these is the participatory collaboration that will be required between the asset producers and asset consumers.
Be the first to comment on this post using the section below.