On 05/05/07, 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.
Only if you are, like most techies, starting at the bottom and working
up. Like I said elsewhere, GE provides a SERVICE to the market,
namely the whole entire shebang that is GE. Most companies have HR
and Finance, these offer SERVICES to the rest of the business, indeed
many companies and governments are looking at shared services in just
these areas.
The problem with your statement, from my perspective, it that its a
very technology view on what a service is and very oriented towards
what the current technology stacks are about. I've found that if you
talk to the business in terms of their Sales, Finance, Logistics,
Procurement, etc, etc SERVICES then they really are rather interested.
> 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?
If you are doing the bottom up approach then its clearly the later,
however my argument is that you are looking at the business through
the eyes of a technology stack, and not actually looking at the
business.
> So you wish that business people to work with lesser abstraction based on
> SOA!!
Nope, I want a higher abstraction based on Business Services. You are
viewing the world via a technology stack and assuming that this is
what the business is. Taking "order to cash" as an example, what is
that? There could be 900 possible steps in a decent sized companies
"end-to-end" process, but a Business Service approach could quickly
identify the linked KPIs so you can say to the head of Logistics AND
the CFO that the issue is down to the cost saving in Logistics because
it means orders are bulked together which delays the payment. Using a
service and goal based approach can help you identify these competing
business metrics.
Service is only fine grained if you start from the bottom and work up.
That is the traditional technology approach.
> And this is a new idea supported by Microsoft, then this has lesser chances
> of success.
Also by IBM and lots of the consultancies.
>
> 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.
Your version most certainly is an IT one, and it isn't architecture.
>
> 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/>
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
>
>
>
>
>
