The biggest challenge to the fundamental migration from a hardware architecture to a software architecture is inertia, which is a much more powerful force in the voice world than it was and is in the computing world. A post on No Jitter today sums it up:
The historic tendency in the voice world -- unlike, say, PCs -- is to ride the gear until it drops, which is more like a decade than the five years it takes to depreciate it fully. Unless capital budgets for voice suddenly open up (seen any pigs flying lately?) or TDM support just disappears, a lot of true IPT deployments -- meaning new PBXs or the equivalent, and new station sets -- have been and will continue to be greenfield and places where the old stuff just quits.
So while enterprises may not love the proprietary model, they love the fact that the gear is paid for and works.
But let's jump ahead a few years, because eventually the gear will stop working, or at least will get so expensive to support that the cost/benefit will shift; or the PBX vendors will finally end-of-life/end-of-support the stuff, as is finally happening to the original voice mail systems that still are chugging away in many enterprises. When that happens, the move toward software-based systems will be almost irresistible. The question is how much of the interoperability issues will be resolved by then.
Today's IP telephony and Unified Communications software falls far short of the mark when it comes to multivendor interoperability. I recently completed a feature-length article on this topic over at No Jitter, where I went into a fair amount of detail regarding the obstacles to interoperability. Basically, the effort to use the Session Initiation Protocol (SIP) to build vendor-neutral systems that provide full legacy feature sets for PBXs -- well, let's just say that effort is struggling.
Meanwhile, Microsoft's competitors are attacking Microsoft for using a proprietary codec in the endpoints that talk to OCS. Microsoft says it's a better codec that provides a higher quality of experience in a wider range of network environments (especially the public Internet). The competitors say Microsoft is just being Microsoft.
Finally, there's the issue of federated presence. Presence is widely considered to be the heart of the UC system of the future. The presence engine is supposed to know the status of all the system's users at all times, and manage how that information is made available to others. If those "others" are all using the same UC system as the person whose presence we want to know about, everything's fine. If those "others" are on a different system, the presence engines have to federate, and that can be a complicated and difficult task. Interoperability in this environment is nowhere close, and even the aforementioned Microsoft-IBM effort is fairly limited in scope.
So if you're waiting for a Unified Communications environment that looks and acts like the computing environment of today, don't hold your breath. Such an environment may emerge eventually, but it's a long way off.