[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm] On UML
If the goal is to cover all of these different levels, then a simple model will not suffice. What you are describing here is the need for a multi-level, multi-view model with increasing resolution as you traverse from level to level. (By increasing resolution, I mean concepts which might be important at the "developer" level will not even appear at the "CIO" level.) Is it possible to capture such a model using a "simple" modeling language? At any rate, I think you have a valid point, namely we need to fix the goal (multi-level model vs single-level model vs ?) as this may put more constrains on how the TC should operate and what tools are appropriate. Cheers, Greg 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 >>*********** >> >> > > -- ====================================================================== G.A. Kohring C&C Research Laboratories, NEC Europe Ltd. ======================================================================
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]