Lists Home |
Date Index |
- To: "Greg Hunt" <email@example.com>
- Subject: RE: [xml-dev] Re: Major Historical SOA Milestone Today
- From: "Bullard, Claude L \(Len\)" <firstname.lastname@example.org>
- Date: Fri, 12 May 2006 08:21:43 -0500
- Cc: <email@example.com>
- Thread-index: AcZ1VNAX+pY9MD/xRxOx0Hh0gI/vegAcTCgg
- Thread-topic: [xml-dev] Re: Major Historical SOA Milestone Today
I completely agree. My only quibble is that on my desk as I write are
RFPs at levels of technical complexity that are not appropriate for the
process of the procurement. We have to answer these in very precise
detail even where that detail makes little difference to the purchaser.
It makes the IT staff feel better and in rare cases, it makes their jobs
easier. However, if the IT staff were a bit more involved, they could
settle these issues before the paper goes to press.
I don't know what your business model does, but ours has a very long
procurement cycle and requires guys like me to analyze RFPs down to the
last field. It slows us down. Too many people assume they are selling
to guys and gals just like our selves. That is actually very rare in
big systems sales. That is where the Sun's of the world lost it.
Multi-core servers, Java, are just stuff. Yadda yadda. That approach
to the computer systems business is a recipe for $4 a share stock.
Very few industrial software/hardware systems are shrink wrap. When you
get into multi-million dollar sales, the process is anything but easy.
Will SOA make it easier? One can only hope.
From: Greg Hunt [mailto:firstname.lastname@example.org]
I think that the interesting thing about SOA is the extent to which it
will drive modelling approaches to services. The focus on the specific
technologies is an unfortunate distraction (and I agree with Michael Kay
that it looks awfully like things that we have already done).
Many businesses are already able to be conceptualised as sets of outward
and inward facing services, its the inconsistent modelling at the
business semantic and operational level that prevents me from easily
sending a purchase order to partner agencies or companies. This
inconsistency is a fact of life. If you are a supplier to a $20Bn
retailer, you do what they want. If you deal with two of them, you
probably do two different things. Its how that problem is managed that
will determine success or failure of the broader aims of the SOA
I don't agree that the business guys wanting to know "how we do it" is
exactly what slows things down. What they usually really want to know
is "what are the business visible side-effects?" and "how does it
break?". Today that tends to mean knowing whats inside the box. How do
we model services so that the business can understand side-effects and
breakage easily without the conversation about the box content? How do
we standardise knowledge of those things?
What I hope to see come from all this SOA stuff is approaches to the
definition of vocabularies (how they relate to stylistic, semantic and
change management issues) , the evolution and diffusion through the
industry of commonly understood interaction styles, and some answer to
the question at the bottom of it all, how do you define service
interfaces that are maximally useful and maximally flexible. It is this
understanding, if we get there, that will pay off. Otherwise it all
tends to look like a cooler, more recent version of
[CORBA|DCOM|APPC|RPC|Punch Card Bills] in a less resource constrained
environment. The initial, top-level definitions are a long way from
addressing these issues.
The XML space and the SOA spaces both seem to be where the relational
database space was in the 80s, disconnected technologies, limited
practitioner understanding, some odd implementations and improving but
not-there-yet tool support (for the not quite there yet WS-* stuff that
we need to enable handling of financial value transactions), all
combined with a high level of enthusiasm. Practitioners in general are
still struggling to arrive at a concensus on how to do things and still
struggling with some odd ideas about how things work. What I believe
happened in the RDB space was that the knowledge diffused through the
industry, the tools got better, organisations internalised the
knowledge, and database modelling is less of a trauma (at the
less-demanding end at least) than it was. I hope we go the same way