> 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. (01)
Agree govt needs to own the architecture. But what needs to go into the
acquisition cycle isn't the architectures but executable test cases derived
from it as Springfield armory inspection gauges were derived from govt specs.
If lock and stock pass the gauge, they'd considered to match the spec. I.e.
interchangeable parts, today renamed interoperable. (02)
--
Work: Brad Cox, Ph.D; Binary Group; Mail bcox@xxxxxxxxxxxxxxx
Home: 703 361 4751; Chat brdjcx@aim; Web http://virtualschool.edu (03)
---------- Original Message -----------
From: "Cory Casanave" <cbc@xxxxxxxxxxxxxxxxxxxxxxx>
To: <bcox@xxxxxxxxxxxxxxx>, "'common upper ontology working group'"
<cuo-wg@xxxxxxxxxxxxxx>
Sent: Thu, 16 Nov 2006 11:21:10 -0500
Subject: RE: [cuo-wg] White Paper (04)
> 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
>
> -----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
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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:
>
> 1: Goverment publishes a capability case analysis defining what new
> capabilities it needs.
>
> 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.
>
> 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.
>
> 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.
>
> --
> Work: Brad Cox, Ph.D; Binary Group; Mail bcox@xxxxxxxxxxxxxxx
> Home: 703 361 4751; Chat brdjcx@aim; Web http://virtualschool.edu
>
> ---------- 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
>
> > 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 -------
>
> _________________________________________________________________
> 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
------- End of Original Message ------- (05)
_________________________________________________________________
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 (06)
|