SOA is an initiative by people who stands exact between business and IT -
architects and business managers responsible for IT products. IT, on a
contrary, resists SOA because SOA requires IT to change its daily life
dramatically.
If you properly model SOA and start with real business services in your
organization (top-down), then 1) a currency converter is a very small business
function indeed and does not deserve much attention in the business (BTW, this
happens due to wide availability of such service); 2) business will notice you
right away because you are solving business problems, not IT tasks.
- Michael
"Shashank D. Jha" <[EMAIL PROTECTED]> 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]> wrote:
On 04/05/07, Shashank D. Jha <[EMAIL PROTECTED]> 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] > 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] > 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] [mailto:
> > > > service-
> > > > [EMAIL PROTECTED] On Behalf Of Peter Madziak
> > > > Sent: Saturday, April 28, 2007 12:08 PM
> > > > To: [email protected]
> > > > Subject: Re: [service-orientated-architecture] BPM & SOA
> > > >
> > > > Just to chime in with own $0.02..
> > > >
> > > > On 4/27/07, Steve Jones < [EMAIL PROTECTED]
> > > > <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 within a service
> > > > boundary) versus de-centralized control (i.e. choreography) realized
> > > > by a bunch of autonomous services doing their thing when they are
> > > > unleashed in the enterprise. It is in this sense that I prefer to talk
> > > > in terms of business protocols rather than business processes because
> > > > that term better reflects the knid of conversational state machines
> > > > that need to be consider when you dig into how a set of services might
> > > > converse.
> > > >
> > > > Peter
> > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On 25/04/07, Stefan Tilkov < [EMAIL PROTECTED]
> > >
> > > > <mailto:stefan.tilkov%40innoq.com> > wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > I was in a panel discussion at a conference this week, and was
> > > > > > surprised to notice there's still no consensus about whether or not
> > > > a
> > > > > > process engine (or rather, support for automated BPM) is a "must"
> > > > for
> > > > > > SOA.
> > > > > >
> > > > > > Well OK, not really surprised, but I still would be interested in
> > > > the
> > > > > > group's opinion.
> > > > > >
> > > > > > There were two views:
> > > > > >
> > > > > > 1. BPM and SOA are orthogonal concepts - you can do one without the
> > > > > > other. It's perfectly OK to have a SOA where there is no
> > > > BPM/Workflow/
> > > > > > BPEL engine involved anywhere. (This is my view).
> > > > > > 2. SOA is all about automating business processes via orchestration
> > > > > > of services, so a process engine is a necessary part of an SOA
> > > > effort.
> > > > > >
> > > > > > What do you think?
> > > > >
> > > > > Couple of thoughts from me
> > > > >
> > > > > 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
> > > > >
> > > > > 2) Business Process is only ONE of the ways that a business actually
> > > > > works, and I'd argue its one of the LEAST important areas. Take sales
> > > > > for instance, sure Siebel might have a "sales process" but the
> > > > reality
> > > > > is that the sales team will be, if they are any good, fixated on
> > > > their
> > > > > goals and targets.
> > > > >
> > > > > So what this means is that sure, from a technology perspective you
> > > > can
> > > > > do BPM without Web Services, but doing BPM without a conceptual
> > > > > framework of services is just Visual COBOL with all the flexibility
> > > > > and agility that COBOL implies. Fundamentally BPM is a
> > > > > procedural/process approach to design and implementation, something
> > > > > that has been roundly proven in IT to be a poor way to build complex
> > > > > systems.
> > > > >
> > > > > The only reason for the current fixation on biz process is that all
> > > > of
> > > > > the vendors top out at business process so that is what is the
> > > > > currently philosophers stone of IT.
> > > > >
> > > > > Steve
> > > > >
> > > > > >
> > > > > > Best regards,
> > > > > > Stefan
> > > > > > --
> > > > > > Stefan Tilkov, http://www.innoq.com/blog/st/
> > > > < http://www.innoq.com/blog/st/>
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
>
>
>
>
>
---------------------------------
Ahhh...imagining that irresistible "new car" smell?
Check outnew cars at Yahoo! Autos.
