Re: [soa-rm-ra] what is a generalized SOA RA?

[Danny Thornton <danny_thornton2@yahoo.com>]

I think the 1.x section about requirements may be
viewed as overlapping with what is currently in
section 1.2 for the three key principles of the RA
approach.

I will reiterated what Jeff stated earlier about
requirements. For ALL of the government projects I've
worked on in the past, requirements are traceable,
testable, and measurable. Requirements are checked and
signed off during formal acceptance testing.  

If we provide requirements, then we are providing an
initial set of traceable, testable, and measureable
statements about a SOA-based system.

For example, take the following requirement:

Resources are distributed across ownership boundaries,
e.g. there is not a single entity that can exercise
control over all identified SOA services.

This is an accurate statement about a SOA ecosystem
but would not be something to measure about the
implementation of a particular system.  Therefore, I
would classify it more in the category of a principle.
 To be a high-level testable requirement that could be
traced to more detailed testable requirements, the
above requirement could be written as:

Resources shall be accessable across ownerhips
boundaries.  ...

Danny

--- Ken Laskey <klaskey@mitre.org> wrote:

> Frank,
> 
> Let me go back to what I proposed 11/12/2007 but
> modify for Jeff and  
> Danny's comment and some of your initial ones:
> 
> 1 Introduction
> 
> Service Oriented Architecture is an architectural
> paradigm that has  
> gained significant attention within the information
> technology (IT)  
> and business communities. The OASIS Reference Model
> for SOA provides  
> a common language for understanding the important
> features of SOA but  
> does not address the issues involved in
> constructing, using, or  
> owning a SOA-based system. This document focuses on
> these aspects of  
> SOA.
> 
> 
> 1.1 What is a Reference Architecture
> 
> A reference architecture models the abstract
> architectural elements  
> in the domain independent of the technologies,
> protocols, and  
> products that are used to implement the domain. It
> differs from a  
> Reference Model in that a Reference Model describes
> the important  
> concepts and relationships in the domain focusing on
> what  
> distinguishes the elements of the domain; a
> Reference Architecture  
> elaborates further on the model to show a more
> complete picture that  
> includes what is involved in realizing the modeled
> entities. While  
> still remaining abstract, a reference architecture
> is more concrete  
> than a Reference Model in that it identifies and
> provides a high  
> level description of architectural components and
> artifacts.
> 
> 
> 1.x What is this Reference Architecture
> 
> It is possible to define Reference Architectures at
> many levels of  
> detail or abstraction, and for many different
> purposes. In fact, the  
> reference architecture for one domain may represent
> a further  
> specialization of another reference architecture,
> with additional  
> requirements over those for which the more general
> reference  
> architecture was defined.
> 
> 
> While requirements for this reference architecture
> are discussed in  
> Section 2, an overview of those requirements
> specifies a SOA for which:
> 
> 
> Resources are distributed across ownership
> boundaries, e.g. there is  
> not a single entity that can exercise control over
> all identified SOA  
> services;
> Resources have been developed for purposes other
> than inclusion in a  
> particular implementation following this reference
> architecture, and  
> those resources should continue to support those
> initial purposes as  
> well as the expanded access via SOA;
> Infrastructure must be in place to enable
> communications through the  
> exchange of messages and with reliability
> appropriate for the users  
> and purposes for which the SOA implementation is
> used;
> Security, governance, and management must be
> effective but consistent  
> with multiple ownership boundaries;
> Appropriate mediation must be available to enable
> coordinated use of  
> independently developed resources;
> [other overarching assumptions/requirements?]
> 
> Below, we talk about such an environment as a SOA
> ecosystem.  
> Informally, our goal in this Reference Architecture
> is to show how  
> Service Oriented Architecture fits into the life of
> users and  
> stakeholders in a SOA ecosystem, how SOA-based
> systems may be  
> realized effectively, and what is involved in owning
> such a SOA-based  
> system. We believe that this approach will serve two
> purposes:  
> ensuring that the true value of a SOA meeting the
> stated requirements  
> can be realized using appropriate technology, and
> permitting the  
> audience to focus on the important issues without
> becoming over- 
> burdened with the details of a particular
> implementation technology.
> 
> 
> 1.2 Service Oriented Architecture – An Ecosystems
> perspective
> 
> Many systems cannot be understood by a simple
> decomposition into  
> parts and subsystems. There are...
> 
> 
> OK, at the time we discussed this I see some
> comments but other than  
> the mixing of architecture and design, there was no
> major heartburn.   
> Does this work in satisfying my stated goal?  Does
> the goal itself  
> not serve a useful purpose for this document?
> 
> Ken
> 
> On Dec 21, 2007, at 3:29 PM, Francis McCabe wrote:
> 
> > Ken:
> >  Except that the wording you proposed would have
> directly  
> > replicated existing wording and made for
> redundancy.
> >
> >  Personally, I think we need to move on.
> > Frank
> >
> >
> > On Dec 21, 2007, at 12:22 PM, Ken Laskey wrote:
> >
> >> Danny,
> >>
> >> Following Jeff's point, we need to see where the
> proposed words  
> >> fit in the Intro.  When I originated the draft, I
> intended for it  
> >> to be part of a new section 1.x entitled "What is
> This RA" that  
> >> sat between 1.1 and 1.2.  I didn't intend to
> alter (modulo other  
> >> comments) the section 1.1 words on reference
> architecture.
> >>
> >> In the previous email thread with Jeff, I
> realized the RM wording  
> >> was unintentionally sloppy and suggested the
> TOGAF reference as a  
> >> way to "clarify" the RM definition.  Jeff
> responded that he only  
> >> supplied that for an example, and thought 1.1 was
> sufficient.  I'm  
> >> willing to go with that being my intent was not
> the redefinition  
> >> of reference architecture but a statement about
> the problem being  
> >> solved by our RA.  So I am more interested in 1.x
> and not in  
> >> rewriting 1.1.
> >>
> >> This thread began 11/10/2007 and isn't very long,
> so a quick  
> >> review might help all.
> >>
> >> Ken
> >>
> >> On Dec 21, 2007, at 3:11 PM, Danny Thornton
> wrote:
> >>
> >>> Jeff,
> >>>
> >>> Didn't you propose the TOGAF reference?
> >>>
> >>> All,
> >>>
> >>> I think Jeff and I are both opposed to stating a
> >>> Reference Archicture is a design pattern because
> we
> >>> both see the use of design pattern in this
> context as
> >>> an incorrect statement.
> >>>
> 
=== message truncated ===



      ____________________________________________________________________________________
Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs