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

[Ken Laskey <klaskey@mitre.org>]

Jeff,

Hold on my friend!  I do not think I mean what you think I mean, or something like that.

To begin, I think you have a much tighter meaning for "architectural design pattern" than I interpret -- I'm not even sure who originally introduced that phrase.  I agree "a reference architecture is a reusable asset whose purpose is to form a starting point for architectural development."  I also have no vested interest in the form it takes -- we've been experimenting on form since the beginning.  As far as proven in use, we are dealing with a chicken and egg cycle but if we don't eventually get to that point, we've wasted a lot of time on the phone.

So what do you mean by architectural design pattern?

Now a lot of the words I proposed (including parts of the added 1.x) are copied from v0.2 section 1.1.  My question has been how we can best up front state what more specific problem(s) our RA is addressing.  A SOA that demonstrates working across ownership boundaries (rather than within a division of one company) seems an important point.  I proposed others too.  If these are best termed architectural principles, so be it.  If you can derive more than one RA from a set of RM concepts and relationships, I want to state unambiguously and up front for what architectural developments is our reusable asset the starting point.

Peace.

Ken

On Nov 12, 2007, at 3:53 PM, Jeffrey A. Estefan wrote:

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.

---------------------------------------------------------------------

To unsubscribe from this mail list, you must leave the OASIS TC that

generates this mail.  You may a link to this group and all your TCs in OASIS

at:

https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 

------------------------------------------------------------------------------------------

Ken Laskey

MITRE Corporation, M/S H305     phone:  703-983-7934

7515 Colshire Drive                        fax:        703-983-1379

McLean VA 22102-7508

smime.p7s