RE: [soa-blueprints] Christmas SOA...

I’m with this view in part, the
challenge it presents is that the BPM and actual execution process become separated
during implementation, so the modelled BPM is then converted into a technical
process with the BPM points “marked” for integration into a BAM
(Business Activity Monitor), if however the business process needs to change
then this has to be done at the implementation level rather than at the
modelling level because of the separation that has occurred.  

 

The point I’m trying to get across
is that the running process is
the technical one, while the perceived process
is the Business one, the challenge is how to enable both elements to work
concurrently and to be managed as one, rather than having a separation between
BPM and realisation.  In the Christmas example the Business only sees the
BPM but that is not in fact the actual process that is running it is just a
view on the process.  If the business wished to change the BPM, e.g. because
they want to add another source of presents, then their modification of the
Business Process needs to be semi-automatically converted into an execution
process.

 

What I’ve historically seen is that
the Business Process is first modelled at the business level, then “refined”
by IT to include the execution elements, this completed process means a lot less
to the business and includes a load of information they don’t care about.
 Thus the nicely modelled element is lost and replaced with (yet again)
the element that is easiest for IT.   As a SOALogic example, if you
consider the high-level order to cash process that we’ve modelled, in IT
reality (the next stage) inside Finance when the Invoice is created there would
be a step to “getCustomerDetails” from the CustomerService (CRM)
(assuming we aren’t going to use single canonical form) this is 100%
required to fulfil the business requirement of “send invoice” but
100% not required for the business to know how you do it.  Its always been
the sort of element where I’ve seen the Business Process corrupted by its
technical implementation and its just that challenge that I’d like to see
us create a blueprint on how to avoid.

 

Steve

 

From:
Reza Shafii [mailto:] 

Sent: 07 December 2005 13:28

To: Jones, Steve G;


Subject: RE: [soa-blueprints]
Christmas SOA...

 

Hi Steve,

 

In my view, this is where
the BPM layer plays a major role. Well modeled BPM processes form a very thin
layer and only model the business view while orchestrating interaction with
different core services (as well as the end users). A thin process BPM layer
gives you the ability to model a business process that can be understood by the
business with all the BAM capabilities: The orchestration implemented by this
BPM layer is then really the implementation of the high level Business Process
service itself.

 

Cheers…

 

Reza

From:
Jones, Steve G [mailto:] 

Sent: Wednesday, December 07, 2005
6:48 AM

To:


Subject: [soa-blueprints] Christmas
SOA...

 

One of the challenges that I’ve been facing while
looking at the Business Process side of SOALogic is how to clearly separate the
business from implementation view of a process.  A challenge I’ve
faced previously is explaining why this is required and I’ve never really
had a good cross domain answer, until in a moment of boredom I decided to do a
 http://blueprints.jot.com/Christmas+SOA
on how my daughter Lana and her parents differ on their views on getting
Christmas delivered.  Suddenly this gave me my cross-domain explanation of
the difference, and an SOA Blueprint for delivering the Christmas project this
year, I’ve not gone down to Level 2 and hosting Christmas dinner at this
stage J

 

On a more serious point though, as we move in the SOALogic
example more into the business process and implementation elements it’s a
definite challenge to blueprint how these two are in fact the same thing, but
with differing representations of how they operate.  Does anyone know of
any work out there to help clearly separate these views, while retaining a
single execution process?

 

Steve

 

 

___________________________________________________________

Steve Jones | Capgemini 

CTO, Application Development Transformation

T +44 870 906 7026| 700 7026| www.capgemini.com

m:  

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.