Cory et al: This is a follow on to my earlier posting to this list that
encouraged a more balanced approach; not focusing so heavily on "technologies"
but acknowledging the need for human (domain expert) involvement, and of
course appropriate incentives to secure their involvement over the extended
lifetime of any ontology. (01)
I'll base these comments on this quote from your paper:
The typical architecture is a paper document produced as part of a project by
a contractor. These architectures tend to be re-invented in each project with
little concern for evolution or an enterprise view. There is no mechanism for
evolving the architectures over the life-cycle of the business processes, data
stores and systems they are supposed to specify. Where processes and systems
live for decades, it is intolerable for their architectures to be transient. (02)
It seems to me the causes of the "ontology problem" start exactly here. The
DOD procurement process (except for COTS) is a pay to build approach, which
means govt bears all the risk and builders (contractors) participate for
strictly defined rewards; cost + fixed fee typically. The typical architecture
is indeed produced by contractors, whereupon the contractor departs elsewhere.
Job done. Same pattern repeats indefinitely throughout the program's life
cycle as contractors come and go. Heavy costs at each stage as newcomers
absorb (or ignore) the prior contractor's ontology and worldview. The product
is not encapsulated. Its complexity is entirely exposed right down to the
silicon. (03)
Govt has many such systems and pressure to make them interoperate. This task
is borne by govt because the contractors who built them long ago departed
elsewhere. Changing the systems to make them interoperate is not an option
because the people who built them are no longer available. The only option is
to change them externally by building adaptors, ideally aided by the high-tech
"ontology technology" like this group is focused on. This, I assert, is a very
expensive problem (N^2) if it is even possible at all, and certainly
impossible without well-motivated people to drive the tools. (04)
I suggest that this group should seriously consider alternatives to expecting
technology to solve this while leaving the root causes (outlined in the above
quotation) unexamined. Consider this as one alternative: (05)
1: Goverment publishes a capability case analysis defining what new
capabilities it needs. (06)
2: Providers respond by submitting bids, but these are not for the price to
*build* such a system, but on the price for each capability transaction
actually delivered to end users, based on metrics captured within the SOA
infrastructure. Pay per use, not pay to build. Development cost/risk borne
entirely by provider, not by government. Upside rewards not capped, so very
high rewards are possible if system is heavily used. Total loss likely if the
system isn't used, or if a competitor delivers an alternative thats more
popular. (07)
Notice that the architecture -> designer -> implementor -> internal test
handoffs completely disappear. Enterprise architects don't build top level
designs as today, but focus on building codes; the standards that providers
must comply with to be considered. (08)
And so forth. Its not as radical as it might seem; its modeled after the
approach that real city planners, architects, interior designers and
construction crews use, just adpated to IT. (09)
--
Work: Brad Cox, Ph.D; Binary Group; Mail bcox@xxxxxxxxxxxxxxx
Home: 703 361 4751; Chat brdjcx@aim; Web http://virtualschool.edu (010)
---------- Original Message -----------
From: "Cory Casanave" <cbc@xxxxxxxxxxxxxxxxxxxxxxx>
To: "'common upper ontology working group'" <cuo-wg@xxxxxxxxxxxxxx>
Sent: Thu, 16 Nov 2006 08:41:40 -0500
Subject: [cuo-wg] White Paper (011)
> James,
> You asked for some input on a white paper outlining the requirements.
> Perhaps an organization for that paper would be a very high level statement
> of the requirement with some specific examples and links to more information
> on those specific examples. We could also have a VERY high level discussion
> on the KIND OF solution and links to more information for candidates.
> Enclosed is some work we started in relation to the FEA and netcenticity
> that may be a start for one such requirement set. We would be interested in
> working with others to develop this further.
> Regards,
> Cory Casanave
------- End of Original Message ------- (012)
_________________________________________________________________
Message Archives: http://colab.cim3.net/forum/cuo-wg/
Subscribe/Unsubscribe/Config: http://colab.cim3.net/mailman/listinfo/cuo-wg/
To Post: mailto:cuo-wg@xxxxxxxxxxxxxx
Community Portal: http://colab.cim3.net/
Shared Files: http://colab.cim3.net/file/work/SICoP/cuo-wg/
Community Wiki:
http://colab.cim3.net/cgi-bin/wiki.pl?SICoP/CommonUpperOntologyWG (013)
|