[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.