[Sigkm-l] Incremental approach?

[Mark Montgomery]

I believe that this list recently had a query on an incremental approach to
establishing an organizational knowledge system. The same question came up
in a different forum, so thought I would share an edited/ shorter version of
my post.

~~

Often is the case when I hear from organizations in hind sight that if they
had to do it over again, they would certainly not choose an incremental
approach to IT systems, because it (often) historically empowered and
rewarded behavior by vendors that directly conflicted with the future needs
of the customer.

So be very careful indeed with an incremental approach to anything IT
related (fully realizing that most budgets require it). I am quite confident
that you will find that an ounce of prevention is a ton of cure, and sooner
or later one will learn the value of an enterprise wide architecture.

Without going into detail on any single product, I would like to address a
more important issue for client organizations, and what they should be
concerned about- total cost of ownership over the long term.

Organizational functionality as it relates to networked information
technology, especially in the knowledge conversion and contribution process,
requires up front consideration of organization-wide issues, such as
interoperability across the org. and/or partners.

Regardless of size or budget, this should be conducted as an organizational
"audit", or complete review of the existing organizational and IT systems
and assets, with the end result being a plan to get from point A to point B
with point C-Z in mind. The worst possible thing one can do, and virtually
every organization did it historically because they had no other options at
the time, is to create unit by unit systems that one later finds to be
"legacy, proprietary, and incompatible" with other units in the
organization, important partners, or consolidation partners. A bit of
planning in advance can and has literally saved an org from financial ruin
later on.

Units of the (U.S.) federal Gov were for example still issuing unit-only
RFPs post 9/11 without considering whether or not they would be
interoperable with other essential units- a recipe for certain disaster, and
one that (the Gov) are working to overcome. Sadly some organizations in the
public and private sector have attempted to maintain independence by making
their systems incompatible.

If your organization lacks an enterprise wide IT architectural design and
the specs that go with, such as the DoD C41SR Architecture Framework, then
you at a very min. need to discuss with your org CIO (or whoever acts as the
CIO in the org) what your plans are with the individual products, and how
that will coincide with their long-term plans for the org.

Otherwise you could wind up with a volume of unstructured data containing
potentially very valuable (or in some cases life saving) information that
later on is found to be difficult or impossible for part (or all) of your
org. to access (such as when the decision is made to not upgrade the
software, switch, or the company dissolves).

Whenever possible, it's wise to choose products that either use or can be
converted easily to universal standards in both computer code and content
management. The good news is that most are at least moving in that direction
even if they have not yet fully arrived at the station.

>From the client perspective, the best software architectural design I could
create providing for an incremental approach, is one that provides
multi-component architecture- one stand alone component for each function
that is inexpensive on its own, but works with universal standards so that
it is interoperable with any other product, provided of course that this
product too adopts universal standards, otherwise integration is required
which can be very expensive.

To empower organizational learning on a continual basis (which should be the
goal), it will require far more than a single product. You want to be
certain that whatever products you start with will be able to evolve along
with the needs of the organization. Beyond that I feel that it's essential
to employ adaptable systems so that each organization has the opportunity to
build upon product and service differentiation, rather than be "dumbed down"
to the lowest common denominator.

Of course adoption of true universal standards and adaptability also means
that each component/product in a software company's arsenal must compete on
its own directly, rather than be bundled together in an inseparable lump,
and that is to date something that has been resisted at all costs by
significant portions of the software industry. .02

Mark Montgomery
Founder - KYield
http://www.mountaincomputertech.com

Managing Director - Initium Venture Capital
http://www.initiumcapital.com