FW: Total Cost of Ownership and porting (was FW: Can we have a mo ment of silence (or several million dollars) . . . please?)

Schilling, Richard RSchilling at affiliatedhealth.org
Tue Jun 26 12:44:37 PDT 2001


> -----Original Message-----
> From: Greg Lindahl [mailto:lindahl at conservativecomputer.com]
> 
> Well, yes, but it's hard to give that info to anyone else and have it
> mean something. My FSL customer is in the business of writing portable

One way is to create a set of standard terms and characteristics to qualify 
the costs.  For example, the following might mean someting to everyone:

PORTABILITY BASELINE COST: the amount of work required to get the code to
compile.
	A measurement of hours for a given hardware platform and an
associated level of complexity 
	for the work (from best case to worst case):

	1 - no code changes.  Just recompiled and ran without modification.
(e.g. ./configure -> gmake -> gmake install)
	2 - configuration files needed changing (e.g. edit Makefile.in,
configure.in, environment settings, etc . . .)
	3 - some libraries needed installing on the target machine, but
could be installed (e.g. pthreads library)
	4 - some libraries needed installing on the target machine, but
could not be installed. New libraries could be created.
	5 - some libraries needed installing on the target machine, but
could not be installed nor recreated in a way that would allow the ported
application to run as intended.
	6 - the software needs to be completely rewritten due to targeted
hardware configuration.
	7 - the software needs to be completely rewritten due to poor code
quality.
	8 - existing code unusable on the target machine.  Number of hours
to determine this would then be noted.

	. . . or something like this.

	As part of the initial data gathering for this rating system, some
analysis of the hours reported would need to validate the usefulness of the
ratings for level of complexity.

BENCHMARKING COST: cost in hours/resources to establish a comparative
benchmark between the software run on the old machine and on the new
machine.  For example, how much faster does pvmpov run on the new machine,
compared to the older one for a given set of input files?

DEPLOYMENT COST: cost in hours/resources to deploy the new software on the
cluster.

HARDWARE CONVERSION COST: resource outlay to get the new hardware and have
it installed.

TIMEFRAME: what is the timeframe for the porting?  This could be set by the
manufacturer (via end of life practices), or the implementer (via adoption
rate practices).

EMPLOYEE COST: Once the scope of the porting work is established, how many
employees will be required, and what is the cost of recruitment, if
necessary.

DOWNTIME: The cost associated with bringing the existing system down (out of
production) to perform the upgrade.



I suspect that taking an itemized approach to this will get people thinking
about comparative cost analysis.  It's a natural step for those that do it
for a living.  In health care we do something similar all the time for new
systems.





More information about the Beowulf mailing list