RE: [soa-rm] On UML

[Don Flinn <flinn@alum.mit.edu>]

Metz

You have presented a good list of audience categories.  I would like to
hone in on category 2.  A Service Oriented Architecture is focused on
solving business problems.  As a consequence the major player in
designing an Architecture will be the business analyst.  Thus if we
don't produce a reference model that speaks to and is understood by the
business analyst - we will have failed.  This does not mean that we can
or will neglect the other categories (after all is said and done I'm a
card-carrying techie).  My point is, as technical people for the most
part, we have to make the effort to produce a document that speaks
equally to the business analyst.

Don

On Thu, 2005-03-24 at 08:48 -0500, 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
> > ***********
> > 
> > 
> 
-- 
Don Flinn
President, Flint Security LLC
Tel: 781-856-7230
Fax: 781-631-7693
e-mail: flinn@alum.mit.edu
http://flintsecurity.com