Hi all -
A quick note, my corporate email server uses the "Last Name First Name"
convention. My first name is Rebekah =)
Rebekah
> -----Original Message-----
> From: [mailto:]
> Sent: Thursday, March 24, 2005 3:35 PM
> To: ; ; Metz Rebekah
> Cc:
> Subject: RE: [soa-rm] On UML
>
>
> The problem with including both the 'business analyst' and
> the technical specialist is the polarized continuum of
> expertise a 'business analyst'
> may possess. For example, you may have a business analyst
> who can't spell SOA (in jest, of course), and you may have a
> business analyst/technical specialist who has a great deal of
> technical expertise.
>
> Therefore, I am not a big fan of trying to go too far down
> the continuum to meet the requirements of the non-technical
> business analyst. This was an issue in ebSOA as well and
> diverted a significant amount of time devoted to translating
> the message.
>
> Thanks,
> TM
>
> -----Original Message-----
> From: Thomas Erl [mailto:]
> Sent: Thursday, March 24, 2005 3:20 PM
> To: Don Flinn; Metz Rebekah
> Cc:
> 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" <>
> To: "Metz Rebekah" <>
> Cc: <>
> 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:]
> >> > Sent: Wednesday, March 23, 2005 7:53 PM
> >> > Cc:
> >> > 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:
> > http://flintsecurity.com
> >
>
>
>
