[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?
Is a set of architectural principles not a requirement? I thought that was the main requirement for an RA. I still think that management and governance belong in the same bullet point in the intro. They can be teased apart as Jeff's diagram showed later, in the Owning view. Cheers, Rex At 5:09 PM -0800 11/12/07, Danny Thornton wrote: >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 > >--------------------------------------------------------------------- >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 -- Rex Brooks President, CEO Starbourne Communications Design GeoAddress: 1361-A Addison Berkeley, CA 94702 Tel: 510-898-0670
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]