Perhaps the best answer to the question “Why would anybody do this?” is Bentley s “Programming Pearls“, Column 7: The Back of the Envelope. But if you do not have such a fundamental conundrum confusing you, please read on for a bit more of a pragmatic approach.
Which server is feasible?
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. 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 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 case of calculating the SPI for more than one server, we simply take the averages for a 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 labor 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 with 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. Anf that is a problem. It is dunny 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?
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:
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 it 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.
One can argue that perhaps this is a crude method. Or perhaps not comprehensive enough, as a valid view on the IT infrastructure, QOS, etc.
But still, I find it priceless when helping people who pay for it, understand what are they paying for.