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

["Sally St. Amand" <sallystamand@yahoo.com>]

<Quote>

Our audience for the SOA-RM reference model is much broader and more "generic" in that we cannot anticipate all of the potential uses/users of the reference model.

<Quote>

 

Which is why I used business/mission/collaboration. It depends on what is the purpose for using the RM. My point is the initating actvity for the RM should be a concept (a top down driver), it should not be abstracted from more concrete forms.

 

Sally

Chiusano Joseph <chiusano_joseph@bah.com> wrote:

<Quote>

The Reference Model needs to reflect the environment, the strategy and the priorities of the business/mission/collaboration.

</Quote>

 

This begs the question: Which business/mission/collaboration? (meant to be rhetorical, emphasizing that we cannot select this)

I actually believe that a reference model in our case should be mostly (if not completely) devoid of such aspects, and the *usage* of the reference model should reflect the environment, the strategy and the priorities of the business/mission/collaboration in which it is employed. However, I believe that reference architectures will be more closely related to these aspects, as they are closer to concrete architectures than the reference model is.

 

I anticipate that there will be more progress on this when we create one or more reference architectures in our TC, and connect the SOA Blueprints to our work.

 

As a quick parallel, in current version of the FEA Data Reference Model (DRM) (currently in review by the US Office of the President) we have included many details on environment, business, mission, etc. - however, for the DRM we have a very specific audience (primarily but not exclusively the US federal government agencies) who require such guidance from us. Our audience for the SOA-RM reference model is much broader and more "generic" in that we cannot anticipate all of the potential uses/users of the reference model.

 

Joe

 

Joseph Chiusano

Associate

Booz Allen Hamilton

 

700 13th St. NW

Suite 1100

Washington, DC 20005

O: 202-508-6514 

C: 202-251-0731

Visit us online@ http://www.boozallen.com

 

---

From: Sally St. Amand [mailto:sallystamand@yahoo.com]
Sent: Monday, December 05, 2005 10:19 AM
To: frank.mccabe@us.fujitsu.com
Cc: soa-rm@lists.oasis-open.org
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

 

 

!