Eric,
Actually, it has nothing to do with an epiphany, just a plea for
(sorry to say it) vendors to stop abusing terminology to support their sales
efforts. My apologies for those that are offended by that statement, but
who among on this list can deny that they do this.
SOA Testing, SOA Infrastructure. Come on Eric, you and I have been
at this game a long time. When was the last time you built a test harness
for your object architecture? When was the last time you developed
infrastructure for your message-oriented middleware architecture? You don't
apply physical entities to an abstract quantity. Even a C++ compiler knows
you can't create an instance of an abstract interface! :-)
I do believe that SOA is being undermined by its association with
the words that are following it and I believe it is being led by the vendor
community that is selling tools to this market. Perhaps even led by the
analyst community consulting to the vendors helping them to try to
differentiate themselves in a rapidly commoditized market.
If anything was an epiphany, it was that as an architectural
paradigm, SOA is up there with FEAF, Zachman, etc. It can be used liberally
to describe any system regardless of what that system is comprised of.
Moreover, it's more robust than these EA frameworks because it carries with
it the weight of compliance and governance inherent in its definition.
JP
-----Original Message-----
From: [email protected]
[mailto:[EMAIL PROTECTED] On Behalf Of Eric
Newcomer
Sent: Monday, March 13, 2006 5:35 PM
To: [email protected]
Subject: RE: [service-orientated-architecture] Re: SOA Infrastructure
JP,
I applaud your efforts to reinvent the term but
unfortunately I don't think I can change what I think
SOA infrastructure means just because of your epiphany
around service oriented people.
Don't get me wrong, I think you are onto something
important, but it's not really anything new. In my
book for example we discuss the fact that service
contracts extend way beyond WSDL to include things
people write down on paper. But the contracts are
still part of SOA infrastructure.
What I understand you are doing is emphasizing an
aspect of SOA that tends to get overlooked by
technologists, and that's great, but to me this is
still a matter of emphasis rather than separation. Or
a sliding scale if you will - technology still plays
an important part but you are correct to remind us
that it's not the be all and end all.
But I think there's another very important aspect of
this discussion, and something that bears emphasizing
in addition to the emphasis on people. Services are
not objects, and emphasizing their relationship to
human activities helps reinforce this distinction as
well.
For years we have tended to model software artifacts
as things (i.e. objects) but now we are more correctly
(correct from the point of human abstraction that is,
meaning easier to understand and map to business
requirements) focusing on functions (i.e. services).
This is confusing since you can use an object to
implement a service even though a service isn't one.
I see this mistake fairly often, for example in a
recent book manuscript I was reviewing.
Emphasizing the human aspect should also help
reinforce the important distinction between objects
and services.
Eric
--- JP Morgenthal <[EMAIL PROTECTED]> wrote:
> Eric,
>
> And I believe that your focus is a fine one.
> However, going back to
> the title of the email. I don't believe, because of
> the other applications
> of SOA, that it is appropriate to say "SOA
> Infrastructure" unless we're
> using it to cover all aspects of implementing a
> service including the pens,
> pads, chairs, buildings, etc.
>
> JP
>
> -----Original Message-----
> From:
> [email protected]
>
[mailto:[EMAIL PROTECTED]
> On Behalf Of Eric
> Newcomer
> Sent: Monday, March 13, 2006 9:41 AM
> To: [email protected]
> Subject: RE: [service-orientated-architecture] Re:
> SOA Infrastructure
>
> Ok, cigars notwithstanding, I think I get it about
> the
> non-computerized contracts being an important part
> of
> the design, and valuable in their own right. Not to
> be
> overlooked etc.
>
> I would still say, however, that the main point of
> any
> SOA exercise would be to automate as many of the
> contracts as possible, since computers typically
> (but
> not always, as you are saying) tend to help
> businesses
> run more efficiently.
>
> Thanks,
>
> Eric
>
> --- JP Morgenthal <[EMAIL PROTECTED]> wrote:
>
> > BINGO! Give the man a ci-gar! That's exactly
> what
> > I'm saying. Remember
> > the 'A' in SOA. I claim that SOA is about a way
> to
> > design a system-any
> > system-and it does not have to be realized in
> > software. I believe it is a
> > grave mistake for the industry to associated SOA
> > with the fact that it has
> > to be realized in software. And, indeed, this is
> > exactly what I believe
> > others believe when I see terms like "SOA
> > Infrastructure" and "SOA Testing".
> >
> > SOA is a way to design a system that closely
> models
> > the business, breaking
> > down the business as a set of services with a
> > well-defined contract. Some
> > of these systems may be automated, while others
> are
> > based on humans. A
> > service is a black box that has a well-defined
> input
> > and output and
> > guarantees a certain level of delivery.
> >
> > JP
> >
> > -----Original Message-----
> > From:
> > [email protected]
> >
>
[mailto:[EMAIL PROTECTED]
> > On Behalf Of Eric
> > Newcomer
> > Sent: Sunday, March 12, 2006 11:40 AM
> > To:
> [email protected]
> > Subject: Re: [service-orientated-architecture] Re:
> > SOA Infrastructure
> >
> > Todd,
> >
> > I am really baffled by this, I have to admit. Are
> > you
> > implying that an SOA doesn't have to be realized
> in
> > software?
> >
> > I have been thinking of SOA as related to
> software,
> > isn't it?
> >
> > I realize there are a lot of nontechnical issues,
> > and
> > I completely agree that an SOA needs to be defined
> > independently of technology considerations, but at
> > the
> > end of the day isn't the point of the exercise to
> > improve the usefulness and suitability of
> computers
> > for business applications?
> >
> > Are you and JP arguing that it's enough to do the
> > design? This is what I don't get.
> >
> > Thanks,
> >
> > Eric
> >
> >
> > --- Todd Biske <[EMAIL PROTECTED]> wrote:
> >
> > > +1. If I could give it +2, I would. Every
> time
> > I
> > > sit down and
> > > think about what it takes to make SOA
> successful,
> > I
> > > don't think
> > > technology ever comes up on my list.
> > >
> > > -tb
> > >
> > > On Mar 11, 2006, at 3:42 PM, JP Morgenthal
> wrote:
> > >
> > > > Eric,
> > > >
> > > > Technology is not required to implement
> > anything.
> > > I can take any of
> > > > the bank services I represented in my example
> in
> > > my post and
> > > > implement them
> > > > with humans. Will I still need
> infrastructure,
> > > yes, probably a
> > > > building in
> > > > which to work, a phone, a pen, pencil, maybe
> > I'll
> > > even throw in a
> > > > pad for
> > > > good faith. The one thing I don't need is
> > > technology (unless you
> > > > want to
> > > > consider the pencil technology, in which case
> I
> > > won't argue).
> > > >
> > > > The problem with saying SOA Infrastructure is
> > > that it immediately
> > > > associates in non-technical people's minds
> that
> > > this thing is
> > > > beyond them,
> > > > not in their field of vision, "that thing that
> > IT
> > > does that we all
> > > > hate
> > > > because they're too slow doing it in the first
> > > place."
> > > >
> > > > I just worked with a company where we used
> SOA
> > to
> > > define the entire
> > > > enterprise. The CFO and the sales team and the
> > > marketing team and
> > > > the loan
> > > > team didn't see SOA as technology. They saw
> it
> > as
> > > the way they
> > > > were being
> > > > organized. They saw it as the way they define
> > > what they do to other
> > > > departments, they say it as requirement to
> > develop
> > > a contract that
> > > > explains
> > > > to other groups how to use their services.
> > > >
> > > > SOA can be so much more than we're giving it
> > > credit for today. It's
> > > > only recently that I've seen the power of
> using
> > in
> > > organizational
>
=== message truncated ===
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Yahoo! Groups Links
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/service-orientated-architecture/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
