RE: [soa-rm] On UML

[Rex Brooks <rexb@starbourne.com>]

There is no question that the audience needs to be considered, and in 
the course of developing a reference model, I think that the criteria 
we adopt to qualify requirements and the criteria we adopt to assess 
whether our specification satisfies those requirements ought to form 
a compelling argument for the executives who need to make the 
business case for SOA adoption as well as the others listed.

However, those arguments will be much more convincing if they are 
based on testable, trackable methods which a sound basis in UML 
provides. I agree that consensus on basic SOA principles is required. 
So far I have read nothing in the materials presented thus far that 
isn't congruent with my own understanding of SOA principles. In fact, 
with such material to hand, I would expect that our tasks would be 
considerably streamlined.

Ciao,
Rex

At 8:48 AM -0500 3/24/05, 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
>>  ***********
>>
>>


-- 
Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-849-2309