SOA, SOP, or SOL?SOA, SOP, or SOL?

I've been writing and thinking a lot recently about interoperability, and about the widespread expectation within the enterprise communications industry that real-time communications will move toward software-based architectures. That migration certainly is under way, and it's inevitable that, as voice and video traffic ride on IP networks, applications using voice and video will function in a fashion similar to "data" applications.

I've been writing and thinking a lot recently about interoperability, and about the widespread expectation within the enterprise communications industry that real-time communications will move toward software-based architectures. That migration certainly is under way, and it's inevitable that, as voice and video traffic ride on IP networks, applications using voice and video will function in a fashion similar to "data" applications.And yet I think we shouldn't underestimate the demands that real-time performance requirements will place on these new software architectures for multimedia applications. And I think that the migration to Unified Communications based on the Session Initiation Protocol (SIP) and Services Oriented Architectures (SOA) will be more protracted and challenging than many folks are letting on, at least if what we're talking about here is a thoroughgoing replacement of legacy TDM voice with UC, in which voice and presence capabilities touch every part of the business IT infrastructure.

To explain what I mean, let me juxtapose 2 posts that ran here last week. One is by John Bartlett of NetForecast, our go-to guy on network performance, QOS, etc. In a post titled "Queuing and Router Output Rates", John describes how a fairly simple configuration issue--not an error, as such--can degrade voice quality. You should read the post for the details, but the upshot is that if priority queuing is implemented in a WAN router but not in a DSL modem or other access device sitting between the router and the access link, you can wind up with bad voice quality that you might never have anticipated.

The second post is by Tom Nolle, who wrote about managed and hosted services, but along the way touched on a real concern about SOA. "While Web Services are a powerful tool in application development and deployment, it's possible to build applications in a way that creates tremendous performance bottlenecks," Tom writes. "Many times development teams, focusing on a mandate to use 'state-of-the-art SOA techniques' and 'create Web Services to increase modularity and portability' will forget that too much SOA can slow applications by an order of magnitude."

So why do we think that we're going to integrate voice into business process applications and it's going to sound just like it sounded; and work just as well; and connect just as quickly, as when voice connections were being handled by a dedicated system whose only job was to effect those connections and carry that traffic? Especially since we're talking about a legacy system which was almost the definition of mature technology--it had been doing that task in one way or another for about a century, and in the current digital form for a quarter of a century.

You juxtapose those two posts and you say, if basic IP packet queuing can still trip you up on voice quality, how densely will the tripwires be deployed in the minefield known as communications enabled business processes (CEBP)?

I'm not saying we won't ultimately want to go ahead and make the tradeoff anyway. I'm not saying it won't work, period. But it is worth pointing out, as I have in the past, that with CEBP, you are putting traffic that by definition is business critical, onto a system that has a lot of moving parts and whose design was created with reference to many considerations that relate not at all to the quality of voice performance.

It's in no vendor's interest to remind you that it will be a major effort in development, deployment, monitoring, management, and troubleshooting, just to get voice performance to the level in CEBP as it was in TDM voice.