Happiness and a Better Enterprise Software Data Model

futurelab default header

by: Sigurd Rinde

Funny thing, seems the human brain uses same tricks as Enterprise Software to save disk space 🙂

Thanks to Zia I found Daniel Kahneman at Ted’s site (go see):

Kahneman’s premise being "confusion between experience and memory: basically it’s between being happy in your life and being happy about your life or happy with your life”.

Expanding on that he uses an example "about a person who listens to 20 minutes of glorious symphony music yet at the very end there is a dreadful screeching sound. In reporting this incident the listener said that the screeching sound had ‘ruined the whole experience’. Still he had had the experience of 20 minutes of glorious music. But now that counted for nothing because he was left with a memory of the end; the memory was ruined, and the memory was all that he was left with."

That reminded me about data models for Enterprise Software: Save the "sales figures for March", forget, or even better, don’t even bother capture the total of raw data that could have been captured in the sales process.

It’s, like in Kahneman’s issue, an issue about direct or indirect representation of reality. The indirect in his meaning I would presume "memory", while the direct being the "experience". Or slightly different; (indirect, manipulated) "presentation" being "memory", (direct) "representation" being "experience".


[Objects, now use your own imagination and create the story…] 

Thanks to our paper based past we’re still sticking to "presentation" being used to "represent": Documents being the perfect example, any write-up represents multiple real world objects, and often with events all mashed together with a dollop of the writer’s own logic thrown in. In the days of handwritten scrolls it made sense to capture reality onto a form that could be used unaltered as a presentation. Ditto with double entry book keeping, decide at the point of capture what "it is", let a receipt "be" the "sale". Keeping the memory of the transaction and not the actual events with all it’s little details that comprises what one calls a "sale". Did the customer smile? No data about that in the receipt I’m afraid.

And it seeps through in all our ways and keeps those not present from seeing the reality as it was, re-experience it to allow for new views. The "data" we’re stuck with in Enterprise Software are "stories", already manipulated and far from reality, a "memory".

So this is what we must do, and Enterprise Software vendors, take note: Keep experience and memory apart as much as presentation and representation should be separates. See it for what it is, not what it presents. Add the colour and interpretation yourself, but for that you need the direct, "experiencing" data free of any previous manipulation. In practice one must capture all data, important or not is for somebody else to decide, by running all activities in process based systems, keep the raw data and apply logic only when in need of "presentation" (reports).

Yet again, the basis for all Enterprise Software must be process engines, unless "you’re there" you cannot "experience". But alas, most Enterprise Software are capture-tools and process free, or at best, DIY process.

If your argument is that such models would create too much data I would say: Raw data takes minimum space, manipulated and formatted data takes much more space. Add that my brain is limited to hat size 61 but there are no hat size issues in the cloud.

And the last nail; Kahnemann suggests "that we think about future not as anticipated experiences but anticipated memories." And that is how planning is in the Enterprise, based on extrapolation of manipulated data with little context visible. Enterprise Planning is based on the logic of whoever wrote the reports or chose what account to add an item. Not smart.

Original Post: http://blog.thingamy.com/sigs_blog/2010/03/happiness-and-a-better-enterprise-software-data-model.html