Brad,
We have been thinking along similar lines but I submit the government has to
own their architectures, only they have the cross-cutting view (or should
have). Contractors can help build these, but the architecture asset (as the
expression of the enterprise, enterprise needs and solutions - business or
technical) has to be put into the acquisition cycle. Systems then need to
be built to that architecture is an executable, testable way. Those
architectures have to STOP being "for a system" and be "for the enterprise".
SOA makes a great model for these architectures - separating concerns and
providing the boundaries to build to. The semantic technologies can help
here to join and bridge architectures, but you are absolutely correct that
the core problem is not technical.
-Cory (01)
-----Original Message-----
From: cuo-wg-bounces@xxxxxxxxxxxxxx [mailto:cuo-wg-bounces@xxxxxxxxxxxxxx]
On Behalf Of Brad Cox, Ph.D.
Sent: Thursday, November 16, 2006 10:00 AM
To: common upper ontology working group
Subject: Re: [cuo-wg] White Paper (02)
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. (03)
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. (04)
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. (05)
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. (06)
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: (07)
1: Goverment publishes a capability case analysis defining what new
capabilities it needs. (08)
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. (09)
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. (010)
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. (011)
--
Work: Brad Cox, Ph.D; Binary Group; Mail bcox@xxxxxxxxxxxxxxx
Home: 703 361 4751; Chat brdjcx@aim; Web http://virtualschool.edu (012)
---------- 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 (013)
> 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 ------- (014)
_________________________________________________________________
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 (015)
_________________________________________________________________
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 (016)
|