Perhaps the best answer to the proverbial question “Why would anybody do this?” is Bentley s “Programming Pearls“, Column 7: The Back of the Envelope.
Please read on for a bit more pragmatic approach to start understanding the costs of your IT system being planned.
Server?

Firstly the terminology. 1..N Servers we shall call a “system”. Thus and in this context, by “system” I mean: IT infrastructure. Machines. One or more servers. 1 to N
aka 1 .. N
.
Here we are talking about everything (as in hardware) that is being designed and priced together, as one single system. SharePoint is my focus last few years and SharePoint server farms is what first springs to mind. We are here basically talking about the quick but reasonably accurate CAPital EXpenditure (CAPEX) calculator.
It actually does not surprises me how people, who are paying for IT Infrastructure, easily lose the clear view of the pure feasibility of the IT infrastructure they are paying for. This is simply because the subject itself is (very) high tech, and the sheer quantity of detail is even more overwhelming than a naked price.
So … (a long time ago), I made a very simple “System Feasibility Index” to keep everybody calm and in-line, whenever discussing IT infrastructure design and options.
Please understand. The money involved here can be very high sums, and there is always nervous stakeholders wanting to know there-and-then, the quick and accurate answer to the proverbial: “How much will it cost me”?
I have seen many good architects, sweating and stuttering on meetings, just because they could not calculate (on the spot) rough estimates of their whiteboard diagrams. Regardless of the fact they have actually presented very good TA’s, invented (actually) there and then on the meetings.
The Core Concept
This “beck of the envelope” calculations core concept is really very simple, and some may very well argue too basic. But, I am claiming, still, it gives us a true, albeit high-level indication of the feasibility of IT infrastructure solutions.
First, we take into account the three most basic attributes of any IT system:
- disk space
- number of cores
- The speed of CPU’s
(Your PC or laptop is one example). And then we simply add them numbers altogether, to arrive at system power index (SPI):
SPI = (disk space) + (number of cores) + (CPU speed)
In the case of calculating the SPI for more than one server, we simply take the averages for the number of cores per machine and averages of CPU speed per machine. For the available disk space parameter, we simply add them all up: DAS, SAN, NAS, inbuilt … all of it.
Then comes the big one: the cost. For this, we use Capex only. Opex is directly influenced by who and where is implementing the infrastructure and thus can not be used to compare the system Technical Architecture feasibility. Opex simply tells us whose labour is more expensive. Nothing to do with hardware costs.
Fine. Input and philosophy sorted. So what is this System Feasibility Index (SFI) then? Here it is:
SFI = SPI / Capex cost
Huh? Well yes, it all boils down to this. It is as simple as that. Power of Your “kit”, divided by the cost of it. You want just one thing: More power for less money. However snazzy the Technical Architecture looks, you want just that one thing:
More power for less money
I do not mean to rub it in, but humans do make emotional decisions. Even when deciding what IT kit to buy. And that is a problem. It is funny how complex Technical Architectures (TA’s) authors and always “at hand” hardware sellers always forget to remind about this simple fact of life, to their faithful audience of CxO’s.
And it is even funnier how easily CxO’s (and their entourage) who have possibly made a mistake in the selection process, forget to mention this simple omission to their company boards. After the money has been committed to the wrong solution.
So, it is as easy as that. Stay composed when they hit you with a six-digit price tag. Do not ever forget to ask:
Can we get more power for less money?
The Practice
Now, a simple example to help us understand what are we talking about How exactly we do use SFI. From a concept to the practice.
Let’s say I am specifying 3 different options from the same vendor, for a single server to be bought. Here is my SFI table:
1 2 3 4 5 6 7 8 9 10 |
System name BL460 DL380 DL360 ------------------------------------------------------- Disk space (TB) 7.2 7.2 7.2 CPU cores 12 12 12 CPU speed (MHz) 2 2 2 ------------------------------------------------------- System power (SPI) 21.2 21.2 21.2 Capex cost 60 30 17 (USD thousands) ------------------------------------------------------- System feasibility 35.33 70.67 124.71 (SFI) (higher is better) |
I have multiplied the SFI by 100, to have it shown and differentiate a bit more prominent on graphs. Relative comparisons are not changed by that multiplication.
The higher the SFI the better system is
And now the “mandatory part”. Specially prepared for those lovely and tense, meeting moments powered by PowerPoint, in front of CFO’s and CIO’s, who are at that very moment brutally exposed to the eye-watering costs of implementing the Technical Architecture they will never fully understand. But to which they know they need to commit.


Summary:
One can argue that perhaps this is a crude method. Or perhaps not comprehensive enough, as a valid view on the IT infrastructure, QoS not mesured, etc.
But still, I find it priceless when helping people who pay for IT, understand what are they paying for.
2 thoughts on “Which server is feasible?”
Adding up various key component figures as a base line, so that is an excellent idea so simplify things; but different units of measure may skew the outcome. I would suggest use average price to normalize the base figure,
e.g.
intel xeon i7 2g =$200, instead of using 2 for SPI sum, we simply use $200 rather than 2.
but that doesn’t work for hard disk, as 7.2T is the maximum capacity; if all filled it will outweigh the cpu cost.
Also in our case, we have to buy DL380 because we need full raised F/C card which DL360 couldn’t host; so how to address expansibility?
charles
@Charles, thanks for the commendation.
This concept stands as it is for both physical and virtual machines.
As a such Expand-ability is an attribute primarily of the physical realm of the IT Infrastructure.