Only 1 message in topic - view as tree
This post summarises for me Daves approach and thinking on this topic, the whole idea of enabling conditions can be taken much further.
From: act...@yahoogroups.com [mailto:act...@yahoogroups.com] On Behalf Of
Sent: Wednesday, 12 October 2005 9:01 PM
Subject: [act-km] The technology question: Demand, Supply or Co-evolution
Maybe it would be helpful to think about enabling conditions rather than
drivers and about a different view of the traditional concepts of supply and
demand. My own work on strategy (and on the development of related software
tools) is increasingly making a distinction in scenario planning between
causal events and enabling events. The normal de facto position is to
create a string of events on the assumption that early events caused the
following event, in practice it is often the case that a certain event made
many other events possible, but the one that happened is then assumed to be
"caused". It's a western concept, this desire to see a reason for things,
most eastern philosophies have the concept of a non-causal system in which
some things just "are" which ironically
If we look at the development of KM in the mid and late nineties then I
think it is true to say that one of the enabling events was the growth of
collaborative technologies. Lotus Notes took the early lead in this and was
(and is) to my mind one of the outstanding collaborative tools.
Unfortunately whoever became responsible for its strategy focused on
competing with Microsoft as an e-mail package, rather than making the case
for "many to many" rather than "one to one" communication. As a result
Notes development and sales/marketing strategy suffered accordingly and of
recent years its decline is becoming self evident. E-mail is now the
antithesis of a productivity tool. The internet itself as active business
tool is to all intents and purposes less than ten years old and anyone with
any knowledge of history will know that you cannot assume that things will
carry on "as is": scalability is not infinitely extendible, things change
and can often change very quickly.
That leads me to the main point. Technology creates the possibilities for
things that we have not thought of before. The earliest ever commercial
computer was used to store the telephone directory of an American city (IBM
1954 and IBM announced a world market for 6 computers), we then moved over
the next 40 years into a DEMAND led use of technology in which existing
manual systems were computerized. The methods of system design and project
management grew out of this period of known need and we have been suffering
from that history in recent times in that such approaches slow down
development when the need is not fully known. In the eighties we started to
move into the SUPPLY period, in which technology capability led market need.
In this period it is fair to say that technology was a "driver" of KM
programmes. The dot com bust was one of the more significant indicators
(but not the only one) of the end of this period.
We are now in a CO-EVOLUTIONARY period in which business needs and
technology capability are interacting in ways that we do not fully
understand, but new applications are emerging from that evolutionary
interaction. One of the consequences of this which is little understood is
that we need to stop designing "applications" in which users say what they
want and technologists build to order, or for that matter buying standard
packages (ERP) and changing human systems to conform. We need to really
pick up something that was surfacing back in the 80's namely object
orientation. Here you design objects that receive and distribute services
and can be controlled by workflow (yes I know this is a crude statement but
it is the essence); the application then emerges from the interaction of
people and business needs with those objects.
It's a very different design strategy, and its one of the reasons why many
of us are interested in complexity science as it gives a theoretical base to
understand what is going on. One of the problems is that IT design
processes are still locked in the demand and/or supply periods. Since
leaving IBM a part of my work has been to create a new software company,
building tools based on my and colleagues ideas. It is object orientated,
but I have to stay constantly alert to developers who want me to provide
"use cases" so that they can build applications, not objects. The idea that
you start to provide general purpose software objects evolve in use is alien
to a generation trained on the inadequacies of the early days of computing.
Its also given rise to this terrible dichotomy in KM between "technology"
and "culture" when in practice the two are intertwined. In a recent book
chapter in the context of narrative Gary and I called these two extremes the
Techno-fabulists and the Art-Luddites. Those familiar with my more strident
views on the conference stage will recognize the techno-fetishists and new
age fluffy bunnies in a more academic disguise.
The Cynefin Centre
mobile: +44 7795 437293