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


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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]