A fundamental of digital signal processing is something called the “Nyquist Rate.”  In layman’s terms, it describes how often you have to observe something to be sure you don’t miss anything.  Nyquist was working with electrical signals, and figured out that if you look (or in digital signal processing terms, sample) a signal at twice the rate that it could possibly change, you are guaranteed of catching everything.  Ever wonder why CDs are sampled at 44Khz? CDs are sampled at 44Khz because humans can’t hear above 20Khz, so there’s really no point in sampling any faster. The extra 4Khz? You can save money by designing lower quality filters and sampling a little higher.

What does this have to do with services development? Glad you asked. A friend tweeted me earlier today with a joke about how I was designing fast, and how if you spent a year on specifications you could design really fast after that. That got me thinking – is there a maximum length of a modern services project? Is there a development cycle so long that it doesn’t make any sense to complete, and if so, how long would that be?

Enter Nyquist, who I think might provide the answer to this question.  Maybe the maximum length of a modern services project should be no more than one half of how fast the market can move. Stay with me here.  Perhaps modern businessmen should ask themselves how much of  a market window they have, then plan to introduce a product or service no more than half of that amount. If they can do this, then they can guarantee that the market hasn’t moved on them. Well, theoretically.

For me, this is yet another drop in the bucket that supports Web as Platform development for telecom.  Using a traditional approach, new service introductions are measured in quarters, and takes as much as two years to vet and bring to market. In that time frame, markets move, and services fail.

Four years ago, I was asked on stage by Carl Ford to speak about service creation along with the head of a European carrier. At the time, I was thinking deeply about horizontal vs. vertical service opportunities, and was concluding that carriers would always be unable to provide vertical applications – and that would be a killer. As I pressed the point with my friend on stage, it became clear that our realities were different, and I soon found out why:

What he didn’t say publicly, but admitted afterwards in a side conversation, was that the problem was in the structure of carriers – they were too large, and the opportunities too fleeting, to really take advantage of the very niched application. I hope I didn’t offend him when I suggested that the problem was with today’s carriers, not tomorrow’s.

Four years later, I see the issue, and the solution. It’s not about niched application sometimes, it’s about sampling rate.