[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm-ra] A general comment on the SOA RA
It's taken me a while to figure what it is about this discussion that disturbs me, but I finally got there: Why would we (or anyone) be doing this if we didn't understand implicitly that it was about conducting business? Perhaps we should be explicit about it up front once, but I don't think we need to be reminded about it, and with all the concerns we need to cover, I'm not in favor of spending more words on it to remind the reader. I don't think our audience needs it. What is the difference between Service Description and Service Definition? We defined Service in the RM. If we're gonna spend time on these differences, we'll have to make some reference to that distinction any time we use either term. If we're spend time on these differences, we'll have to make some reference to the distinction any time we use either term. The details of Service Implementation are, I thought, out of scope except as we describe what is needed for implementation. For instance, we'll say that a rights language is needed, but we don't say that this or that language from this or that organization should be used. I get really uncomfortable when it comes to any kind of specific alignment with BMM for instance. I'm assuming you mean OMG Business Motivation Model? I use the MDA and we use UML, but I don't think we need everything in their arsenal. I don't think its wrong to consider all this, but I'd need more important reasons to change our approach at this point. We spent a lost of effort settling on Views and Viewpoints, and I still think its best for the level of abstraction we are working. Cheers, Rex At 10:25 AM -0500 4/4/09, Lublinsky, Boris wrote: >Content-Type: text/HTML >X-NAIMIME-Disclaimer: 1 >X-NAIMIME-Modified: 1 > >I know you do, >The question is whether it reads this way. >I think that the isuue is mostly restructuring of the content. At >the moment all the ideas about real world effect, description, etc >do reflect some of this, but... >I would think, that it would be more appropriate to make this >statement upfront and then start referring to it throughout. >For example, service description can, then be structi\ured as: >Business service description, providing informataion for selecting >services, base on its business functionality and some of the >policies, that are relevant for this particular business solution. >Technical service description, relevant for building service consumer. > >Another piece, that is not covered at all is service definition and >service implementation. >Here again we could of talked about business decomposition and >defining services, based on the enterprise business processes and >aligning with BMM, which helps to define these processes. >On the service implemwntation, the issue is that you rarely create a >service from scratch - service implementation is typically a fairly >thin layer, rationalizing existing IT capabilities against >enterprise business models. There can be some content on this. > >Is this something that you see being usefull, or I am leading you >out to the left field? > > >From: Francis McCabe [mailto:frankmccabe@mac.com] >Sent: Fri 4/3/2009 6:02 PM >To: Lublinsky, Boris >Subject: Re: [soa-rm-ra] A general comment on the SOA RA > >Boris > I don't see why you felt that everything was IT-oriented. > > We have always felt that SOA was at that junction between business >and IT. > >Frank >On Apr 3, 2009, at 3:53 PM, Lublinsky, Boris wrote: > >> I have finally finished reading and realized where I had the biggest >> issue with this. >> The document equates SOA (for the main part) with a complex >> distributed >> system, leaving completely aside Business/IT alignment nature of SOA. >> Unless we stipulate from the very beginning, that services are >> representation of well-defined business artifacts, there is no >> difference between SOA and, for example, The Web. I would think that > > Web >> is even more complex. >> So, in my mind, >> >> "SOA can be defined as an architectural style promoting the concept of >> business-aligned enterprise service as the fundamental unit of >> designing, building, and composing enterprise business solutions. >> Multiple patterns, defining design, implementations, and deployment of >> the SOA solutions, complete this style." >> >><http://www.ibm.com/developerworks/architecture/library/ar-soastyle/>http://www.ibm.com/developerworks/architecture/library/ar-soastyle/ >> >> Similar definitions can be also find at: >> >><http://www.opengroup.org/projects/soa/doc.tpl?gdid=10632>http://www.opengroup.org/projects/soa/doc.tpl?gdid=10632 >>and >> indirectly >> at >><http://www.jot.fm/issues/issue_2008_11/column6/index.html>http://www.jot.fm/issues/issue_2008_11/column6/index.html >> >> Please, let me know if this makes sense? >> >> If it does, then the document lacks a few other things that can be >> easily added. But lets first agree on this slight change of a >> viewpoint. >> >> Boris >> >> >> The information contained in this communication may be CONFIDENTIAL >> and is intended only for the use of the recipient(s) named above. >> If you are not the intended recipient, you are hereby notified that >> any dissemination, distribution, or copying of this communication, >> or any of its contents, is strictly prohibited. If you have >> received this communication in error, please notify the sender and >> delete/destroy the original message and any copy of it from your >> computer or paper files. >> >> --------------------------------------------------------------------- >> To unsubscribe from this mail list, you must leave the OASIS TC that >> generates this mail. Follow this link to all your TCs in OASIS at: >> >><https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >> > > >The information contained in this communication may be CONFIDENTIAL >and is intended only for the use of the recipient(s) named above. If >you are not the intended recipient, you are hereby notified that any >dissemination, distribution, or copying of this communication, or >any of its contents, is strictly prohibited. If you have received >this communication in error, please notify the sender and >delete/destroy the original message and any copy of it from your >computer or paper files. -- Rex Brooks President, CEO Starbourne Communications Design GeoAddress: 1361-A Addison Berkeley, CA 94702 Tel: 510-898-0670
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]