[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm-ra] what is a generalized SOA RA?
I like most of the culmination of updates that have been proposed for the RA so far, but I would agree with Jeff that we shouldn't propagate the "architecture is a design pattern" statement in the RM even if we are trying to justify it. I also agree with Jeff about architectural principles versus requirements for the RA. I am open to seeing how the requirements section works out, however. Frank can work wonders in this regard. Danny --- Ken Laskey <klaskey@mitre.org> wrote: > 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 > > ____________________________________________________________________________________ Get easy, one-click access to your favorites. Make Yahoo! your homepage. http://www.yahoo.com/r/hs
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]