all bits considered data to information to knowledge

26Apr/130

Meditations on Nature of Data: the first three days :)

Meditating on John Wheeler's "It from Bit" insight I came up with what really could have been going on during first three days of Creation.... 🙂

 

1. In the beginning Information Architect created the database and the model.

2. Now the database was formless and empty, darkness was over the surface of the deep, and the Spirit of Backus-Naur was hovering over the databases.

3. And Architect said: "Let there be data", and there were data.

4. And Information Architect saw that the data were good, and he separated data from metadata.

5. Architect called the data "data," and the metadata he called "metadata." And there was evening, and there was morning - the first day.

6. And Information Architect said, "Let there be a vault between the data to separate datum from datum." And it was so.

7. So the Architect made the vault and separated the datum under the vault from the datum above it.

8. Architect called the vault "database schema." And there was evening, and there was morning - the second day...

9. And Information Architect said, "Let the data outside the schema be gathered to one place, and let storage appear." And it was so. 

10. Architect called the storage "data storage" and the gathered data he called "data logs". And Architect saw that it was good.

11. Then Information Architect said, "Let the data logs, and databases produce meaningful information according to their various kinds of context." And it was so.

12. The data combined with context produced information: databases bearing reports according to their kinds and data logs bearing reports in it according to their kinds. And Information Architect saw that it was good. 

13. And there was evening, and there was morning - the third day.

 

19Oct/110

Metaphorical modeling

I am a big proponent of modeling - data modeling, business process modeling, system modeling… Reducing complex systems and behaviors to the most important attributes for a given context facilitates better understanding, and helps to architect better solutions. Metaphor follows the same pattern - while not a full blown model, it highlights but a few features, magnifying them, and stripping of unnecessary details; by providing analogies in a different context it helps to break patterns of conventional thinking - often resulting in an innovative solution.

It had occurred to me that IT/Business uneasy symbiosis could be represented as a two-sided mirror erected at the border between the respective domains - IT and Business. Each looks at the other side convinced that “this is how they look!”… but each sees only reflection of its own.

NB: This is a variation of a proverbial “hammer and nail” metaphor: IT is looking for IT solutions for business problems (shelfware?), while Business is busy inventing business solution for IT woes (outsourcing, anyone?)

The domain of an Enterprise Architect (not to be confused with Enterprise IT Architect) spans entire enterprise, including both IT and Business; to offer a solution, an EA must have dual citizenship in both worlds.