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- > > > > > > 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]<jones.steveg%40gmail.com>> 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]<john.evdemon%40microsoft.com>> 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]<service-orientated-architecture%40yahoogroups.com>[mailto: service- > > > > > > [EMAIL PROTECTED]<orientated-architecture%40yahoogroups.com>] On Behalf Of Peter Madziak > > > > > > Sent: Saturday, April 28, 2007 12:08 PM > > > > > > To: [email protected]<service-orientated-architecture%40yahoogroups.com> > > > > > > Subject: Re: [service-orientated-architecture] BPM & SOA > > > > > > > > > > > > Just to chime in with own $0.02.. > > > > > > > > > > > > On 4/27/07, Steve Jones < [EMAIL PROTECTED]<jones.steveg%40gmail.com> > > > > > > <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]<stefan.tilkov%40innoq.com> > > > > > > > > > > > <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.
