[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm] On UML
Metz, that's a very useful list you've come up with. I would suggest you place it in and submit it as a separate document. Once we are in a position to begin documenting our reference model we can pull in content from supplementary documents. A "Target Audience" section comprised of a list such as this would likely be required. Thomas ----- Original Message ----- From: "Metz Rebekah" <metz_rebekah@bah.com> To: <soa-rm@lists.oasis-open.org> Sent: Thursday, March 24, 2005 5:48 AM Subject: RE: [soa-rm] On UML I am all for the using the simplest presentation for the intended audience. I do believe that we'll eventually need to reach into the UML toolbox to provide useful information for those that "design and implement of service oriented architecture." I wonder though, will we successfully reach others who are involved in SOA, say the executive who needs to make a business case decision for re-engineering business processes along SOA principles, by presenting what they perceive to be a technical model? Will they relegate it to the IT domain without further consideration? If we take Joe's recommendation to reach back to the charter, I see several potential categories of audience that we need to reach some agreement on: 1) Those that pay for SOA initiatives 2) Those that design SOA (or design according to service oriented principles) 3) Those that implement above the line services 4) Those that implement service oriented infrastructure 5) Those that document SOA 6) Those that must govern services and/or SOA 7) Those that must re-engineer their processes to align with a service oriented model 8) Those that want to sell service orientation (consultants and vendors) 9) Those that want to leverage the SOA-RM for further standards work. Looking at this list, we need to come to some common basis of SOA principles too. Most of us involved in the technical aspects of service oriented evolution are familiar enough with SOA principles to almost take them for granted, but reaching the larger audience, both technical and non-technical, beyond early adopters will probably require coverage of the very basics. Rebekah > -----Original Message----- > From: Duane Nickull [mailto:dnickull@adobe.com] > Sent: Wednesday, March 23, 2005 7:53 PM > Cc: soa-rm@lists.oasis-open.org > Subject: Re: [soa-rm] On UML > > My thoughts on UML and Concepts Maps are that it is best to > start with the simplest presentation (Concept map) and see if > we have a firm need for UML. A concept map often groups many > things that may not appear in the same UML diagram which > often make them easier to grok than UML. > > The position paper Matt and I submitted uses the concept maps > that we used in the W3C Web Services Architecture document. > Concept maps are easy to compose, however they can also be > the death of a standard since they are often very open ended. > It is very easy to keep adding concepts until you get > something that looks like the large concept map in the W3C > WSAG Technical Note. UML, by comparison, is far more strict > however leads to multiple views of the same things in > attempts to relay information about them. > > I encourage everyone to read the 3 different submissions so > far into the group to see how the concept/mind maps work and > analyze how they can also be open ended. > > Some basic modelling conventions for keeping things simple > are to use no more than 5-6 concepts per model, then layer > the more technical aspects in UML. You can use concept maps > and UML to show architectural patterns too. > > Let's start with concept/mind maps to model "what" we are > going to be dealing with, then delve into whether or not we > need UML based on that. > > Duane > > > -- > *********** > Senior Standards Strategist - Adobe Systems, Inc. - > http://www.adobe.com Vice Chair - UN/CEFACT Bureau Plenary - > http://www.unece.org/cefact/ Adobe Enterprise Developer > Resources - http://www.adobe.com/enterprise/developer/main.html > *********** > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]