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 please read on.
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.
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 loose 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.
So … (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. Money involved here can be very high sums, and there is always nervous stake holders wanting to know there-and-then, the quick and accurate answer to the proverbial: “How much will it cost me” question.
I have seen many good architects, sweating and stuttering on meetings, just because they could not calculate (on the spot) rough estimates of their white board 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 the account three most basic attributes of any IT system: disk space, number of cores and the speed of CPU’s (Your PC or laptop is one example). And then we simply add them numbers all together, to arrive to 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 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 with the cost of it. You want just one thing: More power for less money. However snazzy the Technical Architecture looks, you want just one thing:
More power for less money
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 even funnier how easily CxO’s (and their entourage) who have 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.
Now, a simple example to help us understand what are we talking about. A concept in practice. Let’s say I am specifying 3 different options from the same vendor, for a single server. Here is my input table:[sourcecode] 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 (USD thousands) 60 30 17
System feasibility (SFI) 35.33 70.67 124.71
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 this.
And now the “mandatory part” for those lovely meeting moments powered by PowerPoint, in front of CFO’s and CIO’s brutally exposed to the eye-watering costs of implementing the Technical Architecture they will never understand but to which 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.