Placed on Main Street, inside of Walt Disney World, is a collection of hitching posts. What's so special about these posts? Every night these hitching posts are stripped down and repainted gold. The starting time of this process depends on the temperature and humidity, so that the paint will be dry for the crowd the following day. Why would an organization go to the time and effort for a task that no one is going to notice?

If you continue toward Cinderella's Castle, you will see a mural painted on the side of the wall. Cinderella and her evil stepsisters are reenacting the story that has been told for years and years. Yet, if you look close enough, you can see that each sister has a different color of blush; one has red and the other has green. Did they run out of paint or in this case, small colored tiles? The children's story does indicate that one of the sisters was green with envy while the other was red with rage. Again, why do this?

The reason is that Disney pays enormous attention to the smallest detail in the park. From the perfect placement of the trash cans to the emergence of characters from almost anywhere, Disney leaves no detail unturned. What are your hitching posts? What are those little things that your meta data services group (MSG) will be known for? What percentage of park attendees notices the repainted hitching posts or those small tiles of color in the painting? While not many of the guests do, you can bet the vast majority of cast members do. In fact, the small details are the foundation of the Disney lore. Once again we can grab a quote from Tom Peters on the importance of the small things: "If the airline tray table is broken, what must the engine look like?" This focus on the details establishes a culture where everyone remains attentive to the needs of the customer.

This month I wanted to discuss some of our hitching posts. These activities get very little commercial appeal and rarely noticed by the customer base. Yet, they are critical in communicating our commitment to the smallest detail.

Meta Data Quality

You would think that quality would be important to everyone, but in reality meta data is often overlooked as an important dimension of technology work. I challenge you to go to your local intranet and download 10 documents, PowerPoint presentations, spreadsheets or PDF files. Then check those properties; does the meta data match the content of the document? The odds are the answer will be no. In May, I embarrassed myself by checking my own presentation at the DAMA International Symposium and Wilshire Metadata Conference. As expected, my meta data was all wrong. I'll bet your thinking this is really not a big issue, right? Have you heard of the Senator's wife that got caught sending hate mail to a political rival because they found her name hidden in the meta data fields, or the organization that left "track changes" on after they posted the document on the Web. The modifications were published and painted a very dark cloud over this very large organization. Try opening a document with the file type set to "recover text from any file" selected, you might be surprised to see all of the hidden meta data that travels through out the organization. Having too much or too little meta data can be harmful to the organization. Having a group focused on ensuring meta data quality may soon be an imperative to conducting business.

A focus on quality seems like an obvious selection for a hitching post. Why doesn't every one try quality as a focused effort? The reality is that quality is very hard to implement because there are so many opportunities to drop the ball and missing a step or two can really be damaging to the integrity of the group. One of the items I mention in my seminars is the concept of how people associate quality with other items even though there is no connection. For example, if we develop a Web site that represents our group but the user interface is weak or the information hasn't been updated in six months then what does that say about meta data information held within the repository collection?

Usability and Design

Over the last five years, we have designed, built and implemented over 20 repositories. Some utilities survived while others faded out because of the lack of content and usage. However, the one thing I can say is that each and every one followed the basic rules of human computer interaction design. We always want to be sure the repository customer knows where they are, where to begin, the purpose and value of this repository and can locate information is a variety of ways. We try to ensure that each repository is consistent with the design style and philosophy of the organization.

Is usability an easy hitching post to implement? On the surface, it seems that we could read a few books and be on the road to success. And, believe me with every new group, scan, load, site, etc. that we do will conjure up someone that is a "do-it-yourself" usability expert. Everyone wants their own design and functionality to be implemented. The problem with that is we have 150,000 pages of content and making a small change creates enormous problems when scaled to these levels. In order for us to carry the staff size that we do, we must impose design restrictions. If everyone had their own design then we would need to increase our staff 40x which would not be a good idea during these financially challenging times.

Subject Matter Experts

In the 1980s, Nike ran a commercial series with Auburn's famed running back Bo Jackson. The tag line was "Bo Knows" and it was a huge success. But Bo doesn't know meta data, MSG knows meta data. We pride our selves in researching every dimension of the concept; from the data warehouse to the enterprise. We will walk though each presentation that the major data conferences publish, scan the ACM and IEEE sites looking for academic research, read as much online material as possible and be willing to try new things that have no guarantee of success.

Of the three things mentioned, this one is the hardest to accomplish over the long term. There is always someone in the organization that wants to let you know how much they know about data architecture, meta data, reuse, metrics, etc. This is not all bad and I liken this to a poker game. You just went "all in" - indicated what you have, but you haven't seen our hand yet. One particular time, a vendor was brought in for a meta data-type project and I happened to be in the room. They went through their three-hour discussion on the merits of meta data and the basic principles of service. After a couple of questions, I hit them hard with my usual direct questions:

  1. Does your product come with the metamodel already scanned in?
  2. Do you provide sample data for testing/learning the scanning process?
  3. How do you define partner?
  4. Do you import and export XML? How? By what standards?
  5. Do you provide standards compliance? Which ones?

They were not really prepared to answer these questions. However, the real issue was they tried the sales shuffle, which is really just talking fast with as many words as possible. Something like:
"We support extensible markup language that encompasses relational and object database schemata, and even XML schemata, provide documentation, guidance and control for data-driven applications. We also include RDF schemata, which are looser and more generic; they set forth our classification of the resources that we put into the RDF models. In this release or the next, we'll look at schema for the issue tracker RDF statements, using both the W3C RDF schema (RDFS) specification and the DARPA Agent Markup Language/Ontology Inference Language (DAML+OIL), which is an important extension of, and improvement on, the W3C specification. Some familiarity with RDFS and DAML+OIL is preferred from the customer point of view."

Hmmmm yea, was that a yes? O.K., that was a little fictitious but I am sure all of us have seen the sales shuffle in the past. The point of this is that you need to spend time researching meta data and continue this process for the life of the program. Everyone up the organization chart expects that of you and you will have plenty of opportunities to demonstrate your knowledge base.

Excellence is never a random event; it must be planned and executed with passion. The hitching post is a simple analogy that we use to increase our focus on the customer and value delivered to the organization. Excellence is not cheap, a certain price must be paid in terms of time, commitment, execution and persistence. My favorite story of excellence is as follows:

In the late 17th century, three rural families dominated the musical instrument industry. Working in shops located side by side in the Italian village of Cremona, these families produced the finest violins. The Amatic family hung a sign outside their shop that read, "The best violins in all of Italy." Not wanting their creations to go unnoticed, the Guarneri family posted a sign that read, "The best violins in all of the world." The famous Anton Stradivari, known to produce the finest, most expensive stringed instruments, boasted his worldwide renown by hanging a sign on his front door that simply read, "The best violins on the block!" The greatest enemy of excellence is "good enough."

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

Don't have an account? Register for Free Unlimited Access