|
The
issue that has been raised with respect to an alignment between data reference
models and service reference models has to do with interface between what is
known (and encoded as computer data and computer programs) and what is
unknown.
In the quote (from
Joe Chiusano: "I will use the term "business interface" to imply the
presence of a technical interface, plus business-level details about how a
service fits within an organization's operations, the general benefits that can
be realized from using the service, how it fits with the organization's
strategic plans and goals, what organizational units may most benefit from it,
etc"
it is
nice to see that the paradigm as evolved so far and has some much value and
potential value. Clearly we are thinking through most of the issues very
well.
But
what when something truly unexpected is happening.
The emergence of meaning in the situation (where "situation" is an
immediacy and "context" is a categorization of types of past interpretations of
immediacy - or something like that) is largely our weakness today. Our
entire information science structure is based on what is known.
One
pretends as if the contextual categorization finishes the problem, but
observation tells us that autonomous contextual categorization by computer
programs is a weak science at best. Part of the problem is that what is
best about semantic extraction tools is not well understood at the funding and
policy levels. But part of this problem is that the extraction of
"semantics" from computer data is not the sameAs a human or human community
looking at a situation with an open mind.
The
DRM could introduce this problems is one which is an open problem needing some
additional work.
The
SOA RM and several of the OASIS standards attempts to address the problem of how
information structure comes into existence as data in computers and computer
programs.
The
key to understanding the point about "external interfaces" is that information
structure from that external interface needs to be formed into data and or
computer programs. Is this how you see it, Roy?
In
summary: The scope of a federal data reference model may need to align
more fully with the SOA RM in the case where the situation has novelty,
uncertainly, incomplete information, and in-determinacy. This can be done
using the OASIS BCM standard (recently adopted by OASIS) where human choice
points allow the quick induction of information structure and the
interpretations by humans of the patterns of data seen from a process that
involves SOA blueprints.
Everything else also needs to work, ie the data and computer programs
that are about what is known. This means federation of data resources from
different communities of interest, repositories where information models and
ontology are available, and registries of service
indicators.
I believe that it should. More specifically, which type of interface
(technical or business) depends on whether a service is primarily a technical
service or a business service. Or rather, whether it is primarily
technical-"facing" or business-"facing".
In my explanation below, I will use the term "technical interface" to
mean an an electronic "contract" between two services, such as WSDL (with full
knowledge that WSDL only provides part of what is needed in many cases). I
will use the term "business interface" to imply the presence of a technical
interface, plus business-level details about how a service fits within an
organization's operations, the general benefits that can be realized from
using the service, how it fits with the organization's strategic plans and
goals, what organizational units may most benefit from it,
etc.
An example of a "technical-facing" service would be a security service
that enables services to be authenticated/authorized by other
services/systems/data sources through the provisioning of security tokens
(Kerberos, SAML, etc.). Such a service may, for example, be invoked by a data
service (think Enterprise Information Integration (EII) and federated queries)
in order to enable it to be authenticated and authorized (if all goes
well) by the data source. I would assert that the interface between the
data service and the security service is more of a technical interface than a
business interface, as it reflects an electronic "contract" between the two
services (the data service and the security service), and there is no need (or
at least not as great a need as with business-facing services) to provide a
business interface.
An example of a
"business-facing" service would be a "shipment visibility" service that is
part of a supply chain that provides the ability to know the location *and
condition* (which is very important!) of cargo at any point in a supply chain.
Such a service could, for example, enable a supply chain participant to know
that certain cargo is damaged earlier than they otherwise would know (i.e.
before the ultimate customer receives the cargo), thereby providing the
participant with an opportunity to correct the situation as soon as
possible. If this links to an operational performance measure/goal for
the participant (e.g. decrease percentage of damaged goods on arrival by X
percent this quarter), then that service is also supporting key operational
needs, and potentially providing the organization with a distinct strategic
advantage.
I would assert
then that such a service (which I like to call an "operational" service, as it
does not imply bias to commercial entities) requires both a technical
interface and a business (operational) interface. The business (operational)
interface would primarily be in written (human-readable) form, and would
include such details as those I outlined above: how the service
fits within an organization's operations (the "shipment visibility" service
would be most closely aligned with its Supply Chain operations), the general
benefits that can be realized from using the service (decreased amount of
damaged goods on arrival, which ultimately leads to greater customer
satisfaction), how it fits with the organization's strategic plans and goals
(greater customer satisfaction can provide strategic advantages), what
organizational units may most benefit from it (those that interface with
Supply Chain operations), etc.
Thanks,
Joe
Joseph Chiusano
Associate
Booz Allen Hamilton
700 13th St. NW, Suite 1100
Washington, DC 20005
O: 202-508-6514
C: 202-251-0731
UNCLASSIFIED
Hi,
In regard to the
definition of service, shouldn't it include the notion that the service
has to be exposed to the external environment by a technical and business
interface?
Vr,
Roy
Hi -
As a further update, here is the definition of SOA that
was presented at The Open Group conference last week (and which we have shared
with the OMG).
SOA is an architectural style that
supports service orientation
•Service orientation
A
way of a way of thinking in terms of services and service based development
and the outcomes that services bring
•Service
A logical
representation of a repeatable business activity that has a specified outcome
(e.g., check customer credit; provide weather data, consolidate drilling
reports), is self-contained and maybe composed of other Services. It is a
black box to consumers of the Service
•Architectural
Style
The combination of distinctive features in which Enterprise
Architecture is done, or expressed
•The SOA Architectural style’s
distinctive features:
– Based on the design of the services
comprising an enterprise’s
(or inter-enterprise)
business processes. Services mirror real-world
business activity
– Service representation utilizes business
descriptions. Service
representation requires
providing its context (including business
process,
goal, rule, policy, service interface and service
component)
and service orchestration to implement
service
– Has unique requirements on infrastructure. Implementations
are
recommended to use open standards, realize
interoperability and
location
transparency.
– Implementations are environment specific, they are
constrained or
enabled by context and must be described
within their context.
– Requires strong governance of service
representation and implementation
– Requires a “Litmus Test", which
determined a “good service”
At 20:31 04/05/2006, Cory Casanave
wrote:
As an
update from the OMG meeting last week, the SOA SIG adopted the following
definition of SOA;
Service
Oriented Architecture is an architectural style for a community of providers
and consumers of services to achieve mutual value, that:
- Allows participants in the communities to work together with minimal
co-dependence or technology dependence
- Specifies the contracts to which organizations, people and
technologies must adhere in order to participate in the community
- Provides for business value and business processes to be realized by
the community
- Allows for a variety of technology to be used to facilitate
interactions within the community
The corresponding
definition of service has not yet been finalized but the sense of the group
is that there would be both a business/domain centric notion of service as
well as an interaction focused definition.
In both cases this seems
to fit well with the notion of SOA that is evolving in this group and in the
SOA Demo.
Regards,
Cory
Casanave
_________________________________________________________________
Subscribe/Unsubscribe/Config:
http://colab.cim3.net/mailman/listinfo/soa-forum/
Shared
Files: http://colab.cim3.net/file/work/soa/
Community
Portal: http://colab.cim3.net/
Community Wiki: http://colab.cim3.net/cgi-bin/wiki.pl?AnnouncementofSOACoP
Regards,
Chris
+++++
========================================================================
Dr.
Christopher J. Harding
Forum Director for SOA and Semantic
Interoperability
THE OPEN GROUP
Thames Tower, 37-45 Station Road,
Reading RG1 1LX, UK
Mailto:c.harding@xxxxxxxxxxxxx Phone (mobile): +44 774
063 1520
http://www.opengroup.org
******************************************************************
IT
Architecture Practitioners Conference
Hyatt Regency, Coral Gables, FL
July 17-19, 2006
Member Meetings - July 17-21, 2006
http://opengroup.org/miami2006/
========================================================================
TOGAF is a trademark of The Open Group
_________________________________________________________________
Subscribe/Unsubscribe/Config: http://colab.cim3.net/mailman/listinfo/soa-forum/
Shared Files: http://colab.cim3.net/file/work/soa/
Community Portal: http://colab.cim3.net/
Community Wiki: http://colab.cim3.net/cgi-bin/wiki.pl?AnnouncementofSOACoP (01)
|