Having a "quiet time" opportunity, I used the moment to watch the Enterprise 2012 Locknote session, which I found interesting and compelling.
Interoperability
Zeus Kerravala made a good point about middleware and I think a great example is BlueJeans Network. Andrew Davis made the comment, "I just want it to work" and without having to know what the other user or company is using for their video solution. Andrew also went on to elaborate that “users just want to call other endpoints." But does this really matter? How many choices do users have, how many do they really need? No doubt service providers like BlueJeans Network are going to prosper and people will still retain their choices of video gear, hardware and apps.
Still, another example of middleware is found as an integral part of Microsoft Lync deployments because without it, there would probably be fewer licenses sold and less voice penetration.
But what exactly is middleware? According to the Middleware Resource Center:
"Middleware is the 'glue' between software components or between software and the network, or it is the slash in Client/Server"
The discussion about standards and interoperability really needs to include using standards as a framework. Sure interoperability is important but so are open source and proprietary solutions. Then, without middleware, how far behind would we be today?
I don't see standards going away and interoperability is going to be an issue until the end of time. Open source isn't just novel, it's required glue that even Microsoft has taken a fancy to. Taken as a collective: standards, open source, proprietary solutions and middleware--it's really pretty amazing that all this stuff does just work and that this mix keeps improving.
Too much time was exhausted trying to exorcise "proprietary" out of the industry, and the word became demonized instead. Without proprietary, we’d be decades behind. Proprietary works pretty well whether you're talking about protocols or telephone systems, so you can thank either Cisco or scores of vendors that continue to develop and sell solutions with proprietary components.
Dave Michels made a good point on openness and "getting everyone in and out," and it's going to be challenging in communications to do it transparently, securely, cost effectively while maintaining acceptable quality. Welcome aboard middleware and open source solutions.
Network Management Tools
Fred Knight opened the question of complexity and noted the layers of complexity that users are riding on. The reality is, it is complex and there isn't one guy to call to fix your problems. Who's going to provide the tools? Which tools? This is another trip down memory lane and as Zeus points out, there are numerous decision points. Then hearing that "convenience trumps quality" doesn't mean that network management tools and MOS scores are thrown out. I disagree with the premise that monitoring isn't needed. Business knows that reactive fixes almost always cost more than proactive monitoring and management steps. I believe the same thing with call quality; it is important and allowing user tradeoffs of convenience for call quality and/or time will continue, just not as the rule for enterprise class communications.
A few weeks ago one of our sites had a T1 that went down the tubes with rain--yes rain! As expected and because we were "monitoring," a (proactive) trip Sunday night to the customer premise resolved the T1 degradation issue not with a hair dryer but by removing in-line protective fuses. Monday morning that company staff was online and working. Otherwise no monitoring (reactive) meant an easier Sunday night but a potentially ugly Monday morning because a company is road-blocked, at the front gate, from conducting business as usual.
There were a few other comments that didn't carry a lot of discussion. On federation: "Microsoft is a common bond." This is something that Microsoft deserves credit for. Their software has a huge global presence. With Lync, Microsoft found a new way to make themselves needed. I recognize communications glue and Lync is a glue; it's not the only glue, but Microsoft has presence and that counts; and this will contribute to more scrutinized decisions for companies considering purchasing a PBX. Thinking about it further, Lync sure sounds more like middleware to me.
Then, "IT's role is shifting to a consultative one"--and then I heard "management consulting" and "behavioral changes.” Consultative selling should be a key focus area for IT departments, and if this shift proves to be a trend among many IT departments then it will be one with opportunity. Along with opportunity comes new challenges and this is where I think IT stands to benefit or fall short. Six Sigma and lean six sigma should be in your thinking and it better become an ingrained best practice.
New tools are required, along with changed mindsets that move beyond being able to "just make a call or establish a connection." The analytics behind UC must evolve and change; yet I see two key areas ignored. The network monitoring tools to move firms from reactive to proactive are key to reducing Mean Time To Repair/Resolve (MTTR). The single most valuable tool that I consider critical is the packet trace. The other tool that must evolve is the ability to establish metrics for the right reasons and on the fly. The analytics to reduce or remove human latency must bind together in the same way what a packet trace can isolate latency in technology. I've stated previously that human latency is from government, technology or man-made. Reducing latency isn't optional for companies vying for a competitive edge, but understanding what processes and workflows hinder workers is key, and reducing those problems doesn’t mean abandoning quality.
While light was made of the "old monolith" PBX (Wire, box and phones), understanding the processes involved meant a desire for constant improvement and a rule of delivering, on time, a system that just works and works. Ripping and replacing every couple of years isn’t cost effective and it certainly doesn’t occur without disruption most of the time.
Now, review what Marty Parker wrote in "Human Latency in UC: What Does the Business Process See?" Examine the processes of your users/customers and please drill down to the granular movements that they must endure daily in their workflows. This means you must think outside of UC and begin to do what numerous US manufacturers learned to abandon long ago in having engineers come up with stuff (products) to just throw against the wall to see if it would stick (sell).
