Re: [soa-rm] On UML

[Thomas Erl <terl@serviceorientation.org>]

Metz, that's a very useful list you've come up with. I would suggest you 
place it in and submit it as a separate document. Once we are in a position 
to begin documenting our reference model we can pull in content from 
supplementary documents. A "Target Audience" section comprised of a list 
such as this would likely be required.

Thomas

----- Original Message ----- 
From: "Metz Rebekah" <metz_rebekah@bah.com>
To: <soa-rm@lists.oasis-open.org>
Sent: Thursday, March 24, 2005 5:48 AM
Subject: RE: [soa-rm] On UML


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