|
The
Blade Chronicles - Part 6: The Upside of Blades
The first blade vendors were trying to save space and energy. But
the most compelling benefits of a blade architecture comes from
improved availability, integration, configuration, and management
features.
In good blade systems, everything is hot-pluggable - the blades,
their disks, the power supplies, Ethernet switches, and fans. Blade
components also provide for lots of redundancy - power supplies,
switches, fans, and backup blades.
Integrated Ethernet switches do away with tedious installation,
cabling and tagging chores, clear away the cable mess, and use negligible
amounts of power.
Vendors are starting to incorporate SAN connectivity into their
product designs. This simplifies the SAN implementation process.
The chassis management module is the mission control center of
a life-support system. Failing hardware elements are detected and
reported immediately.
A blade failure is detected quickly, and the blade's workload can
be shifted to a backup blade automatically. Alternatively, after
a blade has been removed and replaced, a software image and set
of configuration parameters can automatically be downloaded onto
the new blade, which then is booted and is ready for action. The
whole process completes in a few minutes - and might take only seconds
with a SAN.
Blade architectures forced system vendors to provide management
tools that support software deployment and inventory management
for large numbers of servers. Management capabilities became a major
competitive factor, and this triggered the rapid development and
incorporation of new features. Systems management in general is
sure to benefit from this contest.
BONUS EDITORIAL
PROJECT ROI - Part 14: More on Return on Requirements
Last week we wrote about taking features and functions and tying
them to an ROI model. For many years we have categorized requirements
into three buckets: mandatory, must have and nice to have. We would
like to consider a different categorization: baseline, yield, and
non-yield. A baseline is a requirement that without it, the system
will plain not work. Examples of this type of function might be
database access or a read to a magnetic card. Yield requirements
are items that an ROI number can be assessed. Non-yield functions
are functions that are neither baseline nor can they show a return.
This process is iterative and dynamic. First you start with an
ROI for the project; remember a reliable estimate is a key ingredient
to an accurate ROI. You then take each requirement and put it into
one of the three new categories. Calculate an ROI on each of the
"Yield" features and functions, and add up all the yield
numbers. Subtract this figure from the overall ROI. That is your
baseline ROI. (If you come out with a negative number you have done
something wrong.)
You can start the project off by completing the baseline requirements.
Once the baseline is complete you can implement the system or wait
until some of the yield items are functional. Next, start with the
high yield items first and work you way down the list. As each requirement
gets competed don't forget to reassess the ROI and priority. Implementing
as rapidly as possible is a key to maximizing ROI and gaining feedback
on feature relevance. Non-yield functions need to be considered
on a case by case basis. Project ROI should not be a one-time or
static event. It should follow the life cycle of the system.
|
