 




<?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>Modern Network Architecture &#187; IT Failures</title>
	<atom:link href="http://itknowledgeexchange.techtarget.com/modern-network-architecture/tag/it-failures/feed/" rel="self" type="application/rss+xml" />
	<link>http://itknowledgeexchange.techtarget.com/modern-network-architecture</link>
	<description>It’s like building a 747 while in flight.</description>
	<lastBuildDate>Mon, 20 May 2013 17:08:51 +0000</lastBuildDate>
	<language>en-US</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	
		<item>
		<title>Two simple IT department issues in Modern Network Architecture</title>
		<link>http://itknowledgeexchange.techtarget.com/modern-network-architecture/two-simple-it-department-issues-in-modern-network-architecture/</link>
		<comments>http://itknowledgeexchange.techtarget.com/modern-network-architecture/two-simple-it-department-issues-in-modern-network-architecture/#comments</comments>
		<pubDate>Tue, 11 Dec 2012 14:44:13 +0000</pubDate>
		<dc:creator>James Murray</dc:creator>
				<category><![CDATA[IT Architect]]></category>
		<category><![CDATA[It consultant]]></category>
		<category><![CDATA[IT Consulting]]></category>
		<category><![CDATA[IT Failures]]></category>
		<category><![CDATA[IT Hostage]]></category>
		<category><![CDATA[IT Infrastructure]]></category>
		<category><![CDATA[Modern Network Architecture]]></category>
		<category><![CDATA[Scaling infrastructure]]></category>
		<category><![CDATA[seattle IT consulting]]></category>
		<category><![CDATA[seattle IT Services]]></category>

		<guid isPermaLink="false">http://itknowledgeexchange.techtarget.com/modern-network-architecture/?p=505</guid>
		<description><![CDATA[As a business grows there is often a rebellion in IT departments.  On the one hand, IT technicians become overworked.  What I call IT cowboys enjoy the opportunity to wander the network arbitrarily fixing problems and playing the “lone wolf” on the network.  As the business grows though more and more “lone wolves” wander the [...]]]></description>
				<content:encoded><![CDATA[
<div class="topsy_widget_data topsy_theme_blue" style="float: right;margin-left: 0.75em;"><script type="text/javascript" src="http://button.topsy.com/widget/retweet-big?url=http://itknowledgeexchange.techtarget.com/modern-network-architecture/two-simple-it-department-issues-in-modern-network-architecture/&amp;title=Two+simple+IT+department+issues+in+Modern+Network+Architecture&amp;theme=blue&amp;order=count,badge,retweet&amp;txt_tweet=tweet&amp;txt_retweet=retweet"></script></div><p><span style="font-size: medium"><span style="color: #000000"><span style="font-family: Calibri">As a business grows there is often a rebellion in IT departments.  On the one hand, IT technicians become overworked.  What I call <a title="Seattle IT Consulting" href="http://www.seattleitedge.info">IT cowboys </a>enjoy the opportunity to wander the network arbitrarily fixing problems and playing the “lone wolf” on the network.  As the business grows though more and more “lone wolves” <span id="more-505"></span>wander the network they begin stepping all over each other’s work.  In other words without understanding the changes or discoveries another lone wolf … err… technician has made, there is a risk.  The risk is that the change will break the fix of another technician made earlier.  </span></span></span></p>
<p><span style="font-size: medium"><span style="color: #000000"><span style="font-family: Calibri">In a previous posting I discussed how <a title="Modern Network Architecture – IT Team players?" href="http://itknowledgeexchange.techtarget.com/modern-network-architecture/modern-network-architecture-it-team-players/">IT people need to be Team players</a>.  In another I discussed the <a title="Supporting roles for Operations Management" href="http://itknowledgeexchange.techtarget.com/modern-network-architecture/supporting-roles-for-operations-management/">supporting operational roles</a> to the Incident and Problem management roles.  In this article I’d like to discuss a problem I recently ran into on a client site.  As an<a title="Seattle IT Servicdes" href="http://www.Seattleitedge.com"> IT Consultant</a>, I run into these problems all the time.  The simplest solution is to re-organize the department.</span></span></span></p>
<p><span style="font-size: medium"><span style="color: #000000"><span style="font-family: Calibri">Two common symptoms of poor IT business behavior:  </span></span></span></p>
<p><span style="font-size: medium"><span style="color: #000000"><span style="font-family: Calibri"><strong>No Root Cause analysis</strong> -</span></span></span></p>
<p><span style="font-size: medium"><span style="color: #000000"><span style="font-family: Calibri">Without a problem management team, the Incident team will end up troubleshooting and fixing problems over and over again.  If the company pays $10 to resolve a ticket, each time the incident reoccurs the company pays another $10 for the ticket resolution.  It’s not unusual for tickets to re-occur hundreds of times in a year’s period.  This increases the cost of incident support per problem from $10 to $10 times the hundreds of times the problem goes through the incident process again and again.</span></span></span></p>
<p><span style="font-size: medium"><span style="color: #000000"><span style="font-family: Calibri"><strong>Symptom:</strong> runaway costs fixing the same problem over and over again.</span></span></span></p>
<p><span style="font-size: medium"><span style="color: #000000"><span style="font-family: Calibri"><strong>No Change Management</strong> -</span></span></span></p>
<p><span style="font-size: medium"><span style="color: #000000"><span style="font-family: Calibri">A common problem I see is a technician coming in to fix a problem.  After the technician leaves, the customer finds a new problem or even worse an old problem has come back.  The incident team is called and a new ticket is open for each error.  Each technician continues to work on the same problems over and over again.</span></span></span></p>
<p><span style="font-size: medium"><span style="color: #000000"><span style="font-family: Calibri"><strong>Symptom</strong>: runaway cost fixing the same problem over and over again.  This becomes compounded because while technicians fix one problem, they are breaking an old fix or creating new problems.  Incident problems on the network begin to snowball.</span></span></span></p>
<p><span style="font-size: medium"><span style="color: #000000"><span style="font-family: Calibri">The most important thing to understand is that accountability.  As in any business department there must be a way to track and verify problems.  Managers are taught to first assign tasks, then second follow-up on those tasks.  This follow-up maintains the integrity of the business system.  Too often IT is seen as black magic.  Therefore the second management task does not occur.  Without follow-up IT experts setup their own priorities.</span></span></span></p>
<p><span style="font-size: medium"><span style="color: #000000"><span style="font-family: Calibri">For example making the CPA and the controller the same person is asking for trouble.  Who follows up on the CPA if the CPA is the controller?  The same is true for when making the Incident manager and the problem manager the same person.  Making them the same person reduces accountability of the owner of the two roles.  By building in accountability, technical problems are reduced in the IT department in the same way financial errors and bankruptcy is reduced when a controller role is added to the accounting department.</span></span></span></p>
<p><span style="font-size: medium"><span style="color: #000000"><span style="font-family: Calibri">This accountability is something the old “Lone Wolf” type of technician never had to deal with.  Yet as the business grows, this type of behavior actually damages the real value of the organization.  As a <a title="Seattle IT Consulting" href="http://www.seattleitedge.com">Seattle IT Consultant </a>I work with IT departments and business owners to reorganize departments to avoid these types of conflicts between technicians.  </span></span></span></p>

<!-- wpms-network-global-inserts -->]]></content:encoded>
			<wfw:commentRss>http://itknowledgeexchange.techtarget.com/modern-network-architecture/two-simple-it-department-issues-in-modern-network-architecture/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Modern network architecture – Blaming the user</title>
		<link>http://itknowledgeexchange.techtarget.com/modern-network-architecture/modern-network-architecture-%e2%80%93-blaming-the-user/</link>
		<comments>http://itknowledgeexchange.techtarget.com/modern-network-architecture/modern-network-architecture-%e2%80%93-blaming-the-user/#comments</comments>
		<pubDate>Sun, 17 Jun 2012 02:28:45 +0000</pubDate>
		<dc:creator>James Murray</dc:creator>
				<category><![CDATA[Blaming Users]]></category>
		<category><![CDATA[IT Failures]]></category>
		<category><![CDATA[Modern Network Architecture]]></category>

		<guid isPermaLink="false">http://itknowledgeexchange.techtarget.com/modern-network-architecture/modern-network-architecture-%e2%80%93-blaming-the-user/</guid>
		<description><![CDATA[I am getting very tired of Systems Administrators that blame their users.  Once again I found myself between an IT Services vendor and their client.  As a Seattle IT Consultant I am often called in to help an owner fix their network.  Most IT Services Vendors are anxious when I walk in the door, thinking [...]]]></description>
				<content:encoded><![CDATA[
<div class="topsy_widget_data topsy_theme_blue" style="float: right;margin-left: 0.75em;"><script type="text/javascript" src="http://button.topsy.com/widget/retweet-big?url=http://itknowledgeexchange.techtarget.com/modern-network-architecture/modern-network-architecture-%e2%80%93-blaming-the-user/&amp;shorturl=http://bit.ly/NyVt43&amp;title=Modern+network+architecture+%E2%80%93+Blaming+the+user&amp;theme=blue&amp;order=count,badge,retweet&amp;txt_tweet=tweet&amp;txt_retweet=retweet"></script></div><p>I am getting very tired of Systems Administrators that blame their users.  Once again I found myself between an IT Services vendor and their client.  As a <a href="http://www.seattleitedge.info/">Seattle IT Consultant</a> I am often called in to help an owner fix their network.  Most IT Services Vendors are anxious when I walk in the door, <span id="more-326"></span>thinking I may be trying to steal their clients.  The good ones find themselves with more work because I hand out a lot of referrals. I&#8217;m not an <a href="http://www.seattleitedge.com/">IT Services</a> vendor in the traditional sense.  I work with clients to sit on their side of the table.  I translate the technical speak so common in our industry, into a language business owners understand.</p>
<p>Statistically thirty Percent of network system errors are caused by hardware failure.  If you&#8217;ve been in IT you know that most hardware errors occur in the first couple months the system is setup.  Once the system is running and doing what it&#8217;s supposed to, hardware failures are very rare.</p>
<p><strong>Statistically</strong> we know that 80% of businesses report consistently IT failures</p>
<p>Once the system is up and running whose fault is it?  What I&#8217;ve found is that it&#8217;s usually not the user.  Yet when I&#8217;m called in, I find that more often than not the users in the organization are being blamed.  I&#8217;ve seen one extreme example after another.  Where users are being blamed, but the real problem is the system technician, system administrator or the systems architect.  It&#8217;s very easy to blame the system failure on technology.  The technology is never offended.  The technology vendor is always willing to take the blame, if it means you buy more hardware.  The problem is that once the hardware is replaced, if the system continues to fail, you know it isn&#8217;t the hardware.  So eventually technology vendors begin blaming the users.  After all who else is there that could be causing the problem.</p>
<p><strong>Statistically</strong> 70% of IT failures is due to human error. </p>
<p>If so, human error is always user error isn&#8217;t it?  The reality is that hardware and software vendors have made technology so bullet proof from the user, that users really can&#8217;t bring down a network any longer.  Not when that network is setup in its default configuration from the manufacturer.  The reality is that most network failures are not cause by users.  They are caused by the poor planning of Systems experts. </p>
<p>There are a lot of <a href="http://www.dynagenconsulting.com/">advantages to the cloud</a>.  There is the advantage gained by removing the ongoing cost of server replacement from the organization&#8217;s capital expenditures budgets.  In a Break/fix network environment most networks function between 85 and 95% availability.  By improving Availability from 95 to 99.9% availability organizations improve workplace productivity.  Workplace productivity losses average around $7,000 / hour for small businesses and $50,000 / hour for larger businesses and can be millions of dollars a minute for the largest enterprise organizations.  Recovering 4.9% or more of workplace productivity can mean the difference between red and black accounting ink.</p>
<p>There&#8217;s another unspoken reason for the cloud though.  That&#8217;s to take technology out of the hands of the average system administrator.  Today&#8217;s small business system administrator is a &#8220;Jack of all trades&#8221; master of none.  Small businesses can&#8217;t afford an entire IT department.  Instead they hire someone who is good at everything.  In the cloud, teams of technical experts are hired with deep technical knowledge in every technology.  These teams are working in a highly organized network.  Most IT Support vendors are still tracking tickets in their head or on paper.  There are managed services organizations that manage 1000&#8242;s of clients.  Then there are cloud providers who manage literally Millions of clients at a per user cost that is much less and provide 3, 4 and even more 9&#8242;s of availability to clients.</p>
<p>The reality is that the cloud is possible because todays small business systems administrators are statistically the real reason for most IT Failures.  These administrators don&#8217;t even admit it and charge their customers for fixing their failures.  These system&#8217;s people think they are fooling their clients.  They do know and are looking for some way to protect themselves.</p>
<p>Want to stay in business?  My recommendation is never blame the user&#8230; even if it is their fault.  Design systems that are bulletproof, highly available and highly scalable.  It&#8217;s probably too late though because the cloud is coming.</p>

<!-- wpms-network-global-inserts -->]]></content:encoded>
			<wfw:commentRss>http://itknowledgeexchange.techtarget.com/modern-network-architecture/modern-network-architecture-%e2%80%93-blaming-the-user/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
