The trouble with development work is that it tends to be
unpredictable and spikey. There are typically no SLAs to manage to and
often the only guide is complaint.
One question is who pays for the processor upgrades ? The developers ?
If not, what justifies the need for an upgrade ? The capacity planner
or developer complaint ?
Your predictive method is pretty much what I would use. Unfortunately
developer estimates of future CPU needs can be inaccurate. plus
development efforts come and go. This said, you might look at the new
IBM z9 BC processors. They range from very small to more than 1800
MIPS in lots of small upgrade increments. z9 processor upgrades are
all done with microcode so there is no physical hardware installs. The
idea is get what you believe you will need for the next year (or a
time frame appropriate for your organization) or so, monitor its
consumption, and upgrade in small steps as is necessary..
.
Stahl, Marty wrote:
I am looking for ideas about sizing an large development shop.
Our organization has a development shop that is larger than many full
shops I have been in. The Test Sysplex currently uses 2000 - 2500 MIPS
and continues to grow. Historically, we have managed to keep just ahead
of their demand. However, lately demand has sometimes gotten ahead of
us. Currently, while it is something of a problem, its impact is
lessened by the fact that the development sysplex share hardware with
production and has been able to borrow MIPS from time to time.
We have also outgrown any commercial backup site, so we will be dividing
our workloads along natural lines and will have geographically dispersed
sites. The initial workload moving to the new site will be the
development work. Hence the question of sizing. Initially, there will be
no other work to borrow from, so the size we pick should allow
development to continue unhindered without providing excess resources.
Of course, there is Capacity-On Demand. It's a nice feature. However,
when we add a processor, we add cost. And we can only spend what has
been budgeted... so we need to be right, or very close to it.
Currently, we primarily base our projections on history repeating
itself. That is we fit curves to our historical data and then use the
most similar curve to predict the future. Additionally, with new
work-loads, we get estimates of the size of the effort (i.e., number of
programmers, lines of code, whatever) and adjust the historical by our
machinations based on specifics. As I say, we have historically done
well with accuracy. However, with the developers moving to a separate
environment, it behooves us to look with greater diligence with future
projections.
Your assistance is greatly appreciated.
Best Regards,
Marty Stahl
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
