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