Cisco Jabber presents some really interesting options and my hope over the next few weeks is to write a series of posts that address some of these options. I think for most part Jabber is largely misunderstood. Along with assumptions on why things are done the way they are there seems to be this constant comparison between Lync and Jabber when really both solutions approach things very differently .Jabber provides a lot of flexibility which can really be attributed to the underlying architecture. While some may argue that the underlying infrastructure is complex each individual solution can actually stand on its own without the other pieces. Something other UC platforms just can’t do.
You will notice that I will make comparisons with Lync throughout this post. Mainly because I think those familiar with Lync will be interested in how Cisco brings their solution together. This isn't meant as a competitive post but more about explaining the solution in terms that someone more familiar with Lync rather than Jabber will understand. If I just started presenting this using a bunch of Cisco product names, someone who isn't familiar with those product names will quickly become lost.
What is Cisco Jabber?
Similar to Microsoft's Lync brand, Jabber is the brand used to encompass Cisco’s Unified Communications clients and SDK’s. This includes desktop (Windows & MAC), mobile (Blackberry, iOS and Android etc.), SDK and web clients (Jabber Guest). It really isn't any more complicated than that.
Common Framework
I have worked in the IT industry for over 15 years and seen many a deployment of UC among other things. One thing that has remained true is that its hard to bring different teams together in unison on a single project. If I look at how UC has grown up it would be impossible to finger a point in time or a single product that really created the idea of UC (although I am sure someone will claim it). Also, the fact remains that UC means different things to different people. My point here is in general there is still so much market confusion around UC companies in general see UC as an overlay to an underlying infrastructure. I have sat in countless meetings where drawing the bigger picture either isn’t fathomable or just not wanted or “yeah we will get to it”. Most of the time disparate teams are so focused on their own mission statements of deployment and operational support, to be distracted from that is a big ask.
So how do we bring together disparate technologies and teams that have really grown up over time in their own silo’s? The answer is by having a client that has a common framework that rather than force a change in the infrastructure brings together different services.Notice how I mentioned services. This is because each of these once independent workloads can now be consumed in a variety of ways. On-prem, in the cloud or hybrid. I see each independent workload more as a service and depending on your model, you may choose to consume them in different ways.This really speaks to the cloud trend of course but I see it relative to no matter where this service is coming from. This is a very different approach than Microsoft’s Lync. Rather than take a services approach and combine them into a single client, Lync consumes all major services from a single registration point. Which is fine and has its own set of benefits but at the same time limits deployment models.
By using the common framework we can also reduce a serious issue presented by UC, disruption. Disruption to teams that have a focus on current roles, disruption to services that in all likely hood are already deployed, disruption for users as they are now not faced with having to change an interface or services (voice, video, web). By deploying a UC client that consumes rather than replaces services it has the ability to reduce the disruption across the board. In this post I have focused on the main UC services voice, video, web conferencing but really API consumption can be part of this as well. Think MS Office, Google Apps etc. this really broadens the conversation but for now I want to focus on the main UC services.
Client Services Framework – Cloud or On-Premise
To achieve a services model with a common framework Jabber uses the Client Services Framework.Client Services Framework is a base building block for the client application. Cisco Unified Client Services Framework is a software application that combines a number of services into an integrated client. An underlying framework also provides the benefit of being cross platform portable. So while this may seem complex its actually simplifying the ability for developers to build the client application by being able to build upon CSF.
What this means for companies with large investments in Cisco’s UC infrastructure is a way to bring this together without needing to disrupt current services. You are actually layering CSF across your current infrastructure. This may mean you do not need to deploy any new on-premise infrastructure depending on what you deploy and how you deploy it. Below highlights an all on-premise deployment with everything in place.
So lets suppose for a moment that you wanted to layer on IM&P to an existing Voice deployment but without softphones. You could conceivably follow a deployment per below. Adding softphones from a technical point of view is now just a matter of configuring it.
But lets take this a step further. Lets add in the cloud. Below is a hybrid deployment model with some services on-premise and some in the cloud.
As a first step perhaps I just want IM&P from the cloud.
Next step I may want to layer on voice but this is being consumed from on-prem. Jabber with CSF gives this flexibility to take different services from either on-premise or in the cloud. This could also mean working with a HSC partner delivering voice services so voice could be in the cloud as well.
Some of you may be questioning why I didn’t leave in voicemail while optioning in voice services. Well this is because although visual voicemail in Jabber is a nice to have not every company has Unity Connections as their voicemail platform with Cisco Unified Communications Manager. This shouldn’t be seen as a limiting factor to adding voice for a Jabber or for that matter Communications Manager voice deployment. Fact is Communications Manager is controlling the flow of voicemail and if for instance you have Exchange UM deployed people may be happy just getting voicemail in their email. This really speaks to the flexibility of Communications Manager as a voice platform and having CSF layered over your infrastructure.
Jabber and WebEx
Some of you may be questioning why is WebEx Meeting Center is the diagrams and why Jabber just doesn’t do it all. In my view as a consumable service Web Conferencing can be sometimes be used with a UC client but inevitably I find most companies have more than one Web conferencing service. The reasons vary quite a bit. For some its because an in-house offering doesn’t scale to large meetings or there is an application that is commonly shared that doesn’t work well in one web conferencing solution versus another.What ever the reason the fact remains that a all in one UC client doesn’t always meet the requirements. Over time this may change but the fact Jabber uses WebEx rather than attempt to do it all speaks to the radically different requirements that web conferencing brings.
So although the WebEx messenger service (IM &P) can be directly consumed by Jabber, Jabber does integrate with WebEx Meeting Center rather than consume it directly (aside from P2P desktop sharing). Yes, that means a second application but it also means a consistent end user experience covering far more use cases than a single UC client could possibly do today. In the future this could mean further integration (I am not speaking to any roadmap here, just want to be clear) but this shouldn’t come at the sacrifice of removal of features or use cases just for the sake of a single client experience. From my own personal experience I have seen companies that transitioned from Live Meeting to Lync where this was the case and it caused delays in the migration or a transition to a different service altogether because of a loss of features. This isn't to say they all went to WebEx lets just say “other service” because to be frank some went to WebEx and other went to Citrix, Adobe etc.
Based on my own industry experience I think this is a smart approach. Although in the eyes of Jabber competitors this may be conveyed as a negative, the use cases surrounding Web conferencing are becoming just as complex as voice and other services. Although having a single client user interface is seen by some as the gold standard, in reality getting there and still meeting expectations is a complex task.
What about hybrid Microsoft Cisco model?
This is a really common question. Yes, you can certainly do a hybrid Lync/Cisco UC model. Is it going to get you where you want to end up? Probably not. I say this based on my experience across the last 10+ years. There will always be something you wished worked better together. Although Cisco and Microsoft have made solid efforts to provide interoperability it will most likely never be complete (of course this will depend on which side of the fence your talking to). I think both vendors based on use cases and requirements are at a stage where a company can deploy just one solution to get the greatest benefit. I am sure there are lots of folks out there that agree.
I started my blog based on interoperability. Although I will address it from time to time moving forward, I think the reasons for the hybrid Cisco/Microsoft solution are gone or so significantly reduced that its holds little value in the decision making process. So I will be writing less about it and focusing mainly on Cisco technologies.
Beyond the Marketing Materials
I tried to give a description of Jabber and how it compares in some regards to Lync without trying to be one sided or the other. Examples based on my experience are real world from working as an engineer and also from my time at Microsoft and Cisco. I happen to think Microsoft has helped changed the industry with Lync in many ways but I also want to recognize its limitations with the approach its taken versus Cisco.If I offended any one, tuff its my blog and I write what I want. Feel free to comment in a respectful manner and provide some real insight, don’t just comment to stir because I will delete.
References
Jabber Product Page Home
http://www.cisco.com/web/products/voice/jabber.html
Cisco Collaboration SRND 9.0
http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/9x/collabor.html#wp1105337
Jabber for Everyone
VoIPNorm
