<?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: Is capacity planning dead or set for a revival?</title>
	<atom:link href="http://www.redmonk.com/jgovernor/2008/11/28/is-capacity-planning-dead-or-set-for-a-revival/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.redmonk.com/jgovernor/2008/11/28/is-capacity-planning-dead-or-set-for-a-revival/</link>
	<description>An industry analyst blog looking at software ecosystems and convergence</description>
	<lastBuildDate>Fri, 03 Feb 2012 10:35:40 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: Richard Veryard</title>
		<link>http://www.redmonk.com/jgovernor/2008/11/28/is-capacity-planning-dead-or-set-for-a-revival/comment-page-1/#comment-502825</link>
		<dc:creator>Richard Veryard</dc:creator>
		<pubDate>Sat, 29 Nov 2008 12:28:01 +0000</pubDate>
		<guid isPermaLink="false">http://www.redmonk.com/jgovernor/?p=1704#comment-502825</guid>
		<description>Capacity of what? Not necessarily the same things as in the mainframe era. Sometimes more interesting or complex factors that limit the scaleability of large systems.

For example, if you have x faults per million transactions, and you need one full-time systems engineer for every y faults, then your system capacity is limited by the number of systems engineers you can employ. 

Of course you can try to change x and y, but maybe that&#039;s an important part of capacity planning as well.</description>
		<content:encoded><![CDATA[<p>Capacity of what? Not necessarily the same things as in the mainframe era. Sometimes more interesting or complex factors that limit the scaleability of large systems.</p>
<p>For example, if you have x faults per million transactions, and you need one full-time systems engineer for every y faults, then your system capacity is limited by the number of systems engineers you can employ. </p>
<p>Of course you can try to change x and y, but maybe that&#8217;s an important part of capacity planning as well.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Chris Bird</title>
		<link>http://www.redmonk.com/jgovernor/2008/11/28/is-capacity-planning-dead-or-set-for-a-revival/comment-page-1/#comment-502759</link>
		<dc:creator>Chris Bird</dc:creator>
		<pubDate>Sat, 29 Nov 2008 05:15:33 +0000</pubDate>
		<guid isPermaLink="false">http://www.redmonk.com/jgovernor/?p=1704#comment-502759</guid>
		<description>I don&#039;t agree that capacity planning was simply a mainframe discipline. It has certainly been a large company discipline at the various large organizations that I have worked with. SAP systems with 15,000 world wide users demand that we plan and manage capacity carefully. Package shipping for millions of packages per day globally demand great forethought in the planning and management of capacity. We can&#039;t just throw resources at that kind of a problem.

However when problems are smaller/more discrete then maybe the needs change. Certainly there is so much headroom in server boxes today and at such low price points that we may not need to worry because we know that 2 clustered for fail over boxes will run the critical services.

I do argue though, that most large organizations (and no I won&#039;t define large precisely what large means) will need to plan and manage capacity and scale of their core infrastructure - even as it becomes more of a utility.</description>
		<content:encoded><![CDATA[<p>I don&#8217;t agree that capacity planning was simply a mainframe discipline. It has certainly been a large company discipline at the various large organizations that I have worked with. SAP systems with 15,000 world wide users demand that we plan and manage capacity carefully. Package shipping for millions of packages per day globally demand great forethought in the planning and management of capacity. We can&#8217;t just throw resources at that kind of a problem.</p>
<p>However when problems are smaller/more discrete then maybe the needs change. Certainly there is so much headroom in server boxes today and at such low price points that we may not need to worry because we know that 2 clustered for fail over boxes will run the critical services.</p>
<p>I do argue though, that most large organizations (and no I won&#8217;t define large precisely what large means) will need to plan and manage capacity and scale of their core infrastructure &#8211; even as it becomes more of a utility.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

