thingamy

Information, Knowledge, Wisdom, and Innovation

These four concepts makes humanity move forward. They're basic requirements for every day work as well as for Big Important Decisions, hence nothing to take lightly. Indeed, if possible to grasp, sort, handle, and model efficiently we would all be better off. So lets have a closer look.

Where is the wisdom? Lost in the knowledge. Where is the knowledge? Lost in the information. — T. S. Elliot 

Well put, but it also has the kernel of something more, so let me rephrase that by turning the dependencies upside down (keep in mind that "objects" can be tangible or intangible):

Information = object facts
Knowledge = object relationships
Wisdom = object relationship patterns
Innovation = rearranging object relations

But do not for a moment be fooled by the philosophical whimsy, this touches, no, it is the very essence of any software system or management practice that purports to support the future of organisations.

Do it right and the results will be important, keep on doing it wrong and one shall become the 'lanterne rouge'.

Information: object facts

The car is blue, she's 167 cm tall. Object properties. Information.

Where we go wrong: Thanks to habits developed under old technologies we mix Presentation and Representation, mash logic and information, for the same object. Mostly into documents, forms and accounts, but also into the business objects of large Enterprise Systems.

How to better: Information should be Representation only. Take the information and add logic for Presentation separately when needed. Kill the notion of documents, forms and accounts. We are not limited to scrolls, quills and ledgers any more.

Knowledge: object relations

This we call a "coffee mug" and you have never seen such a thing: The "teacher" fills it with coffee (or tea or water), holds it by the handle in her hand and moves the rim to her mouth while tipping it. Voila you can now use the "coffee mug" with confidence to sip or drink the liquid of choice, you have the knowledge.
This is how children learn, this is how Plato defined knowledge.

Where we go wrong: The problem starts with the information as the "holders" of information keeps more than one object. A letter from the bank holds information about you, your house, the bank, the banks offices, your account and more.
Precisely relating a suitcase of different objects to another bag of other objects is not possible. Hence the knowledge is lost in the (bad format of) information.

How to better: One-to-one only. Single model objects representing single unique real world (tangible or intangible) objects only. Then relate these precisely in the model as they are in reality. That would lower model and system complexity tremendously as well. Reality has the lowest possible complexity. We create unnecessary complexity by using bad models.

Wisdom: object relationship patterns

Over time we (might) become wise for one simple reason: We accumulate knowledge and as humans we're inherently good at recognising patterns. First it takes the form of intuition or gut feeling (male term for intuition), then with luck, one is able to understand and approach the feeling with structured thoughts putting words to the reaction, understanding it, and wisdom emerges.

Where we go wrong: Recognising patterns require a clear view, and lowest possible complexity. But as we can see, most efforts to structure information and add knowledge has failed and thus messed up the path to wisdom. So we most often end up being wise in areas of less commercial importance and thus less structured. Typically life issues are were wisdom emerges, for sure important, but for the overall benefit of mankind it would have been nice if wisdom could be a part of our value-creation life too.

How to better: Fix the two first issues and the rest follows.

Innovation: object relation rearrangement

Why would we only listen to music in the living room or concert hall? Walkman ensued.

Where we go wrong: Yet again, mashed up objects equals irrelevant and rather useless relations leading to a less than clear material to work with and innovation suffers.

How to Better: Simple, as above; fix the two first issues and the rest follows.

Represent real world objects by unique and single objects, then relate these precisely, just like in reality.

Those changes alone will automagically rectify the issues and better models will ensue. And with truer and more direct models of reality we'll all be much better off on all levels - wisdom and innovation included.

Process Engine + Social Media -> Thingamy and ESME

For a long while I've been keeping an eye on the E 2.0, collaboration and social media efforts meant for enterprise use. I have to admit to being a sceptic, still viewing such as mainly single-task tools with little or no process and mostly lacking any way to add accountability and task ownership.

When discussing this with the large Enterprise Software vendors this has not been countered, quite the opposite, and promises of adding some 'process' to their E 2.0 / socmed efforts has been uttered.

In regards SAP's latest E 2.0 effort my fellow EI'er Dennis Moore suggests:

"SAP can distinguish 12Sprints.com by integrating it with business processes and enterprise data, including the Business Suite and Business Objects. This is an area few other collaboration tool providers are venturing into, and one where SAP has a natural advantage. If SAP does take this path, it is likely that 12Sprints.com can deliver real value to enterprises. This likely would result in new customers for SAP, new users within SAP's installed base, and greater customer satisfaction for SAP's existing customers."

To which I humbly disagree: SAP do not have any process engines (nor do any of the other big ones) for Barely Repeatable Processes, and this tool (12sprints) is for people centred processes that by definition are BRP. Hence SAP has no suitable process engine to integrate with.

But I do not think slapping some "process'ish stuff" on top of E 2.0 / socmed / collaboration tools would not cut it, that would be like putting the cart in front of the horse. Or at best elevating E 2.0 to Middleware 2.0.

Better, and I think the only way to go, is to have a core process engine and data architecture onto which the ad-hoc and mostly single task social media and collaboration tools could be added.

To put my money where my mouth is, we integrated some social media into our own BRP process framework in between the holiday parties and food frenzies.

ESME, aka Enterprise Social Messaging Experiment is now a part of the Apache Incubator program, developed and supported by a group springing out of the SAP mentor program.

Yes it's quite similar to Twitter, but it has features and abilities minted for the enterprise user - hence a perfect starting point for Thingamy.

Here's a conceptual description:

Thingamy's Work Processor runs the workflow without a glitch with path choices at most corners - punting a little "train" of relevant and inter-related objects (Workflow/issue/request/idea object - the main one + Assignment objects) through a workflow. The Assignment objects holds the task instructions and captures what's done in the assignment while the Workflow objects holds the details about the issue/idea/request.

That way an Assignee is presented with relevant objects, all the pertinent information required for a specific task + the Assignment object to fill in with result and files.

When having been assigned a task, or when trying to get one's head around the progress of a workflow there is always a need for ad-hoc communication with co-workers and/or other participants; "anybody know...?", "Could somebody help with...?" etc. Normally that would happen by email, phone or walking around - all of which limits the discovery of the unknown, like a co-worker having unknown but useful knowledge or ideas. And it would not add the very useful effect of "peer review" either.

ESME adds that crucial part of "Discovery & Discussion" that inevitably is needed during any process; in a task or when studying the progress. In addition it should become the natural in-system conduit for communication as well as the social pivot point, the water cooler, for the group/department/firm.

The crux being that the data in the two parts must be related - and that is implemented here; any ESME message can be related to any Thingamy object adding context to both sides - in the midst of a task, when studying the automatically generated reports or when scratching your head wondering "what's this discussion about?".

I don't know what next step, as in features, will be - our philosophy is to keep it as simple as possible in the beginning and only add if it makes huge sense and works in practice. So we'll see, the good thing is that both ESME and Thingamy are extremely nimble and doing crazy stunts underway shall be easy.

And here's a quick and dirty effort to demo the result within seven minutes :)

[Update - more discussions out there: Dennis at Zdnet, and David at Biztwozero.]