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

From
MATHEWS, Tim <>
Date
2005-12-05T17:34:47+00:00
ID
Thread
RE: [soa-rm] Proposal: Reorganization of SOA-RM Draft for Better "Componentization"
Matt - I am not sure what point you are trying to 
make by this?  I agree with your premise of a bottom up effort, as 
this was one of the operating assumptions that was made from the 
beginning.

 

But, I am confident it is the business 
environment that is independent from the reference model.

 

TM

From: Matt MacKenzie [mailto:] 

Sent: Monday, December 05, 2005 11:58 AM
To: Sally St. 
Amand; 
Cc: 

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

Sally,

 

A reference model 
actually needs to be a bottom up effort.  We leave the ever so popular 
“top-down” approach to folks like ebSOA J

 

We’re creating a 
vocabulary and general understanding of what I hope we can call a discipline of 
computer science in the future.  This means, we need a durable reference 
model that is not dependent on the current business 
environment.

 

-matt

 

From: Sally St. 
Amand [mailto:] 
Sent: Monday, December 05, 2005 10:19 
AM
To: 

Cc: 

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

 

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

 

 

!