[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm] On UML
I agree with Don's request that we separately identify business analysts as part of our target audience. Service-oriented solutions certainly impact the domain of business analysis and it is likely that many business analysts will need a clear and non-technical (or "less-technical") explanation of what constitutes a service-oriented architecture and what distinguishes a service-oriented solution from others. Further, it is stated in the charter that (among other things) the documentation of the abstract framework in the reference model "may be used as a basis for education and explaining standards to a non-specialist." I would suggest we elaborate on this point by further expanding upon item #5 in Metz's list. A range of individuals may be involved in documenting SOA, for example: - Instructors or textbook authors that write about or reference SOA. The content they produce is likely to be used by educational institutions and consumed by students. - IT authors that write about or reference SOA for mainstream publications. This content is often geared toward other IT professionals. - Technical writers that produce in-house documentation for organizations. Another documentation-related area in which the SOA-RM will likely be used is in the creation of custom design standards. This relates to items #2 and #5 in Metz's list. Organizations that formalize in-house standards or produce best practices or design principles documents may seek guidance in our SOA-RM and/or an implementation-specific variety. Thomas ----- Original Message ----- From: "Don Flinn" <flinn@alum.mit.edu> To: "Metz Rebekah" <metz_rebekah@bah.com> Cc: <soa-rm@lists.oasis-open.org> Sent: Thursday, March 24, 2005 8:29 AM 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]