EDITOR'S NOTE: I e-mailed Nicholas Carr about this post and he suggested that I pick up "The Big Switch" instead of relying on the Network World article, which he suggested might be a bit "sensationalistic." I'll swing by my local bookstore later tonight and see if they have it and will shortly go through it.

By Brian Boyko
Editor, Network Performance Daily

Nicholas Carr (who has kindly mentioned this blog in a post about Ad-block) has written a book called, The Big Switch: Rewiring the World from Edison to Google. And according to Network World, Carr, who wrote an article called "Does IT Matter?" for Harvard Business Review, said in this book that:

"In the long run, the IT department is unlikely to survive, at least not in its familiar form," Carr writes. "It will have little left to do once the bulk of business computing shifts out of private data centers and into the cloud. Business units and even individual employees will be able to control the processing of information directly, without the need for legions of technical people."

Now, we haven't yet read Carr's book and so we can't comment on whether or not he makes a compelling case for the obsolescence of the IT department, and for all I know that quote was taken out of context. But I do believe that it will be a long time before the IT department goes away.

SAAS is a wonderful development, and apps like SalesForce are, to the people that use them, godsends. However, unique company problems require unique solutions - SAAS services are looking to appeal to the largest common denominator. For that reason alone, IT will always have a place in the enterprise.

Additionally, if you want to connect to the network, which you most certainly will have to do to access your SAAS applications, you need network engineers to build and maintain the network - even if it's just for Internet connectivity. And what about application performance?

Google or other SAAS providers will not design your WAN to deliver large backups during off-peak hours, won't get your VoIP service to work with your data applications without clogging the lines, and won't help maintain your company's computer security. (Heck, if nothing else, when a key Ethernet cable gets unplugged, you need at least a sysadmin to find out which cable was unplugged and to physically run down there and plug it back in.)

Relying solely on SAAS is problematic at best. You're at the mercy of another company's quality control - and if the site goes down, so does your business. Your company's data - important and confidential data - resides on another company's servers. Finally, what about capacity planning?

That last one is crucial. You are usually not privy to the capacity of third parties. Larger SAAS services like SalesForce probably scale well and overprovision. But if Carr's thesis - that eventually most enterprise software will be SAAS - holds true, there will be some applications that are further down the long tail and service a much more limited number of customers.

With a typical client/server app, you have all the information there if you need it - the ability of the server, the number of clients, the average traffic per client, and if you have any network management software, you have a very good idea of how much total traffic you can handle. But put that application out in the "cloud" and you no longer can see that information, so you have no idea whether or not you're doing fine or teetering on the edge of a major slowdown in the service. It completely negates any possibility of meaningful capacity planning.

Sure, it shifts the blame from the IT department to the SAAS provider, but ultimately, it's the same thing: less productivity, less on the bottom line.

If Carr's thesis is that SAAS is going to play more of a role in enterprise computing in the future, we can't help but agree. But to say that there's no role for IT in a future with more SAAS applications is assuming far too much.

By Nathan Bragaw
Business Development Manager, NetQoS

NetQoS European Tech Rep. Peter Frame and I made a trip to Moscow last month to attend a network management event hosted by our new Russian partner, UNICORNS. I thought I'd share a few observations from that trip.

First, the obvious: Russia is cold. I was born in Maine and been in Minnesota in Winter, but Russia, complete with snowfall and brisk wind qualifies as the coldest place I've ever been, and that includes Minnesota in Winter. On the plus side, the food is fantastic - I didn't realize I liked borscht until I ate at Taras Bulba on Petrovka Street - wonderful Ukranian and Georgian food.

It was clear from the wonderful work our local partner, Boris Goldshteyn, did with getting some of the biggest companies in Russia to attend our first network management event in the country that the Russian economy is in full throttle.

