Keep Your Perspective on Platform Costs

by Timothy Prickett Morgan

As a server industry analyst, which I do in addition to my job as an editor and reporter in the IT industry, I spend a fair amount of my time listening to the technical jibjabbing and marketing jawboning of the major and minor players in the server market. I also often do original marketing, technical, and economic research for various platforms, and then do a fair amount of jibjabbing and jawboning myself. I can't help myself, any more than server engineers and marketeers can.

After two decades in this business, I still find servers fascinating and I relish the competition between platforms. That's because these platforms run the world's businesses, and they make it possible for us to do work, get paid, buy things and pay for services, and interact with each other on a global scale. What servers do matters very much in this world, and innovation matters in this area. But keeping a tight focus on just the server platform itself--as I often do and as many IT managers and chief financial officers or business owners often do--is a dangerous thing. You have to keep your perspective on what the relative costs across different platforms really mean. There are intangibles that make a great deal of difference in how an IT shop is run, and there are other costs that far exceed the cost of the server platform.

I expend a lot of effort each year making intricate performance and price/performance analyses to compare various server platforms. I take great pride in this work, since it fills in many gaps that the server makers quite intentionally leave in the data that they present to their existing and prospective customers. And as you well know, I get indignant when any one platform gets too far out of whack from the others. My testiness is not just reserved for the iSeries Division, although as a reader of The Four Hundred, you may only see my grumpiness when the iSeries is out of line with the rest of the industry. (A good example is the lead story in last week's issue that talked about the relative bang for the buck of the iSeries running Domino groupware.) But just to be clear, I don't just lean on the iSeries Division. Readers of the other IT Jungle newsletters--which, of course, includes many of you reading The Four Hundred--and readers of other publications I have worked on over the years have seen my curmudgeon side when one or another non-iSeries platform has fallen behind the pack. I am an equal opportunity critic, and by the way, I am just as critical about the machines I build myself. So the first point I want to make about perspective is that each server architecture has its own limitations, and that is just the way it is. Some architectures with limitations have some substantial benefits, too--and that is why they have not gone extinct.

But there is an important other kind of perspective companies need to have when looking at their data centers and the servers that live there. This has to do with taking into account all of the real costs of doing transactions. And this is a very slippery and difficult kind of comparison to make, because every company is unique in regard to the servers they have, the applications they create, and the skill sets of the programmers and end users who make and user the platforms. But a fair comparison would take into account all of these factors.

There is no way to make such a comparison, of course, but I can illustrate the point and then show you the relative magnitude of costs both in the data center and outside of it that are related to the job of processing transactions--of doing business. The performance and price/performance comparison of server platforms that accompanies this story is a little different from the ones I usually do. My purpose in doing this was to illustrate a concept that we all know intuitively, but we may not realize the magnitude of the numbers because not every one of us is dealing with an IT budget or the corporate budget. The new comparison is based on the most recent set of actual and estimated TPC-C online transaction processing performance and costs that I have been developing over the past year or so as server makers brought new machines to market. The main point I want to illustrate is that server costs are utterly dwarfed by the costs of the IT personnel budget, which is miniscule compared to the cost of employing the actual end users who bang away on the keyboards during the course of the business day.

As is my traditional practice, I have created a detailed spreadsheet that shows the configuration, performance, and costs of various server platforms. For this exercise, I compared i5 machines to p5 machines from IBM to the cost of Windows-based ProLiant and Unix-based Integrity machines from Hewlett-Packard and various Unix boxes from Sun Microsystems. There are a total of 36 different server configurations in the table that accompanies this story showing these price and performance metrics. This list is by no means exhaustive, and is intended only to be illustrative. It is also intended to give you an arrow in your quiver as you defend the platform of your choice at your company.

When I build price/performance configurations, my intent is usually to gauge the various, base configurations within a product line and to show the peak processing capacity of this processor complex when it is equipped with an operating system, and if it is an OLTP workload, a relational database. That is exactly what is shown on the left side of this table for this story. But instead of simply dividing the cost of the server by the throughput in transactions per minute (TPM), I did something else. I divided the TPC-C TPM by 250 to calculate a reasonable amount of users who might actually sit at the machines. As most people are well aware, the TPC-C transaction is a little bit thin compared to modern transactions, and more importantly, real world end users are nowhere near as efficient as computerized, simulated end users. Having done this, I also adjusted the throughput of the boxes down by the same amount, and then multiplied the peak throughput by a 260-day, eight-hour normal business cycle, and figured out how many adjusted TPC-C transactions each box could do. In every case, for servers large and small, it is a staggering number of transactions. I then spread the cost of the server platform over three years and divided it by three years worth of transactions.

The server component of each transaction ended up costing a fraction of a penny. While there were big differences between platforms--exactly the same as if you were doing a dollars per TPM comparison--when you say it this way--a fraction of a penny--it just doesn't sound the same.

As we all know, the cost of the server is a tiny piece of the IT budget that goes into creating the infrastructure that allows a transaction to be processed. Just to get a baseline of IT people costs--and I know this is not thorough, but bear with me because I am trying to make a point--I added in the costs of system administrators, programmer/analysts, and IT managers on top of the server costs. For small machines, I have just put a programmer/analyst into this theoretical IT budget, simply because a lot of small sites only have one person on staff. For larger machines, I added in the salary costs of programmers and then an administrator, and for the largest boxes, I added an IT manager and then multiple administrators and programmers to the boxes. To keep it simple, I used the same rough algorithm to come up with the counts for these IT personnel. And ignoring regional and geographical salary differences, I paid these virtual IT people the same salaries: $45,000 for a system administrator, $60,000 for a programmer, and $85,000 for an IT manager. When you add these costs to the costs of the server, it starts to mask some of the server platform cost differences between platforms, mainly because the order of magnitude of this relatively simple IT personnel budget is somewhere between five and 40 times as high as the cost of a server when the costs for both are spread over three years. But even this personnel cost is nothing compared to the cost of end users.

Now, let's add in the cost of end users, who I am only able to pay $20,000 a year. Even for 20 end users on a puppy i5 520 Express machine, the cost of those end users is $1.2 million. This is, I admit, a ridiculously low salary, and it does not fully burden the cost of the employee. But the point I am trying to make is this: if you add in the cost of the server, a skeleton IT staff, and end users to create a very rough metric for the cost of a transaction, it ends up being somewhere between 16 and 19 cents per transaction. Most of that cost is the end user's salary, which ignores the cost of their desktop, health insurance, and a zillion other costs.

Clearly, when it comes to transaction costs, it's not just a question of money or platforms, but rather a question of priorities, experience, and application architecture.

Looking at it from a holistic point of view, the best way to cut transaction costs would be to automate transactions to the greatest extent possible and to create application screens that end users understand and can navigate through in a quick manner. Making end users even 10 percent more efficient could more than pay for the cost of a massive data center upgrade that the CFO or business owner might not want to pay for because it is unjustified. Cutting back the number of end users, letting them process more transactions, and giving them applications that allow them to offer better customer support or do more cross selling is, even using these admittedly very rough numbers, clearly a vast untapped resource.

The lesson is that the platform is not as important as what you do with it.

That doesn't mean that the server budget or the overall IT budget doesn't matter. This does not mean that IT managers do not have to justify their server acquisitions and upgrade plans against alternatives in the market. But the important thing is to not lose perspective about why we buy server platforms in the first place. If you can make a platform sit up and bark and it happens to cost more than other boxes, it may be worth the extra money compared to jumping ship to another platform. Or it may be that the applications you create and that your end users love may more than pay those extra costs, too. Focusing on how to make end users more productive, and perhaps even eliminating large numbers of end users by putting in Web-based self-service and other transaction automation functions (like call routing and other things that have long been used in call centers).

What you need to do is do your own math, and figure out what your own transaction costs are and where you can cut costs and improve the service to end users and, ultimately, to your company's customers. That is the best way to justify whatever platform you chose to deploy your applications on. So sharpen your pencils and get out your stop watches.