You are right, the article was aimed to the IT people and asked them to look at
what they are doing from the business perspectives.
You are also right in that many business people, especially in the business
operation sector, do not see or know the business services they deal with and
cannot distinguish between the business interface and the business service. SO,
to achieve real benefits of SOA, the bu sines has to start thinking in its
business model categories rather than in IT tools terms. I am trying to change
conversations with my business clients and divert them from mentioning
databases and Web pages in describing what and how they want things to be
served to them.
Finally, it is commonly admitted that SOA RM is to high and abstract to be used
by BA directly. This is why OASIS has another initiative on-the-go - the SOA
Reference Architecture standard which is supposed to give enough 'instruments'
to BAs to may their job done in-line with SOA concepts.
- Michael
"Shashank D. Jha" <[EMAIL PROTECTED]> wrote:
Thanks for a insightful article.
But still it fails to convince me that ---
Quoting from your article..start
Thus, SOA may be viewed as a technical architecture built around an enterprise
business model, not around isolated business procedures or just-this-moment
operational needs. SOA is supposed to address current and upcoming business
requirements, diversity, which is limited by a particular business model. If
the business model is unclear in the organization, Services and Processes, SOA
won't help but rather will confuse the company a lot.--end
It makes a great statements but fails to emphasize the need to business people
or Analysts to adopt SOA to model or develop business processes.
All the examples and contents attempts to prove that SOA is IT initiative and
IT solution to allow business agility.
Overall this article again demonstrate that SOA is to make IT systems to adapt
o business requirements.
As iterated by me earlier sometimes back in the same forum that SOA-RM by OASIS
is too Raw and Abstract and to be useful to an BA.
I still of my view that SOA is about making flexible, easy to change, manage,
controlling granularity of software service etc. based on input from business
initiative/ process.
Business needs business process modeling and changes in the same must be able
to execute over underlying infrastructure with as much ease as possible and
this is where SOA comes into picture.
regards,
Shashank D. Jha
On 5/6/07, Michael Poulin <[EMAIL PROTECTED]> wrote:
Shashank,
I have tried to put Steve's words in a form of article, actually, related to
the SOA RM standard. I think, it will help you to decouple your understanding
from the exclusive IT perspectives.
(http://java.sys-con.com/ read/314124.htm)
- Michael
Steve Jones <[EMAIL PROTECTED]> wrote:
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/>
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
>
>
>
>
>
---------------------------------
Sucker-punch spam with award-winning protection.
Try the free Yahoo! Mail Beta.
---------------------------------
Don't pick lemons.
See all the new 2007 cars at Yahoo! Autos.
