CEA


Lync, Microsoft’s unified communications platform, combining voice, web conferencing and instant messaging, is reportedly poised to become the next billion dollar business at Microsoft. It’s time you considered alternatives before Lync becomes engrained in your IT environment, much like SharePoint has for many companies.

Lync follows in SharePoint’s billion dollar footsteps
According to reports from Microsoft’s Worldwide Partner Conference (WPC) 2011, the company has high expectations for Lync, with several Microsoft managers telling editorial director of MSPmentor, Joe Panettieri, that Lync’s sales trajectory will make Lync Microsoft’s next billion dollar platform.

With Lync, formerly Office Communications Server, Microsoft is following a similar strategy to Microsoft’s SharePoint, another billion dollar plus business.

With Lync, as with SharePoint before it, Microsoft has built a set of applications that leverages Microsoft Office’s massive install base. Microsoft is now accelerating partner involvement to shift Lync from a set of applications to a platform that partners can manage and customize.

Microsoft expects to target the 10 million legacy voice over IP (VoIP) phone lines that Cisco currently controls, largely in the enterprise space. However, as Panettieri explains, Microsoft has the install base and partner channel to grow Lync in the small and medium business market.

Lync is available on the Office 365 cloud, but is expected to garner higher on premises interest, an attractive point for Microsoft’s managed service provider partners, driven by a more complete feature set on premises.

Consider alternatives before Lync arrives at your door
Lync only furthers your company’s reliance on Microsoft Office – a smart strategy for Microsoft.

As Microsoft partners get more involved with Lync, you’ll be getting briefings on the benefits of Lync in your business. Now would be a good time to start considering alternatives, especially a few in the open source arena, to be ready for Lync conversations with your friendly neighborhood Microsoft partner.

As Lync is growing by selling into the Microsoft Office install base, the first alternative to consider is Google Apps, a direct cloud competitor of Microsoft’s Office 365. While Google doesn’t yet offer a PBX, OnState Communications offers a cloud-based PBX that from the Google Apps Marketplace. It also stands to reason that Google will add some degree of PBX capabilities into Google Apps.

Twilio, a self purported cloud communications vendor, offers a platform to build voice and SMS applications using simple to use APIs. Twilio also offers an open source phone system through its OpenVBX offering. Twilio is targeted at developers while Lync is a ready to use platform for companies. However, systems integrators or managed service providers could take the Twilio APIs and build a repeatable solution that offers much of Lync’s capabilities.

While several open source PBX phone systems are available, the open source Asterisk project is by far the best known. Companies could consider Asterisk as a piece of a Lync alternative. However, Asterisk, as a PBX product, does not itself offer the full platform for voice, web conferencing and instant messaging as yet.

Perhaps the best alternative to Lync, especially for small and medium sized business, is a unified communications offering from the likes of Cisco or Avaya.

Earlier this year Cisco announced the Cisco Unified Communications 300 Series, aimed at companies with up to 24 employees. Cisco also offers the Cisco Unified Communications Manager Business Edition 3000, for companies with up to 300 users.

It would be interesting for a Cisco competitor, such as Avaya, to acquire Twilio and build a customer and developer friendly offering that rivals Cisco’s unified communications platform and Microsoft Lync.

Whatever alternatives to Lync you ultimately decide to consider, ensure that you’ve done this due diligence before Lync arrives at your company’s doorstep. Make no mistake, Lync offers value, but it also further entrenches Microsoft into critical pieces of your IT and communications environment.

I should state: “The postings on this site are my own and don’t necessarily represent IBM’s positions, strategies, or opinions.”

The growing demand for mobile applications is set to challenge the apprehension that enterprise telephony buyers have towards open source telephony offerings. As IT departments strive to meet new mobile application requirements, they will play a role in driving open source and cloud telephony adoption within enterprises.

The IT versus Telephony divide:
IT and telephony departments are often separate departments, if not fiefdoms, within an enterprise. This historical separation has resulted in markedly different views surrounding open source usage. I was told of this reality when we launched the WebSphere Application Server Feature Pack for Communications Enabled Applications (CEA), and have since seen this reality play out.

Open source telephony solutions are not new. However, for enterprise telephony buyers, the risk of any downtime is too great to consider open source alternatives to Cisco, Avaya, Siemens or other well established telephony solutions. One can hardly blame enterprise telephony buyers. We don’t think twice about having to refresh a web browser if a web application crashes. But what if a conference call crashes or a call between a customer and a contact center representative is terminated abruptly?

One may sympathize with enterprise telephony buyers, but their decisions are impacting the seed at which IT departments can respond to end user demands for innovative applications.

