When you have a large amount of data to sift through, it is often good to create an ironclad framework to manage the data. This framework will include a method of inputting new data, modules for importing and cataloging old data, and an interface to wrap around the whole thing. Collectively, it is called a system.
The problem with systems it they are often created to manage a dataset that is expanding rapidly now, but will taper off quite soon. The designer of the system assumes that the expansion will continue at its present rate, so he creates the system to manage a large amount of data and he designs a thorough catalog to expedite searching. The problem is that with more items, more cataloging effort must be spent on each item so that searches can drill down the necessary data over an ever-expanding dataset. This means the cost of maintaining the system increases exponentially. If the expansion rate drops rapidly, this can be the nail in the system’s coffin, as fourteen layers of metadata provides diminishing returns when you are adding three records a day.
When you picture a “system,” think of a photography catalog. You add more photos as you take them with your camera, importing them using a memory card reader. You add tags and keywords. You sort the images into folders or (preferably) virtual folders. There is a search mechanism which lets you search by folder, date, and keyword. You can search thorough a mass of metadata that is generated by your camera automatically upon shooting each photo. If any one of these components is flawed, the whole system crumbles. Being able to find a photo in two seconds is worthless if you have to spend five minutes cataloging each one. Having a stable catalog of photos sorted …
