[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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:rshafii@bea.com]
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:steve.g.jones@capgemini.com]
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: steve.g.jones@capgemini.com txt: +44 (0) 7891157026 Join the Collaborative Experience ___________________________________________________________
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]