RE: [soa-rm] On UML

[<tmathews@lmi.org>]

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:terl@serviceorientation.org] 
Sent: Thursday, March 24, 2005 3:20 PM
To: Don Flinn; Metz Rebekah
Cc: soa-rm@lists.oasis-open.org
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
>