Can data be merely the servant of the software?

Blogger: Lyn Robison

Whenever a business needs to manage something, they usually need an information system or two to help them keep track of it. The IT professionals who implement these systems need to ask the businesspeople a fundamental question: do you need to know the quantity of this thing or the quality of this thing?

If the business is tracking 3/8 inch sheet metal screws, the answer is probably “quantity”. All sheet metal screws of the same grade, type, and class have the same attributes, so quantity is the primary considerations. When mere quantity is the consideration, you can get away with the data merely being the servant of the software. The IT people gather the software requirements, and off they go to build the system.

On the other hand, if the business is tracking customers, the answer is probably “quality”, meaning they want to track the qualities of each individual customer. Each customer is distinct and not interchangeable, and they each have unique attributes that must be tracked for business reasons. These attributes will need to be assembled from multiple information systems, which means that the data cannot be the servant of any one particular piece of software. So the IT people must gather information requirements, in place of or in addition to software requirements.

Building an information system that tracks quantity is very different from building an information system that tracks quality. If you are tracking quantity, you are no doubt tracking a fungible commodity, and your information can safely treat the data itself as a fungible commodity that can be easily aggregated. OTOH, if you are tracking quality, you must not treat the data as a fungible commodity. You must manage identities beyond the boundaries of any particular data silo.

Speaking of sheet metal screws, I was asked an interesting question by an astute reader of this blog. He asked, “let's use your 3/8 inch screws...the billions of 3/8 inch screws worldwide are certainly fungible, but if I put them in a blisterpack of twenty, give them a UPC and place them in inventory at a Home Hardware, are they non-fungible assets worth tracking, comparing, etc?”

My answer is, one blisterpack of screws is indeed the same as the one on the shelf next to it, but is different from the one in another store from a different supplier only if the screws are of a different grade, type, or class. For example, stainless steel 18-8 Phillips pan head sheet metal screws are all the same no matter the supplier, the retailer, or the packaging. Even then, all sheet metal screws are fungible (interchangeable) within their class. Likewise, one gallon of gasoline is the same as another, no matter what oil company it comes from. “Chevron with Techron” is an effort to differentiate the grade, type, or class. But one gallon of Chevron with Techron is the same as another gallon of Chevron with Techron, so Chevron gasoline is still fungible.

With fungible commodities, your IT systems only have to track the quantity within each grade, type, or class. With non-fungible assets, your IT systems must track identity, and must do so beyond the bounds of any particular application or data silo. This means that data cannot be the mere servant of a software package. With non-fungible assets, the software must bow to the needs of the data.

Comments

[Alex MM]

Interesting topic. Jan Farjh, VP of Ericson Research, writes in a recent essay about connection and connectivity in the next ten years (http://www.futureagenda.org/?cat=19). By 2020, he predicts around 50 billion devices worldwide connected to the interweb. The increase in availability of data and processing power will probably set the ground for efficient search of "quality" data.

[Software Testing Services]

Nice topic. I agree with your comments that data cannot be mere servant of the software package. The software system should me made such that it will do bend against data.