OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm message

[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]