Rex Brooks says what we all know to be true. (01)
"as long as
there is a significant amount of profit to be ensured through
incompatibility, that's what we will get." (02)
The benefits to service orientation are primarily as an enabler of culture
shift, one that is greatly needed. (03)
SOA should NOT be a vehicle for locking in funding by the incumbent vendors
for continuing contracts. (04)
My eight page PowerPoint addresses, an a cartoon fashion, the potential
consequence of service orientation that is also process orientation. (05)
http://www.secondschool.net/beads/ontologyMapping/58.htm (06)
As long as "process" is defined as a "business process" we have not made the
shift from "services supplied by the incumbent vendors" to "services" where
services are defined as those natural everyday exchanges (which may or may
not have anything to do with a contractor getting a government contract.) (07)
This is what the SOA shift "should" mean. (08)
SOA should cause a shift in the control over information structure. (09)
Over the past decade, I have tried to make a position clear that the RFP's
are funding non-interoperability. The way that RFPs are generated is
directed at funding certain groups (and not funding other groups). This
fact is the primary reason why the IT in government services lags behind the
private sector, and why the private sector is barely tolerable. (010)
We have gathered evidence, direct and indirect, that the RFPs, and the
"standards", inhibit innovation that comes from individuals who do not have
a large contracting presence. This effort has been very difficult, for
reasons that are hard to tie down. (011)
I support the call for a reform of the RFP orientation. (012)
Paul Prueitt (013)
-----Original Message-----
From: soa-forum-bounces@xxxxxxxxxxxxxx
[mailto:soa-forum-bounces@xxxxxxxxxxxxxx]On Behalf Of Rex Brooks
Sent: Friday, May 12, 2006 8:58 AM
To: Service-Oriented Architecture CoP
Subject: Re: [soa-forum] Questions to the SOA CoP From Roy Mabry (014)
Hi Brand, All, (015)
Having just returned from the OASIS 2006 Symposium, in which the
SOA-Reference Model Technical Committee worked on readying the 1.0
specification for a second, 15-day public comment period and the SOA
Reference Architecture Subcommittee made substantial progress in
organizing the work toward a specification describing the components
of "a" SOA Reference Architecture consonant with the RM, I think
these questions are very pertinent and acutely drawn. (016)
Right at this moment I am most concerned with 1. What SOA is and isn't. (017)
SOA is or can be composed of many components, but I believe that what
SOA IS in any given circumstance right now is less important than
making sure it becomes widely perceived what SOA IS NOT. (018)
IMO, it is most important to make it known that SOA IS NOT ANY single
conceptualization, let alone a single technology or a single
"ENABLING" technology. (019)
RIGHT NOW the single biggest prize in the scramble for market share
in the largest (now-inevitable) IT infrastructure renewal across the
entire IT landscape since Y2K is the public perception of owning
some indispensable part of SOA, regardless of how that perception is
accomplished. (020)
Now, if I had the biggest pockets in this market, I would spare no
expense to accomplish the perception that I had that "indispensable"
piece of the SOA puzzle or mosaic, and of course, my single vendor
solution would simply be the "wisest," most prudent, inescapable
choice. (021)
So, we need to make sure SOA is shown over and over to be optimizable
through common open standards regardless of major vendor components,
or despite the single-solution impedimenta of major vendor components. (022)
Frankly, I don't think it will be possible to improve efficiency and
effectiveness of government operations until the RFPs are written to
require genuine interoperability of major vendor components through
compliance with voluntary consensus standards because as long as
there is a significant amount of profit to be ensured through
incompatibility, that's what we will get. (023)
The only way I can see to do this is to eliminate the continued
reliance on the perception that large-is-better or the perception
that only large scale companies can produce viable, scalable
solutions. (024)
I think the opposite is actually true, and only smaller companies can
manage large contracts because that is simply all they can afford to
do so they won't be distracted trying to manage several large
projects at once. However, until it can be demonstrated in practice
over and over again, no one is going to stake their careers on it. (025)
How we do that is unclear, since it is a chicken and egg problem. The
odd thing is, this approach is actually in the interest of the
megasaurs. They would be able to reduce their own costs and improve
their own productivity through elimination of the preponderance of
middle management, which would then be freed and made available to
the legions of smaller companies that would then, in turn, need those
very temporarily unemployed but highly skilled middle managers. (026)
Those middle managers, in turn, would actually probably move to the
top of the smaller company food chains, so it would be better for
their long term career interests, also. Meanwhile, the megasaurs
would still do quite well since collections of their components would
remain as required by the legacy systems we have now, even if those
systems are less than half the age of what was thought of as 'legacy'
before Y2K. (027)
However.... (028)
Regards,
Rex (029)
At 9:42 AM -0400 5/12/06, Niemann.Brand@xxxxxxxxxxxxxxx wrote:
>SOA CoP,
>
>
>
>Roy Mabry, Co-Chair of the AIC Governance Subcommittee has posed the
>following questions:
>
>
>
>1. What SOA is and isn't.
>2. Where the CoP sees SOA going in the future.
>3. What benefit it will have for improving efficiency and
>effectiveness of government operations.
>4. What will have to change in policy and governance as we know it
>to transform government to better share information across
>organizational boundaries and better serve the citizen.
>
>
>
>Brand
>
>
> _________________________________________________________________
>Subscribe/Unsubscribe/Config:
>http://colab.cim3.net/mailman/listinfo/soa-forum/
>Shared Files: http://colab.cim3.net/file/work/soa/
>Community Portal: http://colab.cim3.net/
>Community Wiki: http://colab.cim3.net/cgi-bin/wiki.pl?AnnouncementofSOACoP (030)
--
Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-849-2309
_________________________________________________________________
Subscribe/Unsubscribe/Config:
http://colab.cim3.net/mailman/listinfo/soa-forum/
Shared Files: http://colab.cim3.net/file/work/soa/
Community Portal: http://colab.cim3.net/
Community Wiki: http://colab.cim3.net/cgi-bin/wiki.pl?AnnouncementofSOACoP (031)
_________________________________________________________________
Subscribe/Unsubscribe/Config: http://colab.cim3.net/mailman/listinfo/soa-forum/
Shared Files: http://colab.cim3.net/file/work/soa/
Community Portal: http://colab.cim3.net/
Community Wiki: http://colab.cim3.net/cgi-bin/wiki.pl?AnnouncementofSOACoP (032)
|