Next generation mobile applications demand communications enablement:
As mobile web application usage grows, the first step will be to delivering today’s desktop browser application on a mobile browser. Forward thinking IT departments and enterprises will look instead to deliver a class of applications beyond those available on desktop browsers today. In time, the majority of enterprises will follow suit.

These mobile applications will be communications enabled from the start.

A mobile CRM application that lets a sales executive review a sales lead, and within the application itself, call one of her direct reports, based on presence availability and personalization information, and jointly co-browsing through the sales lead data online while speaking over the phone will become standard practice.

A mobile retailer application that lets buyers co-shop online using desktop or mobile devices, and if required, call the 1-800 number and be routed to the appropriate contact center representative, based on browsing history, without having to traverse automated call menus, will become standard practice.

The challenge for IT is that these and similar applications require IT and telephony groups to work more closely together. More importantly, these applications will require a degree of telephony flexibility that enterprise telephony buyers aren’t likely to be comfortable delivering based on their risk adverse nature.

So what’s an IT department to do?

Open source and cloud telephone to the rescue:
An interesting solution is being offered by open source Twilio Cloud Communications. Twilio recently announced OpenVBX, an open source telephony in the cloud solution. OpenVBX offers virtual telephone numbers, voice transcription, voice collaboration amongst users and a drag and drop approach to building call flows and menus.

OpenVBX is offered as a hosted solution so IT departments don’t have to trouble themselves with keeping a telephony infrastructure up and running.

Most importantly, OpenVBX can route calls to existing phone numbers. This means IT can build innovative new applications that rely on the enterprise’s existing telephony infrastructure without actually having to involve the telephony department in the application development process.

I am not proposing that IT circumvent the telephony department in the long run. However, I’m simply suggesting IT departments consider applying the lessons of grassroots open source adoption. It’s much easier to convince decision makers to use open source when the organization has already been using open source.

Neither am I suggesting that telephony departments should migrate away from their existing enterprise telephony solutions. That would be a fool’s errand. I am however suggesting that telephony departments should evaluate how open source and cloud offerings can augment the existing enterprise telephony environment to deliver end user application innovation.

A mobile communications enabled application generating revenue for the enterprise will go a long way toward convincing telephony departments to augment their telephony infrastructures with open source and cloud offerings.

As an end user, I can hardly wait.

Follow me on Twitter at SavioRodrigues. P.S.: I should state: “The postings on this site are my own and don’t necessarily represent IBM’s positions, strategies, or opinions.”

In my previous post I mentioned that the WAS V7 Feature Pack for CEA Beta can help you create some pretty awesome user experiences for multi-modal online interactions.  Well, what does that really mean?  I’ve already covered the Contact Center scenario.  Now, let’s discuss a Peer to Peer scenario.

Your loyal customers, Savio and Hilary, always use your travel planning website to decide on itineraries and book travel.

Savio is away at IMPACT for a week.  This leaves Hilary alone with their two month old.  Erik, Savio’s wise friend suggests Savio take Hilary on a vacation as a “thanks for putting up with me and rearing our child while I travel”.  Hilary loves to be involved in vacation planning.  But Savio’s in Vegas and Hilary’s in Toronto (See P.S. below).  Savio IM’s Hilary and proposes the vacation idea.  She’s in.   Now the tough part.  Deciding where, which flight, hotel and car.  It’s made tougher by the fact that their multi-modal interaction is not linked in any way.

If Savio and Hilary continue the interaction over IM, they’re forced to send URLs back and forth to keep track of the itinerary item that the other person is looking at.  But then, they’d also have to type “flight #348 will get us in on time” and similar information into the IM application.  But switching over from IM to the phone is no better because they still have to describe which page each person is on, (spelling out a URL over the phone…FUN!?!?), and which flight they are looking at etc.  Savio and Hilary are in for a poor user interaction no matter how you slice it.

We designed the WAS V7 Feature Pack for CEA Beta to address a scenario of two users trying to jointly make a decision through a multi-modal interaction.

Peer to Peer Cobrowsing
Let’s start the same scenario off with a Peer to Peer Cobrowsing Web Widget that is delivered in the WAS V7 Feature Pack for CEA Beta.  Savio would click on the “Invitation Link” button on your website and IM it to Hilary.  Once Hilary clicks the link, Savio and Hilary would be in a shared session together. There’s not software for Savio or Hilary to install to enable this shared session.  In fact, Savio and Hilary have individual sessions with WebSphere Application Server, so there’s an added layer of security.  Calling this feature Peer to WebSphere Application Server to Peer, while perfectly okay with the IBM Naming Police, seemed cumbersome.  Ease of use and security? Check.

