<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Three quotes on software development</title>
	<atom:link href="http://www.johndcook.com/blog/2009/11/19/software-development-quotes/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.johndcook.com/blog/2009/11/19/software-development-quotes/</link>
	<description>The blog of John D. Cook</description>
	<lastBuildDate>Thu, 18 Mar 2010 14:57:38 -0400</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.4</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Roger Sessions</title>
		<link>http://www.johndcook.com/blog/2009/11/19/software-development-quotes/comment-page-1/#comment-27518</link>
		<dc:creator>Roger Sessions</dc:creator>
		<pubDate>Thu, 19 Nov 2009 16:12:42 +0000</pubDate>
		<guid isPermaLink="false">http://www.johndcook.com/blog/?p=3747#comment-27518</guid>
		<description>Thanks for the mention. My point is that architectural agility comes from allowing people to make decisions locally. But architectural chaos comes when those decisions are not tied together in a coherent way. So to give but one example, a good SOA describes how services are tied together through messages, but nothing about how those services are implemented. If the various service implementation groups can&#039;t agree on a database, it doesn&#039;t matter. Through agreeing that the services work together through messages (and only through messages), we have agreed to disagree on the implementation details, such as how data is stored, what language is used, etc.</description>
		<content:encoded><![CDATA[<p>Thanks for the mention. My point is that architectural agility comes from allowing people to make decisions locally. But architectural chaos comes when those decisions are not tied together in a coherent way. So to give but one example, a good SOA describes how services are tied together through messages, but nothing about how those services are implemented. If the various service implementation groups can&#8217;t agree on a database, it doesn&#8217;t matter. Through agreeing that the services work together through messages (and only through messages), we have agreed to disagree on the implementation details, such as how data is stored, what language is used, etc.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
