<?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: A small step for SCA, a giant leap for BSM</title>
	<atom:link href="http://stage.vambenepe.com/archives/884/feed" rel="self" type="application/rss+xml" />
	<link>http://stage.vambenepe.com/archives/884</link>
	<description>IT management in a changing IT world</description>
	<lastBuildDate>Wed, 17 Mar 2010 19:31:41 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Bookmarks for July 22nd through July 27th</title>
		<link>http://stage.vambenepe.com/archives/884#comment-80234</link>
		<dc:creator>Bookmarks for July 22nd through July 27th</dc:creator>
		<pubDate>Mon, 27 Jul 2009 14:01:51 +0000</pubDate>
		<guid isPermaLink="false">http://stage.vambenepe.com/?p=884#comment-80234</guid>
		<description>[...] William Vambenepe&#8217;s blog &#187; Blog Archive &#187; A small step for SCA, a giant leap for B... &#8211; The road to BSM is paved with small improvements in the semantic alignment between IT infrastructure and application services. A couple of years ago, I tried to explain why SCA is very relevant for IT management. Now we can see it. [...]</description>
		<content:encoded><![CDATA[<p>[...] William Vambenepe&rsquo;s blog &raquo; Blog Archive &raquo; A small step for SCA, a giant leap for B&#8230; &#8211; The road to BSM is paved with small improvements in the semantic alignment between IT infrastructure and application services. A couple of years ago, I tried to explain why SCA is very relevant for IT management. Now we can see it. [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: William Louth</title>
		<link>http://stage.vambenepe.com/archives/884#comment-80099</link>
		<dc:creator>William Louth</dc:creator>
		<pubDate>Fri, 24 Jul 2009 18:38:32 +0000</pubDate>
		<guid isPermaLink="false">http://stage.vambenepe.com/?p=884#comment-80099</guid>
		<description>Missed that statement. I take &quot;fixated&quot; back the rest you can keep, ;-).</description>
		<content:encoded><![CDATA[<p>Missed that statement. I take &#8220;fixated&#8221; back the rest you can keep, ;-).</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: William Vambenepe</title>
		<link>http://stage.vambenepe.com/archives/884#comment-80094</link>
		<dc:creator>William Vambenepe</dc:creator>
		<pubDate>Fri, 24 Jul 2009 16:10:33 +0000</pubDate>
		<guid isPermaLink="false">http://stage.vambenepe.com/?p=884#comment-80094</guid>
		<description>Hi William L.,

&quot;fixated&quot; seems a bit strong a word when I explicitly wrote that &quot;configuration-based models are a complement to runtime transaction discovery, not a replacement&quot;.

Regards,

William V.</description>
		<content:encoded><![CDATA[<p>Hi William L.,</p>
<p>&#8220;fixated&#8221; seems a bit strong a word when I explicitly wrote that &#8220;configuration-based models are a complement to runtime transaction discovery, not a replacement&#8221;.</p>
<p>Regards,</p>
<p>William V.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: William Louth</title>
		<link>http://stage.vambenepe.com/archives/884#comment-80075</link>
		<dc:creator>William Louth</dc:creator>
		<pubDate>Fri, 24 Jul 2009 08:50:09 +0000</pubDate>
		<guid isPermaLink="false">http://stage.vambenepe.com/?p=884#comment-80075</guid>
		<description>I am curious why you seem fixated on the actual static configuration rather than the actual dynamic behavior patterns and runtime state. 

What has [config] changed? Should that not be what new behavioral &amp; state patterns have we detected in our system. A configuration change does not necessarily imply a change in actual software or system execution behavior though I will admit that it is a good starting point when you have nothing else to go on. 

Maybe it a difference in perspective. I seek to understand (largely observation based) and acquire knowledge whereas most are just looking to take corrective action (incident mode) which typically means roll back but without the search for the underlying &quot;why X&quot; and no knowledge acquisition.

Coming from a programming background I see both the dynamic system and software execution models as the ultimate configuration management databases. But then again I love the hard challenges.

William</description>
		<content:encoded><![CDATA[<p>I am curious why you seem fixated on the actual static configuration rather than the actual dynamic behavior patterns and runtime state. </p>
<p>What has [config] changed? Should that not be what new behavioral &amp; state patterns have we detected in our system. A configuration change does not necessarily imply a change in actual software or system execution behavior though I will admit that it is a good starting point when you have nothing else to go on. </p>
<p>Maybe it a difference in perspective. I seek to understand (largely observation based) and acquire knowledge whereas most are just looking to take corrective action (incident mode) which typically means roll back but without the search for the underlying &#8220;why X&#8221; and no knowledge acquisition.</p>
<p>Coming from a programming background I see both the dynamic system and software execution models as the ultimate configuration management databases. But then again I love the hard challenges.</p>
<p>William</p>
]]></content:encoded>
	</item>
</channel>
</rss>
