I see some conceptual confusion here. Business process outcomes in the form of produce/service delivered is not the same as SOA services. Now here product/service refers to customer value created and delivered. This value has nothing to do with procedures or activties but is measured by the external customer that varies from customer to customer. Customer (external) value is created, by definition, only by business processes not by smaller granualities such as subprocesses, procedures or activities.
These smaller units can be captulated into SOA services to be assembled and reassembled to form new business processes. Therefore in this context, SOA service is a function not a intangible value. I think this distinction is not only politically correct but also convenient both in business and technical sense. Jerry --- "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]<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. > > > > 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]<jones.steveg%40gmail.com>> > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 04/05/07, Shashank D. Jha > <[EMAIL PROTECTED]<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- > > > > > > === message truncated ===
