+1 - Michael
----- Original Message ---- From: Steve Jones <[EMAIL PROTECTED]> To: [email protected] Sent: Tuesday, October 7, 2008 3:52:18 AM Subject: Re: [service-orientated-architecture] Re: Linthicum on Metadata & SOA 2008/10/6 Stanley Stanev <[EMAIL PROTECTED] com>: > Yes, let it be MIR > > Here, Michael, an example I had in mind. > > I know a company that 7 years ago had just 1 product to offer that and was > their SEO. There were doing great, the SEO product had a lets call it bpSEO > (business process SEO) and again that all there were selling. > > 4 years ago they decided to build a generic online shopping cart to help any > store owner out there sell online, and their existing bpSEO with few > massages became just one of the services of the shopping cart to help stores > rank better with the search engines. So the bpSEO became srvSEO (service > SEO) and was a part of a much bigger business process. That is when they > came up with their shopping cart at searchfit.com Or to put it another way. Originally they offered one service (SEO) now they offer a set of services and combine these using another service (the shopping cart) Where is the business process? > > Now since bpSEO is srvSEO they are willing to start selling srvSEO alone > while keeping it well encapsulated, so they don't become slaves as you > described and still make more business. > > Or think when mergers happen or a bigger company A buys smaller one B. Don't > A have to massage the business processes of A and include them as services > to a probably much more sophisticated processes of B? Having done SOA based M&A activities what I'd say is that this is where SOA really wins. Firstly by helping you take a business boundary view so you can see the bits where standardisation makes sense (non-differentiatin g services) and where keeping the previously unique concepts makes sense (differentiating services). A process view will confuse the two and make that work harder. Steve > > - Stanimir > > Michael Poulin wrote: > > We are all for MIR, Stanimir. > > As Steve outlined, a process is only an IMPLEMENTATION, an internal thing > for the company; it exists totally under company control. Nobody, nobody at > all, can be intersected in a use of your internal process as is (except for > burglars :-) ) because it does not exist for external world. Only two > things are exposed: business functionality (business service, function, or > feature) and related Real World Effect (RWE). > > The same principle is put under concept which hides implementation from the > consumers exposing only interface and business functionality/ RWE. HOW this > RWE is reached, nobody's business. This is where internal processes work. > > Even if somebody likes how you are doing things, you can sell only the > results of your activities. If you sell the activities themselves, then > either they are moved to the buyer (you can sell/buy a car assembling plant, > i.e. a lot of processes) or you become a slave. Even in the example with the > plant, the plant is the PRODUCT, i.e. RWE. I would be very interested in > finding an example of one internal process sold... as a process. > > As of Cloud Computing, I am not a fun of this idea because it is represented > recklessly. I put some comments about it in my BLOG > (http://it.toolbox. com/blogs/ so-enterprise- blog/cloud- computing- > before-jumping- into-the- cloud-think- if-you-can- get-out-27444), > and can say only - beware of Cloud; a Black Whole may be behind it. > > - Michael > > ----- Original Message ---- > From: Stanley Stanev <[EMAIL PROTECTED] com> > To: service-orientated- architecture@ yahoogroups. com > Sent: Friday, October 3, 2008 12:24:57 AM > Subject: Re: [service-orientated -architecture] Re: Linthicum on Metadata & > SOA > > Michael, > > I agree with you. Could one process (business activity) of enterprise A be > of an interest to enterprise B? I think it could happen and it happens.. So > then enterprise B could ask A to expose that process as a service and use it > in its own process. So that process of A becomes a service to B. How > granular it could be it is a different story. > > That is what exactly I like about SOA. Things could grow rapidly. New > companies could sprout from nowhere, pick good services and build quickly > their processes. And even further...then they can sell those processes to > new companies as services...the sky is the limit...and here you go a real > cloud computing. > > P.S. "Stani" means "become" and "mir" means "peace", so you got my name :) > > - Stanimir > > Michael Poulin wrote: > > Stanimir and Denni, > though I used to say that service and process are interchangeable, I have > to admit - I did a compromise, and have to support Steve in this discussion. > > At the level of enterprise business model, there are only business services > and, depending on their granularity, different processes can appear between > services if needed. For example, if Accounting Service is split into > Receivable, Payable, and General Ledger, they may interact in one process; > if Receivable Payable are joined, it is another process between the join and > General Ledger. > > That is, service goes first, process goes second. > > - Michael > P.S. Stanimir, may I ask what 'stani' stands for? > ----- Original Message ---- > From: Dennis Djenfer <[EMAIL PROTECTED] se> > To: service-orientated- architecture@ yahoogroups. com > Sent: Monday, September 29, 2008 9:57:37 PM > Subject: Re: [service-orientated -architecture] Re: Linthicum on Metadata & > SOA > > A service could be a container for a process, or a process could use a > service, or a service could be used by an application, or a service could be > a container for business object, or something else. I don't see where the > constraints are that says a service should have a certain scope or be > modeled in a certain way. Sure, we can argue about which modeling approach > is the best, but isn't it still a service oriented architecture if we are > able to map our architecture to the concepts in the SOA-RM? > > // Dennis Djenfer > >
