[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm] On UML
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]