Wheels within wheels in a spiral array,
A pattern so grand and complex.
Time after time we lose sight of the way
Our causes can’t see their effects.

Settling in back home after a week in Boston, I grabbed chance to download and look over the presentations for the sessions I missed. One session I would have really liked to see was the one that Henry Sinnreich gave about Peer to Peer SIP. I must confess that, since I’m really heads down on light weight application programming models, I haven’t been following this scene too carefully. It’s too bad, because the PDF is excellent, and I’m going to spend some time this weekend following up on some new details I found in it.

As I was reading it, I found the following architecture diagram of the current IMS architecture :

As I enter my twenty second year of paid engineering, I realize that complex problems require some level of a complex solution. The task taken on by large carriers to deliver new services is certainly complex, and as reported to me by an IMS insider last week, is getting more so since IPTV is now part of the IMS family. As the range and scope of services that carriers taken on increases, so will the complexity. IMS is an effort to control and manage this complexity, but it will certainly never eliminate it. Software engineers discuss two sorts of complexity : essential and accidental. Essential complexity exists because of the problem itself – it is irreducible. Accidental complexity exists because the solution to the problem is non-optimal, and therefore can be engineered away with enough time and effort. The essential complexity of delivering multiple media-rich services to heterogenous endpoints is high and growing higher, and the above diagram reflects that basic fact.

My research into the extension of the business process with real time communications reveals that the essential complexity is quite low for most applications that address this need. Sending an outbound message to notify a customer that their car is ready is fairly straight-forward. Collecting information through a phone based web survey is a simple matter of a VXML script and a web server. Not only are these applications low in complexity, but they are high in value to the enterprise and the customer. Further, as I scan the verticals, this rule seems to hold fast.

When viewed through the comparison of commoditized carrier offerings versus high-value, sticky niche enterprise applications, what amazes me is the amount of time and money spent on researching and developing IMS architectures, versus that spent on light weight programming models such as mashups. If I didn’t know better, I’d say that fundamental research doesn’t have to be performed on something so straight-forward, simple and obvious. Hey, how much research money is spent on hammers and screwdrivers? The sad fact is that answer is different, and that fact is that the large vendors have vested interests in staying large, so they stick to the hard problems instead of seeking the maximum benefits for marketplace.

I wonder how efficient the market really is in eliminating waste and rewarding those that create long term, sustaining value.