I am always fascinated by how different cultures and environments change the needs of our customers. In Russia, it's not that their network performance problems are any different. Instead, they are facing the same problems, like VoIP performance and WAN Optimization difficulties, but they are moving at a faster rate. This is largely because they are not confined by the fiscal restraints that companies in the U.S. face due to the fallout of the dot-bomb era. Companies in Russia want to invest in technology but are challenged to ensure that the technology they seek will meet the needs of their business. The network engineers we talked to there are looking at massive growth, the push for more current technology, and demands for understanding application performance over their networks.

What differences in culture and environments have you found when working on multinational IT projects? Feel free to tell us about them in the comments section of this post.

By Brian Boyko
Editor, Network Performance Daily

I'm sure most of our readers can sympathize with the protagonist in this Daily WTF story, "Illicit Process Improvement." (Indeed, it reminded me of quite a few scenarios from my mandatory high school "computer studies" courses.) Most people who have worked in the bowels of corporate IT departments can sympathize with the situation: Lowly but technically savvy person discouraged from making minor improvements because of a major change, which is perpetually "on the way."

And it does seem that the big project is almost always either perpetually "on the way," until it's forgotten or the project's sponsors have to admit defeat, doesn't it? Indeed, Infoworld has written "On average, about 70 percent of all IT-related projects fail to meet their objectives." That's a staggeringly high number.

Certainly, IT failure rates are one of the reasons it can be so hard to explain how to get business decision makers to invest in IT. I mean, think about it. Would you invest in a business where 70% of the products failed?

This is one of the reasons that IT departments need to quantify the business gains from successful IT initiatives, in order to justify the investment the business makes in IT. And we've talked about that before, especially as it relates to quantifying the value of network performance improvements. But if it's good to quantify your successes, wouldn't it be even better to have more successes overall?

You could argue that IT is just too complicated; that there are too many pressures and personalities in the IT room, and that technology upgrades are just complex and prone to failure. I doubt it though. Sure, WAN Optimization and VoIP implementations are difficult and technical. But commercial satellite launches are technologically complex, and I'll bet you failure rate is less than 70%. Indeed, the Indian Space Research Organization is talking about a 5% launch failure rate in 10 years.

Okay, so it's a false comparison. But if the IT guys are bright people - why does everything seem to fall apart?

I think that it's because of three things.

First: Often, projects are started without a clear understanding of the company's needs, and without a clear sense of the greater goals of the project.

I don't want to get started in on a recursive loop of existential navel gazing; lord knows I've done that too many times in my lifetime. But I think that many projects are started without a clear answer to the question: "Why?" When the project is successfully completed, what will it have accomplished? Is that goal one which will ultimately benefit the business in some capacity, by reducing cost or increasing revenue? Often times, we find ourselves taking on projects without having the purpose in mind - the project itself becomes its own purpose.

Now, this instinct often serves technical people well - we approach technology as an art form, with no particular purpose needed. This is why we were putting together Linux boxes out of old computers in our freshman years of college (or high school) and learning all we could - even though it might have been more productive to stick with our PCs at that time. Technology for technology's sake.
So as we get bogged down in the technicality of things, we ignore the broader questions of why.

And while it probably means more of the dreaded "meetings" which keep us away from our servers, databases, and wires and force us to spend time in boring, dull human contact before any project begins, it's probably a good idea to establish what the ultimate purpose of the project is. If the project can no longer meet those goals, if the project is not the best way of meeting those goals, if the goals become irrelevant - then it's time to change the project to meet the new goals, not the new goals to meet the project.

Second, when the project is underway and a deadline passes, the deadline is often pushed back with no ill consequences.

Projects often limp on for years that way. Furthermore, if you know that a deadline is going to be extended, you're more likely to put those projects on the back-burner, instead of giving them more direct attention. Okay, sometimes the task is harder than anticipated, or more problems creep up than are expected - these things happen. But if you can't meet an incremental deadline for a phase of the project, then you have to ask whether you'll be able to meet the final deadline; and if not, how that impacts the key goals - will the project even meet those goals now?

In short, a missed deadline is a reason to re-evaluate the project - not a reason to re-evaluate the deadline.

