Portals eNewsletters Web Seminars dataWarehouse.com DM Review Magazine
DM Review | Covering Business Intelligence, Integration & Analytics
   Covering Business Intelligence, Integration & Analytics Advanced Search
advertisement

RESOURCE PORTALS
View all Portals

WEB SEMINARS
Scheduled Events

RESEARCH VAULT
White Paper Library
Research Papers

CAREERZONE
View Job Listings
Post a job

Advertisement

INFORMATION CENTER
DM Review Home
Newsletters
Current Magazine Issue
Magazine Archives
Online Columnists
Ask the Experts
Industry News
Search DM Review

GENERAL RESOURCES
Bookstore
Buyer's Guide
Glossary
Industry Events Calendar
Monthly Product Guides
Software Demo Lab
Vendor Listings

DM REVIEW
About Us
Press Releases
Awards
Advertising/Media Kit
Reprints
Magazine Subscriptions
Editorial Calendar
Contact Us
Customer Service

Knowledge: The Essence of Meta Data:
The Fourth Dimension of User Classification

online columnist R. Todd Stephens, Ph.D.     Column published in DMReview.com
January 20, 2005
 
  By R. Todd Stephens, Ph.D.

There are many ways to describe our users within the world of meta data. We can describe them by department (accounting, finance, billing), by job description (data steward, DBA, programmer, designer, architect) or type of user (business vs. technical). All of these user groups have been documented and discussed well beyond the point of getting any additional value from me. However, we can't say everyone is a customer of the repository collection since that would be a bit presumptuous. There is a process that happens in the online environment that we must understand. The repository must be designed to accommodate the various user groups described in the following paragraphs.

The Repository Browser

Browsers are people that come to the repository will no real purpose in mind. Maybe they came across the repository by searching the corporate intranet where your assets should be represented. Perhaps a co-worker told them of some interesting information that can be found at the site. Generally speaking, browsers might not know what they are looking for and will need some help in finding something useful. They also want to learn about the repository, business functionality, additional services and the assets that are described within. Ideally, we would have a single repository that held all of the assets within the corporation. However, due to the variety of meta-models and standards this doesn't seem like a reality any time soon.

The online environment presents another problem that is rather unique. Unlike books, newspapers and movies, the general user doesn't just open the media up at some random point and begin delving into the information. The Web not only allows for random access points, it also encourages this to happen. This means that a browser may enter into the repository not just on the home page but any page within the site itself. You will never know what link was added to someone's favorites or e-mailed to another employee. This requires you to focus on building a usable repository not just a storage container of information. The key here is a solid header with links back to the home page, contacts, documentation, asset type definitions and many other high-level directives. Ensure that you have a solid help system that educates the user on what exactly they are looking at. Remember, you can't assume any level of the knowledge or expertise in using Web technology. Provide multiple paths through the repository as well as cookie trails so the user can see how they got on the page and how to get back.

Example: Home > Customer Assets > Address Assets > Get_Home_Address

Your search utility should be able to search the entire intranet as well as isolate the search to the repository itself. And, a solid hierarchal structure that provides user supported drill downs into the asset collection is critical. This focus on usability is to help the browser feel comfortable and find value quickly. Unfortunately, the majority of the vendor products are not built for browsers or for anyone else that isn't highly experienced in service creation, database development or application architecture.

The Repository Seeker

With apologies to any Harry Potter fan, a seeker is someone that comes to the repository for information. This information could describe one of the assets within the collection or process definitions. Perhaps, they are seeking specific business functionality such as impact analysis or reuse analysis. Maybe they want to utilize one of the assets but don't know who to contact or what the process of engagement is for that asset type. A seeker will walk through a process of collecting information, analyzing the facts and determining what action needs to occur in order get to the next level. For this user type, repositories should be built with usability as a guide to gently direct the user toward engagement. Unlike the browser, you are trying to drive the seeker to become a producer or consumer of the products or services of the meta data services group. Information content is critical and writing for the Web is not the same as writing a white paper or online article. For example, suppose you're describing a data model asset which of the following would you prefer to see describing the asset?

Example 1: Simple Descriptions

  • Data model
  • Customer
  • 15 entities
  • 145 attributes
  • ERwin (download here)
  • Title: Customer data model
  • Keywords: customer, data, model, logical, physical

