The Confidence GameGiving your users access to "enhanced" metadata in strategic business apps can increase their confidence in making important decisionsBy Karen Kazimer-Shockley In his Nov. 27, 2000 article "Without Metadata, Content Is Just Bits," Fortune magazine columnist Stewart Alsop points out that, "Metadata (information about information) presents the biggest challenge the tech industry faces in delivering the ubiquitous networked future. Whether it's the seamless integration of data into your cell phone, downloading digital music at home, or getting your brokerage house to cooperate online, it doesn't work without metadata. As more corporate transactions are conducted over the Net, each needs metadata so that companies can track the transaction and analyze its success. It is the basis of accounting for the Digital Age."
Despite its importance, the term metadata is infamously overused and undervalued in business intelligence. To some people, it simply refers to the boring attributes of the database being created. To others, the meaning has been somewhat modified, to include characteristics of documents and their elements so that they may be more easily integrated or exchanged. Both these definitions are limited. Rather, by substantially expanding the meaning and the use of metadata as I'll describe here, you can provide extraordinary business value to your users. This expanded concept of metadata is particularly important in today's environment, where stovepipe systems often contribute data to an integrated system such as a data warehouse. The business rules and definitions in each of these systems can, and often will, be different, so in addition to creating a data mapping from the source system to the target, you must also determine, for each data element, what the source system of record must be. One way to determine if you're receiving the maximum ROI from your metadata is to ask the following questions: 1. Is your data complete? 2. Is it accurate? Do the same queries against different data sets produce the same results? 3. Do you get the data in a timely fashion? 4. Does your data support your specific business operations? 5. Is your metadata up to date? If the answer to any of these questions is "I don't know," then your metadata should be updated to provide more value for your investment. ORDINARY AND HIGH-VALUE METADATA"Ordinary" metadata includes several routine kinds of information about data, such as element name, data type, definition, and domain description. This data can be used by modelers, designers, developers, and software support personnel to obtain the correct data elements and understand requirements for transformation. Furthermore, giving users access to an enhanced form of this metadata — to "high-value" metadata, as it were — can be extremely helpful. Depending on their data sophistication, they can glean knowledge that can assist them in making better decisions. For example, many users will know that common data elements exist across several systems. If they've used these systems personally, they also may know the peculiarities regarding that system. System A, for example, may have strict edicts concerning the entries of dates, while System B may have no restrictions at all. If users know that the data for a date field came from System A, they can have relatively high confidence in its value. If it comes from System B, however, the data might be treated as suspect. Fortunately, new metadata standards such as XML specify ways that this information can be attached to data, so that sending and receiving programs are operating from a common understanding of the meanings of data elements. The question is, how do you transform ordinary metadata into high-value metadata? Basically, four elements are required: ordinary metadata, business rules, statistics, and a user interface. BUSINESS RULESAs usual, the first and most important step here is to get the users involved early. For example, in a recent data warehousing project, my team created a joint application development team comprising users and requirements analysts, with the odd developer thrown in for good measure, to determine the business rules and definitions that were applied to each and every data element in the data warehouse. This particular application integrated data from three systems: a demographic system containing all potential customers, a sales system containing information about actual customers, and a delivery system containing information about the services that were delivered. The demographic system was a nationwide database, the sales system was operated by region, and the delivery system comprised more than 200 sites across the country. The business rules captured the following:
For example, age was used in all three systems. In the demographic system, the birth date was used to calculate the potential customer's age at data entry. In the sales system, the age was calculated and updated on each date the customer ordered a product. In the delivery system, the age was calculated and updated at the time of the latest product delivery was stored. As we gathered the data warehouse requirements, it became important to know for which business questions this data would supply answers. For example, was it important to know the age of people as they first became eligible to be customers, and the age when they first received service? Or was it more important to know the ages of all current customers? Eventually, the users determined that they wanted to store both the birth date and the age a customer last received services. They also determined that the birth date would come from the delivery database. This decision was important because in the instance where the three systems carried different birth dates (which happens more often than we IT professionals would care to admit), the birth date stored would be consistent with the age of service delivery.
|
 |
Most Popular This Week
IE Weekly Newsletter
Subscribe to the newsletter
| |
|
|