[AccessD] The Business Side Of Databases

Gustav,

The client won't know any details except that they will get a line item on a
bill for a process run.  How I arrive at that line item is not disclosed.  I
am currently in a position where the client decides when and how often to do
these processes.  There are pros and cons (in my case anyway) to doing it
either way, flat fee or by the computing hour.  

The pros of a flat monthly fee is that I have a fixed income.

The cons of a flat monthly fee is that I have a fixed income.  Plus I still
have to somehow figure out how much to charge them (what the flat rate will
be).  Plus the client can decide to process address validations every week
(every day?) if it is a flat fee.  Why not submit validation orders every
day since it wouldn't cost them any more than once a month? 

With an hourly fee they can soon get a feel for a "cost / record" by
comparing the number of records processed by the cost to process the chunk
of records.  Thus they can decide to process records more or less often.  If
it is more often, they get a more accurate address list and I get more
money.  Less often they get a less accurate address list and I get less
money.  In all cases, they process addresses for deliverability and change
of address so that they can avoid costs of mailing pieces that never get
there.  So they have an incentive to keep their lists accurate.  Since (in
this case) they sell the addresses to their clients, having up to date
address validation is a marketing point.

So my clients will never know anything about FLOPS and processor minutes.
They will know that they processed 100K addresses and it cost them X
dollars, and they received Y address corrections.  All of those statistics I
can provide or they can calculate themselves.

BTW, I am watching my machines compute as we speak.  My laptop is the
machine running the ExportToCSV process (written in VB.Net, pulling data
from a SQL Server database) and it is running about 50% average processor
usage (50% total CPU time for both cores).  The SQL Server is running about
6% usage for both cores.  This tells me that I need to do one of two things,
either set up virtual machines on the SQL Server and let the ExportToCSV
process run on that machine in a virtual machine, or set up VB.Net process
servers on dedicated boxes talking to the SQL Server.  Interestingly, the
data transfers between my laptop and the SQL Server is only using about 2.5%
of the bandwidth of a gigabit LAN for very narrow spikes, every 16 seconds
or so, so I am not network limited.  If I am able to queue jobs I think I
could have a robust business going here even with moderate hardware.  

I am currently processing a 90 million record file, pulling 1 million record
chunks every 4 minutes.  So this job will take about 90 * 4 minutes to
EXPORT THE DATA to CSV for Address Validation.  

I am now processing one of the 1 million record files through the Address
Validation server and it is saying that it will take about 15 minutes to
process each file.  Thus the AddressValidation (on this machine, which BTW
is pegging the single core processor) will cost 90 * 15 minutes.  And
obviously I need to move to a more powerful machine for this process since
this is a bottleneck.

Once I am finished with this I have to import the data back in to SQL Server
(for this client's job).  The validated address file has a ton more fields
(returned by the validation process) so I assume it will take significantly
more time to import back in to SQL Server.  

But the point is that:

A) The client wants this done!
B) The client currently pays me a consulting wage to manually perform all
this stuff and monitor the processes.
C) The client will now pay me a "computing wage" to automatically perform
this process.
D) On this one job I will be paid a "computing wage" for something like 30
minutes * 90 files, or 45 computing hours.
E) While the "computing wage" is less than my consulting wage, this process
will complete in less than 2 days with very little manual intervention
(eventually none under normal circumstances), while consuming 1/2 of the
processing power of one dual core machine for the VB.Net processing.
F) The cost they were paying before to their previous service provider was
something like $1.25 / thousand address validated, AND they were paying that
every time they selected names.  $1.25 / thousand turns into $1.25 * 90K to
do a 90 million record file (112 THOUSAND DOLLARS).  Of course they did not
do the whole file at once, they simply did it for each order that they
shipped, EVERY TIME they shipped an order.  Orders run anywhere from 50K to
a million (or more) records apiece so they would just pay $1.25 for every
thousand they shipped, every time they shipped, even if they shipped the
same addresses (to different clients).

Thus doing it the automatic way they can easily do the whole list once per
month, for a thousand or two, then ship as many names as they want without
worrying about more address validation costs every time they ship an order.
And I can easily show them how much less they pay doing it this way than
paying a "per thousand" through their old provider.  AND... Of course I get
more work (again, mostly automated) shipping the addresses to their clients!

This looks like a HUGE win/win for both me and my client!  Isn't that what
we all hope to achieve?
	
John W. Colby
Colby Consulting
www.ColbyConsulting.com 
-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Gustav Brock
Sent: Thursday, June 28, 2007 6:05 PM
To: accessd at databaseadvisors.com
Subject: Re: [AccessD] The Business Side Of Databases

Hi John

Too bad. I was just about dusting off two old Pentium 266 MHz IBMs I planned
to send to you proposing a commission deal.

Seriously, I think you go too much into detail. The clients probably don't
care about FLOPs or CPU minutes, they are just happy having you to take care
to get the job done. We do something similarly and simply charge individual
flat rates per month which the clients find fair.

/gustav