<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:]
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
!
