<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	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/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>vReference &#187; Design</title>
	<atom:link href="http://www.vReference.com/tag/design/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.vReference.com</link>
	<description>guides, links and news for VMware and virtualization technologies</description>
	<lastBuildDate>Tue, 31 Jan 2012 15:54:43 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=</generator>
		<item>
		<title>Design factors</title>
		<link>http://www.vReference.com/2010/06/16/design-factors/</link>
		<comments>http://www.vReference.com/2010/06/16/design-factors/#comments</comments>
		<pubDate>Wed, 16 Jun 2010 18:49:59 +0000</pubDate>
		<dc:creator>Forbes Guthrie</dc:creator>
				<category><![CDATA[News]]></category>
		<category><![CDATA[Design]]></category>
		<category><![CDATA[vSphere4]]></category>

		<guid isPermaLink="false">http://www.vReference.com/?p=880</guid>
		<description><![CDATA[<p>Recently I have been thinking a lot about the basic process we go through when designing an infrastructure solution, the choices we make, and why we make them.</p> <p>These processes may be carefully structured within well-formed and trusted architectural frameworks, or they may be the sort of inherent thoughts that whiz through your mind when [...]<p>=====
<a href="http://www.vReference.com/2010/06/16/design-factors/">Design factors</a>  originally posted by Forbes Guthrie on <a href="http://www.vReference.com">vReference</a>.
Subscribe to my <a href="http://feeds2.feedburner.com/vreference">RSS feed</a> for all the latest updates, and follow me on <a href="http://twitter.com/forbesguthrie">Twitter</a> for shorter ramblings.
<a href="http://twitter.com/{screen_name}" class="twitter-follow-button">Follow @forbesguthrie</a>
<script src="http://platform.twitter.com/widgets.js" type="text/javascript"></script></p>
]]></description>
			<content:encoded><![CDATA[<p>Recently I have been thinking a lot about the basic process we go through when designing an infrastructure solution, the choices we make, and why we make them.</p>
<p>These processes may be carefully structured within well-formed and trusted architectural frameworks, or they may be the sort of inherent thoughts that whiz through your mind when someone asks for your opinion on a pressing matter.</p>
<p>Regardless of the depth and scope of the project in front of you, I think the design questions you ask are often the same.</p>
<p>I have been reading what some VMware experts (along with other non-VMware related sources) have to say to this, and have tried to collate a list for myself.  I looked to identify what it is we consider, without overloading it so it stays nibble, but documented nonetheless to clarify each step.  As I said, these are scraped and cross-referenced from many people and sources (unfortunately too many to remember now), so I make no assertion that this all came to me in a glorious epiphany.</p>
<p>Here is what I have come up with so far. When looking at each decision within the design, these are the factors I would like myself to think through:</p>
<ul>
<li>what is the feature/component/technology and what is its place in the overarching solution</li>
<li>options within the feature – why you need to make a decision</li>
<li>assumptions</li>
<li>requirements to use it (prerequisites)</li>
<li>constraints when you do use it</li>
<li>what is considered best practice (even though it may not be the right choice in this particular circumstance)</li>
<li>impact of using (ramifications/consequence) – cost/availability/performance (including impact on other areas)
<ul>
<li>positive (benefits) – justified?</li>
<li>negative (drawbacks) – how to mitigate (if possible) &#8211; risks</li>
</ul>
</li>
<li>impact of not using (ramifications/consequence) – cost/availability/performance (including impact on other areas)
<ul>
<li>positive (benefits) – justified?</li>
<li>negative (drawbacks) – how to mitigate (if possible) – risks</li>
</ul>
</li>
</ul>
<p>What do you think?  These are not the pieces to create a whole design, just the considerations for each and every decision.  I&#8217;d love to hear your comments and suggestions for improving this.</p>
<p>=====
<a href="http://www.vReference.com/2010/06/16/design-factors/">Design factors</a>  originally posted by Forbes Guthrie on <a href="http://www.vReference.com">vReference</a>.
Subscribe to my <a href="http://feeds2.feedburner.com/vreference">RSS feed</a> for all the latest updates, and follow me on <a href="http://twitter.com/forbesguthrie">Twitter</a> for shorter ramblings.
<a href="http://twitter.com/{screen_name}" class="twitter-follow-button">Follow @forbesguthrie</a>
<script src="http://platform.twitter.com/widgets.js" type="text/javascript"></script></p>
]]></content:encoded>
			<wfw:commentRss>http://www.vReference.com/2010/06/16/design-factors/feed/</wfw:commentRss>
		<slash:comments>3</slash:comments>
		</item>
	</channel>
</rss>

