Gervas,

I have been thinking about how to respond for a while.
 It's unfortunately still a misunderstanding.

Here's how I have been doing vendor-neutral technology
pitches for years:

-- Describe the problem - in this case architecture
and design comes before technology
-- Describe a solution - in this case SOA
infrastructure mapped to the architectural and design
requirements
-- Give an example that works for any vendor (or at
least multiple vendors) - in this case the products
from IONA being a good potential fit for some of those
requirements

If I were working for another vendor, I would use that
technology for the example.  But in the examples I
give, it could be any number of vendors.  

To me this isn't a sales pitch but a vendor neutral
discussion about technology and requirements, using a
particular vendor's product for an example to help
prove the point.

Has something changed?  Is this not a good way to do a
vendor neutral technology pitch anymore?  

Or is the problem simply that I work for a vendor?

Thanks,

Eric


--- Gervas Douglas <[EMAIL PROTECTED]> wrote:

> Eric,
> 
> No apology called for.  If I had really objected (as
> some moderators
> would have), I would not have approved your message.
> 
> Whilst I appreciate the nobility of your intentions,
> I have to say it
> was a textbook example of a good pitch.  Contrary to
> popular myth, one
> of the secrets of effective selling is to actually
> believe in what you
> are selling (and I do not mean in the meretricious
> manner of temporary
> assumption of belief as adopted by certain political
> orators [TB,
> perhaps??]). Perhaps you should use your obviously
> natural talent in a
> deliberately targeted fashion!
> 
> Gervas
> 
> --- In
> [email protected],
> Eric Newcomer
> <[EMAIL PROTECTED]> wrote:
> >
> > Hi Gervas,
> > 
> > I'm sorry if it seemed like a sales pitch.  It
> wasn't
> > my intention.  I happen to think our technology is
> a
> > very good fit for some SOA architectures and
> > requirements. 
> > 
> > From the recent conversations about what's
> appropriate
> > for the discussion group I thought it was ok to
> post
> > messages that were enthusiastic about a particular
> > technology.  I'm sorry if I misunderstood.
> > 
> > To be clear, the question at the end was not about
> the
> > idea that our technology could be a good fit in
> some
> > SOA architectures, although since it was directly
> > after the last paragraph I could see why someone
> might
> > think it was related only to that.  
> > 
> > My intention was rather to confirm the thrust of
> the
> > entire message, which was (at least this is what I
> > meant it to be) that the design should be done
> > independently of the vendor or technology choice.
> > 
> > Eric
> > 
> > --- "Gervas Douglas (gmail)"
> > <[EMAIL PROTECTED]> wrote:
> > 
> > > Putting my moderator's hat on:
> > > 
> > > Hmmm.  That wasn't so much billboarding as a
> gentle
> > > but deadly sales pitch.
> > > I like the assumptive (how could he possibly say
> > > anything but "yes") close
> > > at the end.  Ever thought of moving into sales,
> > > Eric???
> > > 
> > > Have fun!
> > > 
> > > Gervas
> > > 
> > > ----- Original Message -----
> > > From: "Eric Newcomer" <[EMAIL PROTECTED]>
> > > To:
> > >
> <[email protected]>
> > > Sent: Wednesday, March 08, 2006 3:35 PM
> > > Subject: Re: [service-orientated-architecture]
> Re:
> > > SOA Infrastructure
> > > 
> > > 
> > > > Hi Awel,
> > > >
> > > > I would agree 100% with what you are saying,
> and I
> > > > often tell our customers (and anyone else who
> > > might be
> > > > attending one of my talks, such as the one
> next
> > > week
> > > > at the InfoWorld forum in San Fran) that it is
> > > vitally
> > > > important to start with the design and the
> > > > architecture and make the technology choice
> later.
> > > >
> > > > Especially if you are doing SOA it's important
> to
> > > do
> > > > the design first and then see what technology
> maps
> > > > best.  We do not suggest anything different.
> > > >
> > > > We are also very happy to identify the areas
> where
> > > we
> > > > can contribute to any such architecture, such
> as
> > > > service enabling legacy applications, or
> > > abstracting
> > > > the messaging layer, if those are important
> > > aspects of
> > > > the architecture (as they are for some of our
> > > > customers).  If we don't fit, that's ok too. 
> We
> > > are
> > > > not trying to force ourselves into places that
> > > don't
> > > > make sense.
> > > >
> > > > But we do believe strongly that our technology
> is
> > > > good, proven in large scale demanding
> applications
> > > and
> > > > it can be helpful.  Not in every case of
> course
> > > but in
> > > > many.
> > > >
> > > > So I think we are in agreement?
> > > >
> > > > Thanks,
> > > >
> > > > Eric
> > > >
> > > > --- Awel Dico <[EMAIL PROTECTED]> wrote:
> > > >
> > > > > Hi Eric;
> > > > >
> > > > > It is a good observation as to how the
> vendors
> > > are
> > > > > approaching the
> > > > > ESB product implementation. That diversity
> may
> > > be
> > > > > positive for the
> > > > > users - choose what best fit to their
> situation.
> > > The
> > > > > reality from
> > > > > your customers (users) perspective is
> different
> > > > > though. Many
> > > > > enterprises do not just go and buy those
> "ESB
> > > > > products". They look
> > > > > at the ESB capabilities as a pattern first -
> at
> > > > > least from the point
> > > > > of view of the enterprise I work for. With
> clear
> > > > > understanding of
> > > > > the capabilities, they map those
> capabilities
> > > with
> > > > > the SOA
> > > > > infrastructure requirement. This is
> important
> > > > > because you may not
> > > > > need ESB at all (XML appliances may do the
> job);
> > > or
> > > > > it is something
> > > > > that you need right away, or it may be
> something
> > > for
> > > > > the future. The
> > > > > enterprise architecture has to come up with
> the
> > > SOA
> > > > > technology
> > > > > infrastructure reference architecture
> > > accordingly.
> > > > > Based on the
> > > > > understanding of the capabilities required
> and
> > > > > enterprise
> > > > > architectural guidelines, they start to
> evaluate
> > > ESB
> > > > > products - may
> > > > > take them for a test drive (Proof-of-concept
> 
=== message truncated ===


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 




 
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/
 


Reply via email to