On 10/05/07, Jerry Zhu <[EMAIL PROTECTED]> wrote: > > > > > > > Steve, I do not blame you about Business Process. It > bogs down what is BP. I bet ten people will say ten > versions. I define BP as "a set of related tasks to > accomplish a goal. it begins and ends with customer to > deliver a product and service." There are other > processes like management process, support process but > they are not BP. So BP is by definition customer > facing. Does that kind of BP cover your "marketing > facing services"?
As the implementation bit yes, but the key bit for me is as you said "begins and ends with a customer" and its that bit which the customer cares about. I'm not saying BP doesn't exist, just that it isn't as important as the current tech community think and that it is the implementation approach rather than being the architectural approach. > > I don't understand why people mean SOA IT only, SOA > is as much IT as business at the same time. The scope > of SOA units are not customer facing but are about its > implementation. There might be alternative > implementations. But SOA beneifts have been talked > well enough. What I mean is that there is a, large, body of people who look at SOA as being the lipstick on the pig of IT, its a thin veneer (ala EAI, but now with added XML and HTTP) for exposing that IT estate. This is the SOA that is IT only, and its not much better than the previous generations of IT and certainly isn't a game changing exercise. > > BP serves the purpose of cusotmers which is strategic > to the business. SOA serves the purpose of BP hence > operational. The former's IT aspect is BPM the > latter's business aspect is business subprocess. BP is not always strategic to the business, infact I'd almost be inclined to say that BP is dominant in the non-strategic areas of business (e.g. backoffice). SOA 4 IT serves the stack based view of BP(M) but it is certainly possible to model at a higher level of abstraction than either SOA 4 IT or BP(M) which is the Business SOA that I bleat on about. > > So SOA is not just dust but business capabilities > enabled by IT and made accessible and reusable by IT. Which to me is the dust, because we've been there, done that and failed a whole load of times. CICS was the same, MVS (IIRC) was the same, CORBA was the same, EAI was the same, DCOM was the same and now we have WS. For SOA to actually matter it must change the way people think, and neither BPM nor SOA 4 IT is capable of achieving that. Grumpy Steve > > Jerry > > --- Steve Jones <[EMAIL PROTECTED]> wrote: > > > I have to disagree here Jerry, Business Process is > > a long way away from being the only way that value > is _generated_ within a business. When people > > interact with businesses they tend to interact at > > specific points, these tend to be marked, and indeed > referred to as the "market facing services" of > > the organisation. > > > > Viewing SOA as just about the dust at the edges > > misses the real point of SOA > > which is that by using services to model _business_ > > you can understand what > > different approaches are required in different area. > > BPM and SOA, if driven > > from a technical perspective, will fail to deliver > > any real benefits to > > organisations. Technology is a secondary concern, > > the main goal is changing > > the way people think about IT. If SOA just aims to > > be the dust while BPM is > > the business then it will be just as successful as > > BPM was _before_ SOA and > > as EAI was in controlling that dust. > > > > > > http://service-architecture.blogspot.com/2007/05/soa-isnt-about-technology.html > > I tried to sum up what I mean in two pictures. > > > > Steve > > > > > > On 07/05/07, Jerry Zhu <[EMAIL PROTECTED]> wrote: > > > > > > 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] > > <shashank.dj%40gmail.com>> > > > 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] > > <m3poulin%40yahoo.com>> > > > > 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] > > <jones.steveg%40gmail.com>>* > > > wrote: > > > > > > > > > > On 05/05/07, Shashank D. Jha > > > > <[EMAIL PROTECTED] > > <shashank.dj%40gmail.com><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. > > > > > > > > === message truncated === > >