Example 2: Specific and Focused Descriptions

  • Logical and physical data model for the business customer
  • Customer subject area which includes name, address, phone, role, current sales
  • Key entity: name with 14 supporting entities
  • 145 attributes with the majority focusing on the name entity.
  • Logical and physical ERwin model, PDF printable version and repository links
  • Title: Primary business customer data model
  • Keywords: customer, logical model, physical model, name, address, (all entity names)

OK, not the best examples in the world but you get the idea. Provide information so that the user doesn't need to ask further questions. Provide the benefits and different delivery models. This information content should follow the concepts that Nielsen (1997) indicated:

  • Users do not read on the Web; instead they scan the pages, trying to pick out a few sentences or even parts of sentences to get the information they want .
  • Users do not like long, scrolling pages: they prefer the text to be short and to the point.
  • Users detest anything that seems like marketing fluff or overly hyped language ("marketese") and prefer factual information.

Other information elements that should be included for the seeker include: feedback forms, product comparisons, engagement processes and forms, templates and timelines that users can use to understand the meta data environment. While the browser came to the repository environment looking for information to increase awareness and interest, the seeker comes looking for defined value and research material to support their assumptions. Don't leave either user wanting!

The Repository Engager

The engagement user is similar to the buyer in the electronic commerce world. The engager wants to do business with the meta data group, and the repository better not stand in their way. They come to engage the organization as an asset producer or consumer. As a producer they are going to provide content for the repository. These folks provide your product inventory so be nice to them. The consumer wants to reuse a dimension of the asset (naming standard, component service, data definition, etc). Both of the users are important to your success they should be provided with a simple, elegant, graceful, beautiful and easy processes to follow in order to complete the business engagement. Those who have been in technology for a few years understand the difficulty to build something simple and usable. Many times we judge our success by demonstrating how complex and confusing meta data can be; and yes, it is very complicated. Ultimately, your success will be defined by how much content and usage the repository collection has, not by the level of complexity.

Simple business processes begins with simple forms and step-by-step instructions. Good form design isn't hard but here are a few key points:

  • Don't overload the user with 100 questions on a single page; perhaps 10-20 would be better.
  • Provide a step counter, such as Step 2 of 4 complete, at the top and bottom of the page.
  • Try to break the process down into logical information collections such as contact information, organization information and asset meta data.
  • Try to provide questions prepopulated with options which includes radio buttons, drop-down lists, multiple select lists and checkboxes.
  • Thank them on the final form and provide details of what happens next, how soon they should hear from you, who they should call if they have questions, etc.
  • Ideally, they should be able to save part of the form process and come back later (state information).

What part of the meta data process could be moved to the online environment? The complex answer is everything, but here are a few specific ideas: asset submission, subscriptions, reservations, utilization of the asset, metrics and communications.

The final user class is the repository customer which I will save for a later column. Sorry, this column is already up to four pages and that's way too much information. The first three user groups have enormous implications to the repository and meta data strategy. Does it matter that the browser is a DBA or the seeker is a data analyst? Some will say yes, but I am not so sure anymore. Perhaps conventional wisdom needs to be readdressed as we move toward new roles for the repository collection in a service-oriented environment.

 

...............................................................................

For more information on related topics visit the following related portals...
Metadata.

R. Todd Stephens, Ph.D. is the director of Meta Data Services Group for the BellSouth Corporation, located in Atlanta, Georgia. He has more than 20 years of experience in information technology and speaks around the world on meta data, data architecture and information technology. Stephens recently earned his Ph.D. in information systems and has more than 70 publications in the academic, professional and patent arena. You can reach him via e-mail at Todd@rtodd.com or to learn more visit http://www.rtodd.com/.



E-mail This Column E-Mail This Column
Printer Friendly Version Printer-Friendly Version
Related Content Related Content
Request Reprints Request Reprints
Advertisement
advertisement
Site Map Terms of Use Privacy Policy
SourceMedia (c) 2006 DM Review and SourceMedia, Inc. All rights reserved.
SourceMedia is an Investcorp company.
Use, duplication, or sale of this service, or data contained herein, is strictly prohibited.