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

["Jeffrey A. Estefan" <jeffrey.a.estefan@jpl.nasa.gov>]

Ken,

I strongly object to your suggested changes.  I never liked the RM's 
definition of a reference architecture as being an "architectural design 
pattern" because it's misleading and incomplete.  In a nutshell, a reference 
architecture is a reusable asset whose purpose is to form a starting point 
for architectural development.  It can take many forms, including 
architectural patterns (note I did not use the term 'architectural design' 
pattern), architectural best practices, architectural principles, 
architectural frameworks, etc., and, unlike our SOA-RA effort, reference 
architectures are typically proven in use.

Historically, reference architectures have been used by service-based 
consultancies (not in the SOA-sense) as part of their intellectual capital 
reusable asset base.  In this way, reference architectures are, again, 
typically proven in use, which, is not the case for our domain-specific 
paradigm reference architecture for SOA.  We used to use reference 
architectures all the time when I worked for IBM and so did my colleagues 
over at Anderson Consulting (now Accenture).  More recently, analysts 
organizations like the Burton Group offer reference architectures for 
specifically targeted problem domains, e.g., application platform 
strategies, identity and privacy strategies.  Burton happens to structure 
their reference architectures based on "principles," "technical positions," 
and "templates."

The bottom line is that people can choose to use reference architectures or 
not.  We certainly cannot require people to use the SOA-RA anymore than we 
can require people to use the SOA-RM.  That is because these efforts are 
aimed at modeling a domain-specific paradigm as opposed to a specific 
technology.  If we, for example, were writing technology specs and standards 
like our W3C WSDL or OASIS SAML friends, then things like interoperability 
requirements would drive people to adopt certain technology specs and 
standards and, of course, specific versions of those technology specs and 
standards.  This is arguably why we've had limited play from the vendor 
community in our efforts because the vendors' focus is primarily 
technology-oriented.  Of course their professional services business should 
they choose to be technology agnostic (an similarly the analysts and 
consultancies businesses) could and arguably should make use of the SOA-RM 
and forthcoming SOA-RA, but then that's a judgment call based on their 
business model.  Nevertheless, I digress.  My apologies.

Let me just say that I prefer the language we had captured in Working Draft 
v0.2 of the RA.  I believe it does an excellent job of distinguishing a 
reference architecture from a reference model.

Incidentally, you also characterized a set of requirements, which read more 
like architectural principles than requirements.  Once again, I stress as I 
have since the beginning of this effort that we need to articulate a core 
set of architectural principles as part of the SOA-RA and these could be a 
reasonable start.  If we want to publicly articulate the requirements we 
have levied upon ourselves and to the SOA-RA, that's debatable, but we 
should still specify a core set of architectural principles; otherwise, 
we're no longer talking about architecture anymore, are we?

Bye for now...

 - Jeff E.