Re: [ebsoa] [Comment: Section 2, Para 1] Re: [ebsoa] Recipes for Success

["Chiusano Joseph" <chiusano_joseph@bah.com>]

David RR Webber wrote:
> 
> Joe,
> 
> In terms of our position statement and what we say SOA might
> include in its mission profile - this stuff below fell into my
> mailbox today too.  I would submit we need to
> position ourselves so that we do not suffer academic obsolescence
> right out the gate!  Clearly - whatever the aforementioned below
> actually means (your guess is as good as mine!) - you can use
> an ebSOA to implement it - and we need to make sure people
> can make that connect.  Since these
> words are extremely cheap at this 70,000 ft level - we may just
> want to include them in some way - so that our customers don't
> mistakenly go elsewhere looking for what they really need - aka
> simple, proven and robust solution sets!

Thanks David - not sure how these comments relate to the definition I
proposed.

> Now there's a radical thought - how about:
> 
> "ebSOA - a simple, proven and robust solution set for delivery
>  of network based business systems and components".

I would say that this definition does not capture the essence of SOA -
which are shared services, flexible architectures, and business agility.
I would say that there are probably approaches other than SOA that can
apply to the definition above - so IMHO the definition is not specific
enough.

> Less could well be more!?!

I would say not in the case of defining what SOA means, which should be
at the heart of our work. 

Joe

> DW.
> 
> <snip>How do the common "build" principles that power the Internet illumine
> the
> agile path from today's business process conversations to tomorrow's
> business process components?  How do semantic technologies lightly abstract
> and assemble shared meaning to sustain quality business conversations?
> What distributed enterprise design tools accommodate the multiple forms of
> expertise that need to be expressed and integrated in agile business
> components within each Services life-cycle?  What can we learn from early
> developers and early adopters?
> </snip>
> ----- Original Message -----
> From: "Chiusano Joseph" <chiusano_joseph@bah.com>
> To: "Matthew MacKenzie" <mattm@adobe.com>
> Cc: "ebsoa" <ebsoa@lists.oasis-open.org>
> Sent: Tuesday, May 25, 2004 9:31 AM
> Subject: [ebsoa] [Comment: Section 2, Para 1] Re: [ebsoa] Recipes for
> Success
> 
> > I would like to suggest an alternate version of the definition of SOA
> > that appears in Section 2, Para 1.
> >
> > Current definition:
> >
> > "An architecture is called a Service Oriented architecture if it follows
> > a general model for how components communicate or interact with each
> > other."
> >
> > The following proposed alternate definition approaches the definition of
> > SOA from a business/functional perspective:
> >
> > "Service-oriented architectures (SOAs) provide flexibility and agility
> > for organizations through their representation of business functionality
> > as implementation-neutral, standards-based shared services. They are a
> > natural progression in the evolution that began with the advent of XML
> > and the emergence of Web Services."
> >
> > I would also recommend an alternate Figure 3.1 that depicts an
> > architecture with multiple functions exposed as services, many of which
> > utilize shared services (i.e. each other) for their required
> > functionality.
> >
> > Thoughts?
> >
> > Joe
> >
> > Matthew MacKenzie wrote:
> > >
> > > So, I've officially thrown down a first draft of this specification,
> based on Duane's introduction, and an extremely perverted transliteration of
> the Zachman framework into a simple pattern notation that I cooked up. Its
> basically at the outline phase right now, I more or less see it having the
> following structure:
> > >
> > > Introduction - Basic Stuff
> > > Service Oriented Architecture - What it is, why we're doing it, etc.
> > > Pattern Notation - How we will represent patterns, define a grammar.
> > > Patterns - The actual patterns, conforming to the pattern notation.
> > >
> > > So, in order to facilitate the progression of this specification, I will
> make the following proposals for some ground rules.
> > >
> > > 1. Please, don't edit the working draft unless you are part of the
> editing team.
> > > 2. Please, review and send comments and suggested content. One comment
> per email with a subject that sets the context, e.g. s1.1, fix to para 3. If
> you draft content that is complex, do it in MS Word using ONLY the default
> text styles with body text at Arial/10pt.
> > > 3. Please submit comments and content to the mailing list, so that they
> are archived.
> > > 4. Please, don't cc people who are known to be on the list when sending
> to the list.
> > >
> > > Thanks :-)
> > > ___________________________
> > > Matthew MacKenzie
> > > Senior Architect
> > > IDBU Server Solutions
> > > Adobe Systems Canada Inc.
> > > http://www.adobe.com/products/server/
> > > mattm@adobe.com
> > > +1 (506) 871.5409
> >
> > --
> > Kind Regards,
> > Joseph Chiusano
> > Associate
> > Booz | Allen | Hamilton
> >

-- 
Kind Regards,
Joseph Chiusano
Associate
Booz | Allen | Hamilton