Re: [soa-rm] Reference Architecture

[Michael Stiefel <development@reliablesoftware.com>]

Agreed that the appropriate requirements should be part of the RA. Also 
agreed that the requirements could vary in their "concreteness".

To use our housing example, we could have any one of the following 
requirements in the RA:
         there has to be an eating area
         the eating area may or may  not have room for dining
         the eating area must have a dining area and either a stove or a 
microwave
         the eating area must take up between 10% and 20% of the are of the 
floor it is on
         etc.

It almost seems that the RA could be a sort of abstract BNF or some set of 
production rules.

That brings up another question. Forgetting about contradictions between 
the reference architectures for a moment, could a given concrete 
architecture be generated from more than one reference architecture.

For example, a Queen Anne style building originally borrowed from 
pre-Georgian and late Medieval style buildings. It eventually developed 
into a pastiche of various influences.

Michael

At 07:55 PM 1/26/2006, Francis McCabe wrote:
>Right.
>Although I think that the requirements need not be completely
>concrete in a reference architecture. Also I think that we need to
>ensure that the requirements we adopt are an explicit part of the RA
>itself.
>One other thing, there are requirement of an architecture and
>properties of an architecture. So I think that the appropriate logic is:
>
>There are requirements a,b and c. These are predicates, if you will,
>that must be satisfied by the architecture.
>There are properties p, q and r. If these properties hold then a,b
>and c will be satisfied. It may not be provable that p,q and r will
>give you a, b and c. But properties are measurable.
>Then there are mechanisms (modules, patterns, relationships whatever)
>that, in combination, exhibit properties p, q and r.
>Then you are done!
>
>E.g., "the architecture shall be securable" is a reasonable
>requirement. We assert that proper authentication and auditing will
>result in a secure architecture. (Not by itself provable of course.)
>Then in an architecture in which agents must authenticate themselves,
>and supply authentication tokens to an escrow for each communication
>then we have established a mechanism that gives us our required
>properties and have a secure architecture.
>
>Frank
>
>
>On Jan 26, 2006, at 6:53 AM, Michael Stiefel wrote:
>
>>Frank:
>>
>>Fair enough.
>>
>>Let me see if I understand you correctly. A reference architecture
>>states principles such as:
>>
>>Given concrete requirements a and b abstract mechanism x will be
>>one possible way to salsify it.
>>Given concrete requirement c, abstract mechanism y will be the only
>>way to satisfy it.
>>Given concrete requirements d and e, a you use abstract mechanisms
>>w and z to satisfy it.
>>Given concrete requirement f, a relationship between model elements
>>q and r is the only way to satisfy it.
>>
>>Michael
>>
>>
>>At 11:11 PM 1/25/2006, you wrote:
>>>Michael:
>>>  I have to confess that I don't much like this definition. It gives
>>>no guidance or expectation as to what an RA will do for you. That is
>>>why I used the phrase mechanisms - I want to be able to inform
>>>architects how to build something that will work.
>>>Frank
>>>
>>>On Jan 25, 2006, at 6:58 AM, Michael Stiefel wrote:
>>>
>>>>Here is a link discussing using reference architecture within the
>>>>RUP framework: http://www-128.ibm.com/developerworks/rational/
>>>>library/2774.html
>>>>
>>>>I am not advocating the RUP framework, but they seem to have a
>>>>definition of a reference architecture that could serve as a
>>>>starting point:
>>>>
>>>>A reference architecture is a resource containing a consistent set
>>>>of architectural best practices for use by all the teams in your
>>>>organization.
>>>>
>>>>
>>>>As a set of patterns it is reasonably abstract, yet concrete enough
>>>>to help develop specific solutions.
>>>>
>>>>Michael
>>>>
>>>>At 12:33 AM 1/14/2006, you wrote:
>>>>>The time has come to start considering the development of a
>>>>>Reference
>>>>>Architecture.
>>>>>
>>>>>The TC agreed to establish a sub-committee to pursue this, so we
>>>>>will
>>>>>be called the SOA RM TC RA SC !
>>>>>
>>>>>  The first item of business is to develop a statement of purpose.
>>>>>
>>>>>  One suggestion is:
>>>>>
>>>>>  To develop, in accordance with the SOA RM TC Charter, a reference
>>>>>Service Oriented Architecture.
>>>>>
>>>>>  Definition: A reference model that is mapped onto software
>>>>>elements
>>>>>that implements the functionality defined in the reference model.
>>>>>  www.sei.cmu.edu/architecture/glossary.html
>>>>>
>>>>>  Definition: A reference architecture is an abstract set of
>>>>>mechanisms and relationships that models a predetermined set of
>>>>>requirements.
>>>>>  McCabe 2006
>>>>>
>>>>>  Keywords: abstract, mechanisms, model, requirements.
>>>>>
>>>>>  A reference architecture can be to guide the realization of
>>>>>implementations where specific properties are desired of the
>>>>>concrete
>>>>>system.
>>>>>
>>>>>  To initiate the discussion, some questions suggest themselves:
>>>>>
>>>>>1. What requirements should be captured in a reference architecture
>>>>>2. What mechanisms are required to realize those requirements
>>>>>3. What is the relationship between the Reference Model and the
>>>>>Reference Architecture
>>>>>4. What additional concepts (if any) to those captured in the
>>>>>Reference Model are necessary to develop an RA.
>>>>>
>>>>>  Immediate steps
>>>>>1. To agree on a statement of purpose
>>>>>2. To collect requirements
>>>>>
>>>>>Let the fur fly!
>>>>>
>>>>>Frank McCabe
>>
>>
>