Lawrence, you ared doing a wonderful work! I have three questions to your post:
1) why a Business Service is a Business Service if it has zero business model elements, i.e. has no Business Service Subjects (in your definition)? 2) in "if a Service doesn't have these associations to objects in the business model, then it isn't a business service" - you, probably meant 'subjects' rather than 'objects', didn't you? 3) what does mean "Business Types"? - Michael From: "[email protected]" <[email protected]> To: [email protected] Sent: Monday, April 6, 2009 9:55:02 AM Subject: [service-orientated-architecture] Re: den Haan explains SCA If I can add to Michael's comments. In our -CBDI- SAE approach, we make the following statements, which are built in to our CBDI-SAE Meta Model for SOA. You can download this from http://www.cbdiforum.com/public/meta_model_v2.php (free on registration) The meta model contains a Business Modeling Package that defines various Business Modeling concepts, mainly those to which a Business Service can be usefully linked. (line 213) A Business Service is expected to handle the requirements of zero, one or more business model elements, that we call Business Service Subjects. The meta model currently enables a Business Service to handle the requirements of the following Subjects: • Business Processes • Business Capabilities • Business Types • Business Events • Business Rules • Business Policies. A Business Service can also be related to: • The Business Objectives that it supports (this can help justify the acquisition of the Service) • The Business Processes that it is expected to (or actually does) support, directly or indirectly (once again, this can be used to justify service acquisition) • A Business Domain. We later go on (in Appendix A1) to provide rules regarding how these associations place Business Services into spefic layers in the Service Architecture. So, if a Service doesn't have these associations to objects in the business model, then it isn't a business service. Our model permits infrastructure services and also the use of what we term Underlying Services as a mechanism to include other services (which I won't go into now...) Lawrence --- In service-orientated- architecture@ yahoogroups. com, Michael Poulin <m3pou...@.. .> wrote: > > Augusto, > > SOBA is interpreted as 'SOB Application' as well as 'SOB Architecture' in our > days. My comment relates to both. Why? Here is a short story: in Udi's BLOG > I asked - > MP: "what's the place/role of SOBA in SOMA?" > Tilak Mitra [co-author of 'Executing- SOA-Practical- Service-Oriented > -Architect', the book that discussed the recent update of IBM SOMA]: "SOMA > provides prescriptive techniques and guidance on how to extend the SOMA > method to develop SOBA's" (http://www.mail- archive.com/ service-orientat > ed-architecture@ yahoogroups. com/msg08468. html) > > If we still lock ourselves in IT, we think that a collection of technical > services can constitute a business application. I disagree. I insist on that > business application has to be constructed based on business services some of > which may be implemented using technical services. A service becomes business > service not because Business uses it but because it implements business > function, feature, service, or process. If a SW component just carries > business data, it is a driver/object, not a service because it implements > technical task, not a business task. > > If SOBA is constructed by SOMA where 'Interface=Service, Service=Web Service > and Business=Process' , I do not think it is a service-oriented business > application. It is, probably, an aggregation of integrated applications > utilising Web Services as the integration technology; whether it implements > any business functionality or not is an open question. Use of Web Services > does not automatically constitute service, and, especially, service-oriented > business service. > > - Michael Poulin
