I agree.
From my understanding the most concise, clear and sensible idea about BPM &
SOA and their relation I got is from a publication by OMG available at
http://www.businessprocesstrends.com/publicationfiles/bptadvisor2006Apr18%2Epdf regards, Shashank D. Jha On 5/5/07, Jerry Zhu <[EMAIL PROTECTED]> wrote:
Thank you, Shashank, for the excellent article. It reflects my view well except a small portion that is SOA being an architecture for BMP. My take on this and in general is that SOA is the architecture at the level of service modeling. The implementation of Services maybe using OO that needs another architecture at different level of abstraction. In other words, we need different architectures at different levels of abstraction. So we need a BMP architecture as much as we need a architecture at service level abstraction. Architectures at different levels of abstraction are ontologicially and sementically distinct and are not overlapping in representation of reality. Jerry Zhu --- "Shashank D. Jha" <[EMAIL PROTECTED] <shashank.dj%40gmail.com>> wrote: > Above was quote from article by Ismael Ghalimi > available at > http://itredux.com/blog/2006/08/13/bpm-is-soas-killer-application/ > > regards, > Shashank D. Jha > > On 5/5/07, Shashank D. Jha <[EMAIL PROTECTED]<shashank.dj%40gmail.com> > > wrote: > > > > From a business standpoint, a service is too small > a unit to really appeal > > to the business side of the house. Its granularity > is too fine. And it's > > only when elevated to the level of processes that > business folks usually > > start paying attention. Reusing a currency > conversion service across > > multiple applications, and saving three man-month > of development along the > > way, is one thing. Being able to shave three weeks > in the overall > > order-to-cash process is another. Guess which of > the two will get the CFO's > > attention? > > > > So you wish that business people to work with > lesser abstraction based on > > SOA!! And this is a new idea supported by > Microsoft, then this has lesser > > chances of success. > > > > BP running on top of SOA infrastructure sounds > more realistic vision of > > achieving success for both BPM and SOA. Ps note > that SOA is an initiative by > > IT not business people. > > > > regards, > > Shashank D. Jha > > > > > > On 5/4/07, Steve Jones <[EMAIL PROTECTED]<jones.steveg%40gmail.com> > > wrote: > > > > > > On 04/05/07, Shashank D. Jha > <[EMAIL PROTECTED] <shashank.dj%40gmail.com><shashank.dj%40gmail.com >> > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > I am not sure if I have understood the stated > correctly. So what your > > > are suggesting here are two things- > > > > > > > > 1. Business as a set of process is at a lower > level of abstraction > > > than business as a set of services? > > > > > > Yes > > > > > > > > > > > 2. BPM is one of the implementation approach > for SOA? > > > > > > Yes > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 4/30/07, Steve Jones > <[EMAIL PROTECTED] <jones.steveg%40gmail.com><jones.steveg% 40gmail.com>> > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I think in part this nicely sums up one of > the challenges that we > > > have today, namely that a lot of SOA isn't > architecture (which should be > > > business focused) its design focused (which > would be SOD) around technical > > > implementations. There is a sort of a tiering of > elements here which is > > > > > > > > > > SOD = Web Services and development > boundaries > > > > > BPM = Cross Web Service processes > > > > > > > > > > In this view BPM conceptually sits "above" > SOA, and is hugely pushed > > > by technology vendors as it fits well with the > stack based thinking (App > > > Server/.NET, Development, Web Services, BPEL) > which makes selling products > > > easier. This is the traditional IT product > oriented way of thinking. > > > > > > > > > > The other SOA is the architectural one which > views the business as a > > > set of services and then takes that view as a > mechanism for the > > > re-organisation of IT, projects and management > to become more business > > > focused. In this view BPM is an implementation > approach for certain types of > > > IT services or is a measurement mechanism for > services ( e.g. Sales). > > > This is (to me) the new way of thinking that SOA > allows. This is beginning > > > to be seen in vendor's products (e.g. Microsoft > Motion, IBM's CBM) but > > > is early days so isn't overly pushed within the > marketing hype yet. > > > > > > > > > > Steve > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 29/04/07, John Evdemon > <[EMAIL PROTECTED] <john.evdemon%40microsoft.com>< john.evdemon%40microsoft.com>> > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Maybe I'm oversimplifying but I see SOA as > a design philosophy > > > ("loose coupling") and BPM as a management > philosophy > > > > > > ("processes as assets"). SOA is a means > for some of the aspects of > > > BPM. > > > > > > > > > > > > John > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: > [email protected]<service-orientated-architecture%40yahoogroups.com> <service-orientated-architecture%40yahoogroups.com>[mailto: > > > service- > > > > > > > > [EMAIL PROTECTED]<orientated-architecture%40yahoogroups.com> <orientated-architecture%40yahoogroups.com>] > > > On Behalf Of Peter Madziak > > > > > > > Sent: Saturday, April 28, 2007 12:08 PM > > > > > > > To: > [email protected]<service-orientated-architecture%40yahoogroups.com> <service-orientated-architecture%40yahoogroups.com> > > > > > > > Subject: Re: > [service-orientated-architecture] BPM & SOA > > > > > > > > > > > > > > Just to chime in with own $0.02.. > > > > > > > > > > > > > > On 4/27/07, Steve Jones < > [EMAIL PROTECTED] <jones.steveg%40gmail.com><jones.steveg% 40gmail.com> > > > > > > > <mailto:jones.steveg%40gmail.com> > > wrote: > > > > > > > > 1) BPM is an implementation > technology, SOA is a conceptual > > > > > > > (thinking) > > > > > > > > framework. So all I've ever considered > BPM as is "one" of the > > > > > > > > implementation choices for a service > > > > > > > I agree completely and I'll only add > that I sometimes try to > > > frame > > > > > > > things relative to service boundaries. > So in this sense, I see > > > the > > > > > > > orchestration capabilities that the BPM > tools provide as just > > > one of > > > > > > > the many possible implementation > alternatives for inside the > > > service > > > > > > > boundary. I make the "inside the service > boundary" distinction > > > here > > > > > > > because I also see higher-level business > capabilities being > > > realized > > > > > > > through the choreography of services. > The difference is one of > > > > > > > centralized control (i.e. orchestration > from === message truncated ===
