RE: [soa-rm] On UML

["Metz Rebekah" <metz_rebekah@bah.com>]

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