Hi Folks,
First, I hold the following three statements as axioms. (Axiom: a statement or proposition which is regarded as being established, accepted, or self-evidently true).
Axiom #1: Data is the most important, most valuable part of an application or system.
Axiom #2: Applications or systems should be designed first and foremost with a focus on identifying the data, structuring the data, and specifying the data.
Axiom #3: Applications or systems that are designed per axioms 1 and 2 (i.e., in a data-centric fashion) stand a good chance of being well designed. Conversely, applications or systems
that are not designed per axioms 1 and 2 are almost certainly poorly designed and are likely to have problems surviving in today’s highly interconnected ecosystem.
Next, here are telltale signs that an application or system has violated the axioms.
10 telltale signs that an application or system was created with data, structuring the data, and specifying the data as an afterthought
-
When you ask the owners or developers of the application or system a question about the data (e.g., is the binary data in little or big endian form?) they respond with source code (“look through this source code, the answer to your question must be in there
somewhere”), or, they respond with, “Looking at the data from Wireshark after processing by the Network Interface Card, the answer to your question is ...”
-
When you ask for sample data files or test data files they respond with “Sorry, we don’t have any.”
-
The documentation on the data was written after development of the application or system was completed.
-
The documentation on the data was not written by senior-level architects and developers; rather, it was written by tech editors or entry-level engineers.
-
The documentation on the data is incomplete. For example, the documentation says that the data contains a data item foo of type fooType, but nowhere does the documentation define fooType.
-
The documentation on the data is incorrect and/or out-of-date. For example, when inquiring about fooType, they respond, “Oh, we didn’t implement foo or fooType, we forgot to update our documentation.”
-
The description of the data items is vague and imprecise.
-
There is no thought about data interoperability – no thought on how to convert the data into other forms for interoperating with other applications or systems. For example, if the data is formatted as XML, there are no XSLT programs for transforming the data.
-
When you ask for their data specification you get a blank stare and this reply: “What’s that?”
-
When asked about the data, they tell you, “We store our data in a database” and then they proceed to tell you about the virtues of the latest whiz-bang database technology they are using to internally store their data.
Is there anything you would add to this list?
/Roger
