Anticipated Audience (WAS RE: [soa-rm] On UML)

["Chiusano Joseph" <chiusano_joseph@bah.com>]

Perhaps we can start with what is included in our charter and go from
there:

Anticipated audience 

Anyone involved in the design, documentation or implementation of
Service Oriented Architectures (SOA's) or components thereof, regardless
of the standards body under which the work is sanctioned.

Joe

Joseph Chiusano
Booz Allen Hamilton
Visit us online@ http://www.boozallen.com
 

> -----Original Message-----
> From: Metz Rebekah [mailto:metz_rebekah@bah.com] 
> Sent: Wednesday, March 23, 2005 5:33 PM
> To: soa-rm@lists.oasis-open.org
> Subject: RE: [soa-rm] On UML
> 
> Ken started an *excellent* list of questions that will help 
> to flesh out the SOA RM and our assumptions about it.  Based 
> on that discussion thread, the UML vs. mind-mapping 
> discussions and the technical vs.
> non-technical discussion, I suggest that we should first 
> agree on *who* the intended audiences of the reference model 
> are?  Having a clear definition of intended audience will 
> direct the content, representation and tone of the 
> components/sections/portions of the reference model.  It may 
> also resolve the editorial approach discussions as well.
> 
> I don't believe that saying technical and non-technical 
> audiences is sufficient clarification.  There are several 
> types of "techies" that all require different types of 
> information.  Are we distinguishing between them?  For the 
> non-technical, are we providing material only at the 
> executive primer level?  I know that when I first start 
> exploring a reference model or standard, I would find it 
> tremendously useful to understand what the target audience is 
> and to frame the problem somewhat before presenting the solution.
> 
> 
> With specific reference to Ken's original email ...
> <Quote>
> Might it not be good to start by listing the capabilities an 
> SOA enables?  
> </Quote>
> 
> I would add that we consider both technically and 
> business-oriented capabilities.
> 
> Again, my 2 cents.
> 
> 
> Rebekah
> 
> > -----Original Message-----
> > From: Schuldt, Ron L [mailto:ron.l.schuldt@lmco.com]
> > Sent: Wednesday, March 23, 2005 4:19 PM
> > To: Don Flinn; tmathews@lmi.org
> > Cc: frank.mccabe@us.fujitsu.com; soa-rm@lists.oasis-open.org
> > Subject: RE: [soa-rm] On UML
> > 
> > I concur with Don's assessment of the situation. The SOA-RM 
> needs to 
> > communicate to both the non-technical and technical audiences.
> > 
> > If others agree, then perhaps we need a section 
> specifically oriented 
> > to the non-technical and another section to the technical.
> > 
> > My 2 cents.
> > 
> > Ron Schuldt
> > Senior Staff Systems Architect
> > Lockheed Martin Enterprise Information Systems
> > 11757 W. Ken Caryl Ave.
> > #F521 Mail Point DC5694
> > Littleton, CO 80127
> > 303-977-1414
> > ron.l.schuldt@lmco.com
> >  
> > 
> > -----Original Message-----
> > From: Don Flinn [mailto:flinn@alum.mit.edu]
> > Sent: Wednesday, March 23, 2005 2:08 PM
> > To: tmathews@lmi.org
> > Cc: frank.mccabe@us.fujitsu.com; soa-rm@lists.oasis-open.org
> > Subject: RE: [soa-rm] On UML
> > 
> > 
> > One of the initial points that we need to agree upon is who is the 
> > target audience(s) for the SOA RM.  SOA falls under what may be 
> > described as a "disruptive technology".  When a business 
> adapts an SOA 
> > it will change the way it does business in a number of ways.  
> > (Anecdotal information from business leaders is that they 
> are hesitant 
> > about employing the SOA model, not because of the technical expense 
> > but because of expenses related to change in major parts of their 
> > business
> > model.)  One resultant change that is envisioned is that a 
> business's 
> > service oriented architecture will be strongly influenced, 
> if not led, 
> > by business architects, supported by technical architects.
> > 
> > If the TC agrees with this observation then, arguably, a major 
> > component of the audience will be the non-technical person.
> > 
> > Don
> > 
> > On Wed, 2005-03-23 at 12:43 -0500, tmathews@lmi.org wrote:
> > > Frank -
> > > 
> > > I think I see your point.  The target audience for this
> > specification
> > > would be the determining factor.  If the audience of the 
> SOA RM was
> > the
> > > non-technical strategic thinker, then UML certainly would
> > 'not' be the
> > > answer.  I do feel, however, that since this is a SOA RM, denoting
> > both
> > > architecture 'concepts' and RM as the end objective, the
> > deliverable
> > > will ultimately provide better value to all of us 'techies' 
> > if using a
> > > common standard (wonder that!) to represent the model.
> > > 
> > > I would also argue that UML helps to funnel complex mind maps with
> > 'many
> > > relationships' into something more tangible, easier to
> > grasp for many.
> > > We want to avoid abstraction to the point of obfuscation of
> > concrete
> > > relationships wherever possible.
> > > 
> > > I believe the mind maps to be a viable solution to expand further 
> > > 'predicate logic' (as you put) in the informal model.  Not
> > sure I see
> > > your number 3 as a disadvantage.
> > > 
> > > TM
> > > 
> > > -----Original Message-----
> > > From: frank.mccabe@us.fujitsu.com
> > [mailto:frank.mccabe@us.fujitsu.com]
> > 
> > > Sent: Wednesday, March 23, 2005 12:11 PM
> > > To: soa-rm@lists.oasis-open.org
> > > Subject: [soa-rm] On UML
> > > 
> > > The issue with UML are
> > > 1. A somewhat spurious sense of formality. In fact, the
> > semantics of
> > > even UML 2.0 are less than clear on even the basics such as
> > what does
> > > inheritance mean?
> > > 2. The strong bias towards one relationship: isa, when in
> > reality we
> > > will need a great many more relationships: describes, has, owns, 
> > > implements, responsible-for, correlates, etc. etc.
> > > 3. The strong bias (on the part of certain vendors) to
> > automatically
> > > generating code from UML, resulting in a tendency to 'go concrete'
> > very
> > > quickly.
> > > 
> > > An alternate suggestion: mind maps. A mind map is simply a
> > collection
> > of
> > > concepts and relationships connecting them. V. simple, and in my 
> > > experience v. flexible. It is also possible to develop rigour by
> > mapping
> > > into predicate logic.
> > > 
> > > Frank
> > > 
> > > 
> > --
> > Don Flinn
> > President, Flint Security LLC
> > Tel: 781-856-7230
> > Fax: 781-631-7693
> > e-mail: flinn@alum.mit.edu
> > http://flintsecurity.com
> > 
> > 
>