[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm] On UML
Hi all - A quick note, my corporate email server uses the "Last Name First Name" convention. My first name is Rebekah =) Rebekah > -----Original Message----- > From: tmathews@lmi.org [mailto:tmathews@lmi.org] > Sent: Thursday, March 24, 2005 3:35 PM > To: terl@serviceorientation.org; flinn@alum.mit.edu; Metz Rebekah > Cc: soa-rm@lists.oasis-open.org > Subject: RE: [soa-rm] On UML > > > The problem with including both the 'business analyst' and > the technical specialist is the polarized continuum of > expertise a 'business analyst' > may possess. For example, you may have a business analyst > who can't spell SOA (in jest, of course), and you may have a > business analyst/technical specialist who has a great deal of > technical expertise. > > Therefore, I am not a big fan of trying to go too far down > the continuum to meet the requirements of the non-technical > business analyst. This was an issue in ebSOA as well and > diverted a significant amount of time devoted to translating > the message. > > Thanks, > TM > > -----Original Message----- > From: Thomas Erl [mailto:terl@serviceorientation.org] > Sent: Thursday, March 24, 2005 3:20 PM > To: Don Flinn; Metz Rebekah > Cc: soa-rm@lists.oasis-open.org > Subject: Re: [soa-rm] On UML > > I agree with Don's request that we separately identify > business analysts as part of our target audience. > Service-oriented solutions certainly impact the domain of > business analysis and it is likely that many business > analysts will need a clear and non-technical (or > "less-technical") explanation of what constitutes a > service-oriented architecture and what distinguishes a > service-oriented solution from others. > > Further, it is stated in the charter that (among other > things) the documentation of the abstract framework in the > reference model "may be used as a basis for education and > explaining standards to a non-specialist." I would suggest we > elaborate on this point by further expanding upon item #5 in > Metz's list. > > A range of individuals may be involved in documenting SOA, > for example: > - Instructors or textbook authors that write about or > reference SOA. The content they produce is likely to be used > by educational institutions and consumed by students. > - IT authors that write about or reference SOA for mainstream > publications. > This content is often geared toward other IT professionals. > - Technical writers that produce in-house documentation for > organizations. > > Another documentation-related area in which the SOA-RM will > likely be used is in the creation of custom design standards. > This relates to items #2 and > #5 in Metz's list. Organizations that formalize in-house > standards or produce best practices or design principles > documents may seek guidance in our SOA-RM and/or an > implementation-specific variety. > > Thomas > > ----- Original Message ----- > From: "Don Flinn" <flinn@alum.mit.edu> > To: "Metz Rebekah" <metz_rebekah@bah.com> > Cc: <soa-rm@lists.oasis-open.org> > Sent: Thursday, March 24, 2005 8:29 AM > Subject: RE: [soa-rm] On UML > > > > Metz > > > > You have presented a good list of audience categories. I would like > to > > hone in on category 2. A Service Oriented Architecture is > focused on > > solving business problems. As a consequence the major player in > > designing an Architecture will be the business analyst. Thus if we > > don't produce a reference model that speaks to and is understood by > the > > business analyst - we will have failed. This does not mean that we > can > > or will neglect the other categories (after all is said and > done I'm a > > card-carrying techie). My point is, as technical people > for the most > > part, we have to make the effort to produce a document that speaks > > equally to the business analyst. > > > > Don > > > > On Thu, 2005-03-24 at 08:48 -0500, Metz Rebekah wrote: > >> 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 > >> > *********** > >> > > >> > > >> > > -- > > Don Flinn > > President, Flint Security LLC > > Tel: 781-856-7230 > > Fax: 781-631-7693 > > e-mail: flinn@alum.mit.edu > > http://flintsecurity.com > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]