Re: [soa-rm] Proposal: Reorganization of SOA-RM Draft for Better"Componentization"

["Gregory A. Kohring" <kohring@ccrl-nece.de>]

Sally,

With respect to your comments on Fig 1, I think you have misread this
diagram.

The arrows point in the direction of the dependency. Hence,
as I read it, everything in the box "Architecture Work" is "guided by"
the "Abstract Reference Model", not vice-versa. Similarly,
"SOA Implementations" are "constrained by" "Architecture Work", and
"Architecture Work" takes into account everything in the box "Input".
Finally, "SOA Implementations" "use" "Related Work".


As this diagram seems to be causing some confusion I would suggest
putting in a short paragraph explaining it...


-- Greg



Sally St. Amand wrote:
> 
> Frank
>  
> This is in response to your request on last week’s conference call, if
> anyone has comments speak now. I also think that the recent comments on
> clarifying sections are a reflection of my issues with the specification.
>  
> I agree with the majority of points made/described in ver 10. My issues
> are with what is not in this draft. Based on Fig 1 the Refe! rence Model
> is guided by Reference Architectures, Concrete Architectures, Profile &
> Related Models. They in turn account for requirements, motivation &
> goals. This is creating a Reference Model from the bottom up. I believe
> a Reference Model should reflect a top down approach.
>  
> The Reference Model needs to reflect the environment, the strategy and
> the priorities of the business/mission/collaboration.  This will impact
> the construction of services. A service is a business task or activity
> that is realized through technology. The draft does a good job of
> describing how that realization happens. But it doesn’t provide a
> sufficient link between processes and services. The draft makes the
> point that _the central focus of! SOA is the task of business
> function—getting something done._ A business process is made up of tasks
> and activities to achieve a goal (getting something done). The/ concept/
> of creating the service from the tasks and activities in a process is
> important. For example, where on the continuum of fine grained to coarse
> grained should a particular service be; this will affect interaction,
> reusability. The relationship between processes and services needs to be
> in the Reference Model.
>  
> While I saw that there is a note saying the glossary is still in flux,
> since one of the objective of the Reference Model is a vocabulary,
> having less in the glossary might be a better option. Is semantic
> integration a guiding principle of SOA? 
>  
> With respect to conformance there needs to be business results. That is
> an SOA should provide demonstrable mission accomplishments, e.g. ROI,
> match a competitors distribution channel. SOA is not a technology.
> Conformance should provide operational accomplishments, these should be
> measurable.
>  
> Sally
>  
>  
> !
>  
>  
>  
-- 
======================================================================
Dr. G.A. Kohring
C&C Research Laboratories, NEC Europe Ltd.
======================================================================