OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: FW: [soa-rm] [Fwd: I can't post to RM...]



http://ftpna2.bea.com/pub/downloads/architectsummitpresentations/uk2005/Stev
e_Jones_Capgemin_kn.pdf

This is a PDF version of the presentation that didn't make it as a PPT... I
can now post!  Other comments below.

Steve


> -----Original Message-----
> From: Chiusano Joseph [mailto:chiusano_joseph@bah.com]
> Sent: 24 August 2005 21:30
> To: SOA-RM
> Subject: RE: [soa-rm] [Fwd: I can't post to RM...]
>
> Welcome Steve (you're in for quite a ride on this TC; - just kidding)
[Jones, Steve G] If its as fractious as the Java Business Process ones I'll
be surprised :)

>
> First, I am getting a "Cannot open due to error" error when attempting
> to open the PPT file - are others getting this as well? (no specific
> error description)

>
> Let's start with:
>
> <Quote>
> has to START with the concept of Service, where simply put a Service is
> a definition of "what" an organisation (or project) does.
> </Quote>
>
> I would assert that this is *too* simple and broad a definition. It
> would apply to a service-based organization (such as yours and mine),
> but not necessarily other types of organizations. I also don't believe
> that a service has to be associated with a single organization (except
> perhaps that the service provider may be an organization, or individual
> for that matter) or project.
[Jones, Steve G] Its definitely broad, and deliberately so.  The intention,
for me, in creating a service architecture is giving an overall context and
structure to the problem space, whether that be a single organisation,
multiple organisations co-operating (or to use a dreadful consultancy term,
in co-opertition) with each other, or a single project.  The aim is to get
the "Big Picture" that everyone can agree on, so at least everyone
understands the problem space and agrees on the drivers.  Then you can start
doing BPR, IT Strategy, Enterprise Architecture, solutioning etc.

I actually find it harder to service map service industries than "real"
industries, as there is normally a physical clarity to those organisations
that makes it easier to understand the true "what" over those things that
are just a result of an organisational structure, Banks are a particular
nightmare of "what" v "organisation".

In terms of a service being associated with a single element or not, its
definitely the case that they can be shared between multiple organisations.
One element I would say is that two identically specified services that
operate in different services domains (e.g. "Procurement" between a Bank and
a Manufacturer), actually have different service level agreements, and
execution constraints, as a result of the containing service domain.  As a
direct example, in many ways this TC has the same service definitions as a
JCP Expert group, W3C group or the UN Security Council all have the same
service definition (defining and arbitrating on standards, request
in->decision out), but the overall context , the encompassing service domain
(organisation) they are in, fundamentally changes the operation and service
level agreement (the contract) of the group.

>
> <Quote>
> Once the service architecture is in place the detailed definition of
> services can then begin.
> </Quote>
>
> You have no way of knowing this since you're new to the TC, but we are
> actually trying to define "service" before we move into the reference
> architecture work (or at least be resonably close to having it defined)
> - so it's the other way around.
[Jones, Steve G]

Which I know now :)

And I'm not going to start asking for change! There is a difference between
what we are trying to do however and the process for someone creating their
business' SOA model. I find it easiest to discover services to create an
architecture without worrying about definitions beyond simple "What, Who,
Why" interactions which provide the service context.  From experience,
organisations who go "service hunting" i.e. trying to map out all those
elements which match a given definition of service tend to fall into the
granularity trap (how big is a service) and have no structure to manage or
understand the services.  This is predominately what happens when IT decides
on a "Web Service" strategy.

It makes sense for this group to work out what the service should be, as we
aren't trying to expose any actual services. Our challenge will in part be
when external people take the definition of service and try and apply it as
a cookie cutter across their organisation. The other challenge of course is
to ensure that the Service definition works at all levels of a business from
the strategic down to the infrastructure.

>
> I appreciate your contributions, and look forward to seeing the PPT.
>
> Joe
>
> Joseph Chiusano
> Booz Allen Hamilton
> O: 703-902-6923
> C: 202-251-0731
> Visit us online@ http://www.boozallen.com
>
>
> > -----Original Message-----
> > From: Duane Nickull [mailto:dnickull@adobe.com]
> > Sent: Wednesday, August 24, 2005 3:34 PM
> > To: SOA-RM
> > Subject: [soa-rm] [Fwd: I can't post to RM...]
> >
> > ***********************
> > Warning: Your file, Delivering SOA  Making IT understand the
> > business.ppt, was not scanned by InterScan MSS.
> > ***********************
> >
> >
> >  From our newest member.
> >
> > Duane
> >
> > -------- Original Message --------
> > Subject: 	I can't post to RM...
> > Date: 	Wed, 24 Aug 2005 15:42:00 +0100
> > From: 	Jones, Steve G <steve.g.jones@capgemini.com>
> > To: 	Duane Nickull <dnickull@adobe.com>
> >
> >
> >
> > So to add into the mix on Service definition I have the following
> >
> > Adding my own service definitions into the mix
> >
> > http://doi.ieeecomputersociety.org/10.1109/MS.2005.80
> >
> > The importance piece for me isn't so much the service
> > definition (or the definition of service) but the mechanism
> > by which a service is discovered and defined. This HAS to be
> > top down, and has to START with the concept of Service, where
> > simply put a Service is a definition of "what" an
> > organisation (or project) does. Once the service architecture
> > is in place the detailed definition of services can then
> > begin. The PPT attached covers a bit more of the thinking,
> > speak in a few mins.
> >
> > Steve
> >
> > ___________________________________________________________
> >
> > Steve Jones | *Capgemini *
> >
> > CTO, Application Development Transformation
> >
> > T +44 870 906 7026| 700 7026| www.capgemini.com
> > <http://www.capgemini.com>
> >
> > m: steve.g.jones@capgemini.com <mailto:steve.g.jones@capgemini.com>
> >
> > txt: +44 (0) 7891157026
> >
> > *Join the Collaborative Experience*
> >
> > ___________________________________________________________
> >
> > This message contains information that may be privileged or
> > confidential
> > and is the property of the Capgemini Group. It is intended
> > only for the
> > person to whom it is addressed. If you are not the intended
> > recipient,
> > you are not authorized to read, print, retain, copy, disseminate,
> > distribute, or use this message or any part thereof. If you
> > receive this
> > message in error, please notify the sender immediately and delete all
> > copies of this message.
> >
> >
> >

This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient,  you are not authorized to read, print, retain, copy, disseminate,  distribute, or use this message or any part thereof. If you receive this  message in error, please notify the sender immediately and delete all  copies of this message.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]