With this shared session both Savio & Hilary can take control and direct what is shown on the other person’s browser window.  Both can highlight elements on the page for the other person to see.  Vastly improved user experience? Check.

And of course, if either needs more information before deciding, they could use the Click to Call feature enabled by the WAS V7 Feature Pack for CEA and enter into a joint session with one of your customer service representatives.  I described this scenario before.

Want to learn more?
Get the WAS V7 Feature Pack for CEA Beta here and the Getting Started guide, part of the Library materials, here. Also, here’s a good description of the widgets from Erik. Finally, if you need a copy of WAS V7, you can get a trial here.

Let us know what you think!

P.S.: Hilary and I planned our last trip sitting beside each other, with our individual laptops scouring Expedia for info. It was painful to keep track of the itinerary item that the other person was suggesting. So, while the scenario above describes two geographically separated users, I’m certain it’ll apply to two users sitting beside each other on a couch! What that says for our society is a different story ;-)

Follow me on twitter at: SavioRodrigues

In my previous post I mentioned that the WAS V7 Feature Pack for CEA Beta can help you create some pretty awesome user experiences for multi-modal online interactions.  Well, what does that really mean?  Let’s start with a common scenario.

While searching for a life insurance policy online a user might want to call a customer service representative (CSR) about discounts since her mortgage is held by the bank.  More often than naught, the CSR wants to point the user to more information on the bank’s website.  But here’s the dilemma.  The user and CSR are involved in a multi-modal interaction, but there’s no synchronization between the two modes of communication.  If the CSR wants to direct the user to a specific page on the site, he must tell the user “okay, go to the homepage, on the left navigation bar, click Other Offers and then scroll half way down the page, look for a link that says….” Agreed, that’s an ugly interaction.

When the user decides to purchase life insurance, the interaction is no prettier.  While the user and CSR are speaking on the phone and both have browser windows open, there is no linkage between the two modes of communication.  The user still has to speak certain information which the CSR must transcribe into the application form.  There’s no visual way for the user to verify that the CSR has transcribed the spoken information properly.  Try saying “Savio Rodrigues” and the person on the other end of the phone not transcribe “Fabio Rodriguez” or “Flavio Rodriguez” or “Sabio Rodriguez”.  Not cool.

We designed the WAS V7 Feature Pack for CEA Beta to address a scenario in which a user and CSR are involved in a multi-modal interaction prior to the user making a decision.

Click to Call
Let’s consider the same scenario with a Click to Call Web Widget that you can embed in existing and new web applications.

Unlike third party hosted Click to Call offerings, the Click to Call feature in the WAS V7 Feature Pack for CEA Beta can be completely integrated into your application.  No need to spawn another browser window or advertise your hosted provider’s service.  Integrated and consistent user experience? Check.

Next, our Web Widget is integrated with your telephony infrastructure (so far, Cisco & Nortel).  Why pay a third party Click to Call hosted provider per minute fees for calls when you can leverage your existing telephony infrastructure?  Lower costs and driving higher utilization of existing resources? Check.

Finally, any information that you want to share between the user and the CSR through the Click to Call session, such as login information or account numbers, does not have to go through a third party.  Increased privacy & security? Check.

Contact Center Cobrowsing
Okay, you added a Click to Call widget to your application, now what?  Well, your customer enters her phone number and clicks on “Connect”.  The result is a shared session between the user and the CSR (through WebSphere Application Server).  Oh, and there is no software for the user or CSR to install. Security and ease of use? Check.

With this shared session both the CSR and the user can take control and direct what is shown on the other person’s browser window.  Both can highlight elements on the page for the other person to see.  No more having to say “scroll half way down the page and look for the link to the right of the picture of a monkey”.  Improved user experience? Check.

Two Way Forms
Next up, the dreaded filling out of forms over the phone.  But have no fear. Since you have a shared session between the user and CSR, there’s no reason that the form can’t be displayed to both parties.  But why stop there?  The Two Way Forms feature of the WAS V7 Feature Pack for CEA Beta lets both parties enter data into various elements of the form.  You can even restrict the data shown in a form field between the CSR and user.  For example, the user could type in and see their full credit card or social security number, while the CSR would only see the last 3 digits.  The user can even click to confirm that individual form field data was transcribed correctly by the CSR. Fewer frustrated users? Check.

Want to learn more?
Get the WAS V7 Feature Pack for CEA Beta here and the Getting Started guide, part of the Library materials, here.  Also, here’s a good description of the widgets from Erik.  Finally, if you need a copy of WAS V7, you can get a trial here.

Let us know what you think!

Follow me on twitter at: SavioRodrigues