Related Links

Web Seminars

Over the past few weeks, I have been reading a rather interesting book called the Tipping Point by Malcolm Gladwell. He discussed at length a theory on crime prevention called the "Broken Window Syndrome." A cliff notes version of the theory is provided by Tom Asacker (2003).

In their groundbreaking article in The Atlantic called "Broken Windows: The police and neighborhood safety," Kelling and Wilson argued that rampant crime is the inevitable result of disorder. If a window in a building is broken and left unrepaired, people walking by will conclude that no one cares and that no one is in charge. One unrepaired window is an invitation to break more windows, and lawlessness spreads outward from buildings to streets to entire communities.

On the streets, "quality-of-life" crimes - panhandling, vagrants sleeping in doorways - serve as the equivalent of broken windows. In the subways, low-level crimes like fare-jumping act similarly as small but unmistakable signals that, left unchecked, invite further chaos. In such an environment, according to Kelling and Wilson, citizen complaints will often be met with excuses: the police are understaffed, the courts don't punish first-time offenders, etc. Soon, citizens stop calling the police, convinced they can't do anything. Or won't.

If we could all agree that one of the biggest problems facing our cities is the crime problem then this theory provides a different kind of solution. New York proved that crime can be addressed by focusing on these small and insignificant issues. In the data world, we have enormous problems that are seemingly insurmountable: integration, quality, reuse and interoperability. Many organizations attack the problem with strategic initiatives, stewardship programs and spending enormous amounts of capital on software and consultants. However, time and time again, these efforts only provide short-term relief to the long-term issues.

What does this have to do with meta data? I think we all can agree that meta data has long been the stepchild of the data architecture world. Rarely are the concepts and strategies of meta data placed on the front end of a project or better yet established as an enterprise program. Could it be because meta data is not as glamorous as business intelligence or a business communication device as the logical model? My stipulation is that meta data is the broken window of data management, data architecture and the myriad of data disciplines.

Let's take a Web example. Most Web developers spend 99 percent of their time working on content, layout, navigation, graphics and the myriad of other user interface components. Usability tests focus on the human/computer side of application while other tests focus on the business functionality of the application. Does anyone actually ensure that all images have alternative tags, that all pages have descriptive titles, that each page has a solid collection of meta tags or that terms used to build these components are constructed from a predefined vocabulary? Are these insignificant items or broken windows? I would argue that they are huge items that can allow the organization add quantifiable business benefits such as site positioning, site indexes, table of contents, soft link utility and search engine enablement such as meta cards. (Meta card is an HTML representation of a dynamic page or object that can be rendered in a browser. Think of a meta card as a card catalog of assets that only exist when the browser generates the view)

O.K., perhaps this is true in the Web world. How about the XML space? Currently, we are spending a tremendous amount of time on XML integration, XSLT capabilities, XML native database, transformation hardware, Web services and plenty more. I'll repeat my sermon from last year, all of this technology is great but what happens when we have a couple million XML files sitting around, buried within the business processes? Failure to address the meta data issues of vocabularies, naming conventions, standards, registration requirements, documentation and meta data interchange will lead us back where we currently are with a whole lot of stuff but no idea of what it is.

One of the compliments I get from time to time is how we have been able to raise the awareness and importance of meta data management within the organization as well as the architecture. In many ways, we created a meta data epidemic within the corporation. Either by blind luck or divine intervention, we have succeeded in building brand awareness of a core construct of information and a very valuable one, I might add.

Epidemics are a function of the people who transmit the infectious agents, the agent itself and the environment in which the agent is operating. When an epidemic tips, one or more of the following has changed: the law of the few, the stickiness factor and the power of context.

The law of the few describes the efforts of a few people that have the passion, energy, knowledge and communications skills to influence others on the principles and benefits of meta data. The people you choose to lead and operate your meta data program must have the ability express the mission and vision; this effort has no ending. Throughout the life of the program, people need to hear the message from a source that truly believes in the power and utility of meta data. In many ways, the leadership ability of these few determine the level of effectiveness your meta data strategy will have on the corporation. Leadership will determine the level of influence meta data will have in the corporation: a small insignificant project or an enterprise level program. The reality is that change requires leaders to lead, not follow, not manage, not accept mediocrity.