Real-Time Versus Just-in-Time -- Dollars Versus Sense

If you haven't picked up this year''s Perspectives 2011 yet, be sure to do so--it has some excellent articles that provide what the publication's title promises.

An article into which I had some input was John Williamson's Retail models need real-time billing.  In there, he quotes my oft-repeated advice to consider the just-in-time concept from manufacturing best practices instead of choosing real-time (often just because it can be done).

A story from my past experiences puts the issue in stark relief to make my case.  A firm in which I served as the Vice President of Engineering, Metapath Software Corporation, was awarded the contract to deploy the usage data management and element provisioning mediation system for the rollout of the Sprint PCS nationwide network (180+ markets), all in six months, by the way.  We had sold the solution as providing "near real-time" (the marketing gurus nixed my suggestion of "just-in-time" as sounding too geeky) delivery of usage records from the various network elements to a central repository for use in billing, network management, and customer care.

After we won the contract, we had to figure out what we were on the hook for technically (never confuse selling with delivering).  Previous generations in the fixed networks had replaced tapes and overnight freight delivery with teleprocessing twice daily delivery, and we had taken that to the second generation for wireless where it was streaming delivery to a queryable repository.  What remained was the question of what should be the latency of the data with respect to accessing it from the repository, once generated at the element end.  There were some technical limitations on the range of latency that could be acheived, but we were pretty sure we could acheive sub-minute figures, it was just a question of how much less than a minute we could and should do.  The could and should distilled the question as succinctly as could be.  If we could do 1 second, should we?  If we couldn't do 1 second, what must we (there was an expectation set in the customer's mind, after all, from the "near real-time" of the sales pitch)?  At issue beyond the technical bounds was the cost of acheiveing a given result.  One minute would cost less to realize than would thirty seconds, thirty less than 15, and 15 less than 1.  So the question had to be:  "What was the highest number we could afford to deliver and still meet the lowest number actually required by the customer?"--all the while realizing that the contract price was fixed and it was down to cost to reap a profit from the contract.

The solution came about in a way that ensured success--we asked the customer what business problem we had to solve with whatever performance we acheived in the implementation, and then analyzed that to determine the answer of what "just-in-time" meant in reality.  The most demanding business use case was that of a dropped call, followed immediately by a call to customer service to demand a credit.  It was critical to Sprint PCS that the Customer Service Representative be able to have the Call Detail Record (CDR) available in the repository to pull up on their dashboard while on the line with the complaining customer, thus giving the excellent experience of seeing that the Service Provider had some visibility into the Customer Experience.  Analysis of the use case determined that a 30 second latency would properly support the scenario in question.  Coming from an Electrical Engineering education experience, I applied the often-prudent 100% design margin rule applied in many business-critical applications, so we designed and impelmented to a 15 second requirement--and made it!

I can tell you that if 1 second were even technically feasible in those days (probably not, due to circumstances out of Metapath's control), it would have at least doubled the delivered cost of the system and we would have been unlikely to make one dollar of profit on the multi-million dollar contract.  On top of that, the customer wouldn't even have been aware of the overkill, nor put any value in it, so would have shown no sympathy for our monetary distress.

The moral of this story is that a system-wide, business use case-driven analysis of the true need for real-time versus just-in-time is a case of "Dollars Versus Sense".