Third, there's a tendency for IT planning to develop overarching, long, huge, revolutionary solutions when small fixes are the most efficient solution.

Just speaking from personal experiences, I could have just bought a TiVo instead of going through the steps required to build my own MythTV box.
In the story mentioned at the top of this article, there was a solution that marginally improved the process that was discarded, because of fear that it would interfere with a larger project that never quite materialized. The larger the project, the greater the number of things that can go wrong; and thus, incremental steps of organic improvements are often the best - if not the most sexy - of solutions.

The other extreme, of course, is to keep patching a legacy system far past its workable prime. (A good rule of thumb for when to do the whole thing over again is when you find you can't fix one thing without breaking one other.) But by and large, people often overlook simpler solutions in the pursuit of their own grand plans.

Ultimately, reducing the failure rate in IT projects comes down to the paradoxes of being able to meticulously plan a clear path and being able to recognize opportunities and improvise when they arise.

Of course, these are just my opinions, and I could be wrong. Let us know what your theories on the high failure rate of IT projects are in our comments section below. Of course, we are particularly interested in those that pertain to networking and performance management.

Also, just a quick reminder, our New Years Resolution contest ends tomorrow, January 3rd, 2008, which is your last chance to submit your Network Performance Management Resolutions for 2008 for the chance to win a Nintendo Wii, TomTom GPS system, iPod Shuffle or iPod Nano.

Eight questions that will help you decide when it’s time to replace IT management products

With rapid technology growth and constant change we often lose focus on some of the products we purchased years ago, may not really understand their true cost, or really give much thought to better alternatives. This is particularly true in the case of some older management products that have become commoditized.

Every year, companies renew exorbitant maintenance contracts for dormant products from vendors that barely have a trained support rep on the other end of the phone. Such products have often been acquired as a cash cow and parent vendors starve their development, choosing high margins over more customer-centric advantages like taking advantage of new standards and protocols or integration with new architectures or solutions. Ah, the power of incumbency.

Continue reading "Old Technology and the Danger of Incumbency" »

By Brian Boyko
Editor, Network Performance Daily

There's an essay that's going around some of the top news sites, called "If Wishes were iPhones, then beggars would call," about the idea of 3rd party tools on the iPhone.

The main point of the article is this:

Apple has been unwaveringly clear that the iPhone is theirs. Not yours, not Ambrosia's, not J. Random Hacker's. You may own the hardware, but you only have a limited license to use the software, and an ongoing contract to use the network. If you don't like those terms, your only recourse is to shop somewhere else to begin with….

I don't understand this continuing obsession with buying things that you need to break before they do what you want.

I don't know what it is either; I just know that it exists. It is the urge in all mad scientists to go grave robbing for old, discarded technology that can be put to new use, to twist and mangle things into doing what they were never designed - or ought never - to do, to cackle with glee as we defy the laws of man, God, and nature to raise our voice up to the heavens, and scream against the thunder, "LIFE! GIVE MY CREATION LIFE!"

My first computer was built in 1996 - back in the days when IRQ conflicts were a serious problem and required setting jumpers to modify - by a family friend from old discarded PC parts that would have otherwise ended up on a rubbish heap. We dubbed it "Frankenstein."

The end result of all this stuff is an entire geek subculture, only starting to show through - of hardware hackers. In two weeks, for example, the Maker Faire is coming to our home town of Austin where people make stuff by breaking stuff - there's an entire sub-exhibit on taking old children's toys and making them into strange instruments - called Circuit Bending. There's a few displays which show off the capabilities of the Arduino, an electronics prototyping board which can be configured for a variety of purposes. And on the networking side; demonstrations of how to build your own Beowulf clusters.

But that's the geek mentality. Create. Invent. Remix.

Apple's whole business model is stifling those tendencies in exchange for providing a simpler product - and that's not a bad thing for Apple, because they get to sell to the 90% of the human population that aren't geeks and don't want to bother with figuring out new and exciting ways to do things. They even stopped carrying a mid-range tower line of computers. But if you notice, Apple sticks well to the consumer side of the market, not the enterprise side - sure, they have the Xserve, but they really haven't followed up with other entries into the enterprise market since its introduction.

In enterprises we've seen a trend over this past decade from big, proprietary system management frameworks to individual tools that work together, and I think that can be attributed to the Frankenstien Syndrome. Even Cisco is breaking up their IOS into different modules. We here at NetQoS sell all our products individually, even though they all work together through the NetQoS Performance Center Web portal. We even made it a clear goal to allow third-party Web applications - any third party Web application - to work with the NetQoS Performance Center. Figure out a way to map network slowdowns to Google Maps? Go ahead, we won't stop you.

Because it's important to harness - not stifle - those geek tendencies which make geeks so well suited for enterprise networking.

By Brian Boyko

Fingerpointing - it's a frustrating and lingering problem for IT organizations. Whenever, application performance degrades, all of a sudden application, server, and networking teams start pointing the finger at one another in an attempt to pass the blame. But isn't that why we have network monitoring tools in the first place - to tell you where the problem is, so that you can fix it faster.

Theoretically, yes. Unfortunately, network teams may be suffering from an undeserved "credibility gap" that prevents companies from taking timely action when problems arise.

For so very long, problems with network performance have often been laid at the feet of the networking team because, quite frankly, to the end user, an application problem, a server problem, and a network link problem all look like the same thing. "The network is slow." So even when it's not the network, the network team often gets the blame.

(Continued...)

Continue reading "Fingerpointing, Frustrated Network Engineers, and the Application Performance Blame Game" »

By Brian Boyko

In an early Network Performance Daily post, we spoke a bit about the impact that the Apple iPhone is likely to have on the company's IT department, and we thought that with some of the announcements of WWDC, it would be worth taking a look back and revisiting some of those ideas.

Back in January, we opined:

• People will use the iPhone at their jobs the way they use Blackberrys now.
• To the end-user, the iPhone is a personal cellphone, with no more need of IT scrutiny then their current phones. To the IT department, the iPhone is a mobile computer, increasing the complexity of the network and creating an additional demand of resources.
• The iPhone's rumored "phone over WiFi" capabilities means that even if you don't intend to roll out VoIP, you may still be dealing with converged traffic on your network.
• The iPhone's web browsing capability may draw additional bandwidth.
• The iPhone would be used as a gateway to SaaS software such as Google Docs and Salesforce.com.
• The iPhone is small enough to steal, requiring data to be secured.

Now that we know a little bit more about it, we can start to revise some of our predictions of how the IT department will have to deal with the new iPhone.

(Continued…)

Continue reading "I, Phone: Could the Apple iPhone's broad consumer appeal present a formidable threat to enterprise networks?" »

By Dr. Cathy Fulton

In the beginning, Al Gore created the Internet. (Okay, I have to be fair, Vint Cerf has given Al Gore a lot of credit for his work in government.)

IP version 4 was created back in 1981, and in August of 1990, at an IETF meeting, three individuals predicted that the IPv4 Class B address space would be consumed as early as March of 1994, the “date of doom,” and that would cause all sorts of issues.

That stimulated a lot of publicity and action, on how the address space seed shortage would be handled. A working group was formed in December 1993 that published a request for whitepapers asking for solutions to the IPv4 problem – including next-generation IP protocols.

They were so worried, however, that they would run out so quickly, that they believed there would be no time for new features. The ALE working group was tasked with determining how long they had before the Internet collapsed, due to routers unable to keep up with the increased routing tables. Could next-gen IP add new features, or did they just have to implement an emergency measure?

The working group came back with an estimate in 1994, and said that the collapse of the net would be somewhere between 2005 and 2011. That gave the IETF time to develop a full protocol, add new features, and figure out where they were going next.

In 1994, technical criteria by which the IP next generation protocol would be judged were introduced. The current specification was proposed in 1998, and is now a draft standard – one step away from full Internet standard.

So, where’s IPv5?

(Continued...)

Continue reading "The Evolution of IPv6" »

As readers can see, we’ve changed our “daily links” to twice-a-week Tuesday and Thursday links. This way we can provide a bit more commentary on each link instead of just listing them with little to no analysis. We invite our readers to give their opinions on this new format, and we’ll be looking to incorporate changes. One important note – if you have a link that you’d like to submit, please use the “submit a story” link on the left column of this page – we’ve been inundated with comment-spam and we wouldn’t want to accidentally delete your suggestion.

ZDNET: AMD versus Intel: CPU wars roadmap

George Ou at ZDNet graphs out the next two years of projected developments in CPU design over the next two years from Intel and AMD.

According to Kanter, the big reason for AMD's problem was Intel's manufacturing lead. While Intel was producing 65 nm processors all of last year, AMD was outputting 90 nm parts and barely got their first 65 nm product out by the end of the year. The significance of this is that 90 nm manufacturing with small 200 mm wafers produces less than half the number of wafers compared to a 65 nm process on 300 mm wafers. That means that while the price wars of 2006 put a damper on Intel's profits, it tore in to AMD financials because of higher chip fabrication costs.

Obviously the processing speed of the server will have an impact on request times, and if more data can be processed on the server side from more users, there will be more demand for Web-based apps – which could impact both application development and demand on network resources. Additionally, more computer cores means that there’s more room for virtualization… which you can read more about below.

Ars Technica: Buying OEM versions of Windows Vista: the facts

Ken Fisher has information about buying OEM versions of Windows Vista – you can get Vista Home Premium for $119, vs. retail at $239, but OEM versions cannot be reused with new motherboards.

OEM software is also tied to the motherboard it is first installed on. Unlike the retail versions of Windows which can be transferred to a new computer, OEM versions are not transferable. What about upgrading hardware? Microsoft says that anything is fair game, except the motherboard. Replacing the motherboard in a computer results in a "new personal computer," which the company considers to be synonymous with a transfer. It's not permitted with an OEM edition of Windows.

VMWare: Convert Physical Machines to Virtual Machines – Free!

Okay, imagine this scenario – you want to move to virtualization, but you have no idea whether or not you can switch over from a real server to a virtual one. Secondly, you’ve spent hundreds – if not thousands – of man-hours configuring and tweaking all the server’s settings for performance optimization, and you really don’t relish doing that again, multiple times.

VMware Converter quickly converts Microsoft Windows based physical machines and third party image formats to VMware virtual machines. It also converts virtual machines between VMware platforms. Automate and simplify physical to virtual machine conversions as well as conversions between virtual machine formats with VMware Converter.

Additionally, for the home user, being able to clone their existing installation of Microsoft Windows and then use it in the free (as in beer) VMWare player in Linux is a major stepping stone towards Linux migration.

By Brian Boyko

Back in November of 2006, (which seems like such a long time ago,) Network Performance Daily published a column by Carol Schiraldi about "why enterprise developers use Java and game programmers use C++."

We published this for a number of reasons - but the main one was that typically, enterprise developers are programming for function first, reliability, second, and performance over the network, if it's even considered at all, is a tertiary thought.

What this means is that applications, developed originally for the LAN environment, often take up valuable network resources unnecessarily when placed into a WAN environment.

[Full disclosure: NetQoS sells network performance management software which diagnoses problems like "chatty apps," and we want you to buy them. Anyway…]

But one area where this isn't a significant problem is in game development, which was the thesis of the original column. Game developers, who realize their games have to perform well over the Internet, typically build with performance in mind first.

This was confirmed when we had a chance to talk to Timothee Besset, a game developer at ID Software, developers of the famous Wolfenstein, Doom, and Quake series of games. Here's what he said about this issue:

(Continued…)

Continue reading "ID Software Developer Timothee Besset on Network Performance in Games" »