<?xml version="1.0"?>
<rss version="2.0">
<channel>

  
<title>Coding the Architecture - Nines</title>
<link>http://www.codingthearchitecture.com/2007/09/26/nines.html</link>
<description> I&#039;ve been reviewing some software architecture documents as part of a training course today, where the authors had restated the non-functional requirements. Given that the non-functional requirements are some of the key architectural drivers, restating ...</description>
<language>en</language>
<managingEditor>Simon Brown</managingEditor>
<lastBuildDate>Fri, 28 Sep 2007 08:03:39 GMT</lastBuildDate>
  
  

  <generator>Pebble (http://pebble.sourceforge.net)</generator>
  <docs>http://backend.userland.com/rss</docs>
  
  
  <item>
    <title>Re: Nines</title>
    <link>http://www.codingthearchitecture.com/2007/09/26/nines.html#comment1190966619216</link>
    <description>
      Recently I’ve dealt with two different managed hosting providers on behalf of my client and they both guarantee (through money back clauses) 100% uptime.  Which is nonsense.  They are basically hiding their real service levels.  They know they can&#039;t be 100%.  They know they can&#039;t even be 5 nines probably - they certainly can&#039;t beat pacemakers and air traffic control systems.  So they&#039;ll take a small financial hit when they drop their service (if the customer notices...) just so they can splash the 100% sales pitch on their home page.

This sort of woolly apologetic approach to availability encourages the business to expect unrealistic NFRs.  &#034;If the hosting provider can be 100% then why can&#039;t this new application?&#034;.  It also begs the question, when you ask for a specific availability NFR how are you actually going to measure it in production?

    </description>
    <author>Sergio Annecchiarico</author>
    <comments>http://www.codingthearchitecture.com/2007/09/26/nines.html#comments</comments>
    <guid isPermaLink="true">http://www.codingthearchitecture.com/2007/09/26/nines.html#comment1190966619216</guid>
    <pubDate>Fri, 28 Sep 2007 08:03:39 GMT</pubDate>
  </item>
  
  <item>
    <title>Re: Nines</title>
    <link>http://www.codingthearchitecture.com/2007/09/26/nines.html#comment1190884479485</link>
    <description>
      &lt;p&gt;Yes, I see over stringent NFRs very often. Rather than allowing the business people to compare to another IT system (google&#039;s budget is HUGE) I tend to compare to a car. A basic car from a mass producer is quite cheap and pretty reliable these days. How expensive would the car be if it could be guaranteed to have no faults for 10 years? No flat tyres, leaking coolant or even a replaced windscreen wiper? We all top up the coolant on our cars and replace the wipers so why is an IT system different?
&lt;/p&gt;
    </description>
    <author>Robert Annett</author>
    <comments>http://www.codingthearchitecture.com/2007/09/26/nines.html#comments</comments>
    <guid isPermaLink="true">http://www.codingthearchitecture.com/2007/09/26/nines.html#comment1190884479485</guid>
    <pubDate>Thu, 27 Sep 2007 09:14:39 GMT</pubDate>
  </item>
  
  <item>
    <title>Re: Nines</title>
    <link>http://www.codingthearchitecture.com/2007/09/26/nines.html#comment1190884222215</link>
    <description>
      Agreed and see my comment below - we&#039;re trying to figure out NFRs (limitations) for an existing architecture! :-)
    </description>
    <author>Simon Brown</author>
    <comments>http://www.codingthearchitecture.com/2007/09/26/nines.html#comments</comments>
    <guid isPermaLink="true">http://www.codingthearchitecture.com/2007/09/26/nines.html#comment1190884222215</guid>
    <pubDate>Thu, 27 Sep 2007 09:10:22 GMT</pubDate>
  </item>
  
  </channel>
</rss>
