No Jitter is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

7 Factors to Consider on Enterprise Messaging Apps

Workstream messaging, also known as team collaboration and a variety of other terms, is the new panacea for enterprise communications. These new applications center on a familiar messaging interface, but extend into shared content and real-time communications.

For the past two years I’ve been predicting a collision between these workstream messaging applications and UC. That appears to have been optimistic, instead, the UC vendors are launching their own workstream messaging solutions, and the new applications may instead subsume UC. UC vendors with new workstream solutions include Alcatel-Lucent Enterprise, Avaya, BroadSoft, Cisco, Fuze, Microsoft, Mitel, RingCentral, ShoreTel, and Unify.

To the casual observer, all of these applications look alike. They do indeed share many common characteristics. Almost all of them feature persistent messaging between individuals and among teams. This content forms a searchable and shared conversation history.

Most of these solutions support interactions with external users. This marks a significant difference between workstream messaging and the instant messaging found in UC suites. Although external/guest users typically do not have as many capabilities as licensed users, they can participate at will.

Big differences among workstream messaging applications reflect the immaturity of the category. Some of these differences may be short lived as the products are evolving quickly. However, some differences are attributable to the varying architectural approaches and philosophies among vendors and will persist.

Telephony Support
The unified part of the UC vision was to tie together all forms of communications into a single application. Most of the UC vendors missed email and SMS -- and then enterprise social needs emerged. Workstream messaging also has a unified communications vision, but without the term. These solutions often replace SMS, reduce email, and offer more inclusive conversations.

Most workstream messaging solutions support real-time communications, with point-to-point voice and/or video calling. But that isn’t the same as telephony, which includes inbound/outbound PSTN services and telephones.

Some workstream messaging solution providers suggest that placing a call on a separate system is no big deal. But that works against a consolidated conversation history. A key benefit to workstream messaging solutions is how much users can accomplish within a single application. A response to some information may trigger a conversation, which may transition among messaging, voice, and video.

This is where many of the UC companies that offer workstream messaging solutions have an advantage. Developing a rich and robust messaging solution is difficult, but it is a cakewalk compared to that challenge non-UC vendors face in building a feature-rich, reliable voice platform.

Prospective customers need to reconcile their long-term plans for voice and their desire for a comprehensive communications tool. UC vendors/providers such as a RingCentral, Mitel, and Unify offer integrated UC. Unify also supports a SIP connector that integrates with most UC platforms.

Conversation Format
Workstream messaging evolved from basic group chat solutions such as Internet Relay Chat (IRC). These solutions present conversations chronologically, as do IM and SMS . New messages (or other content) are added to the stack as they arrive.

This works well with smaller, interactive groups. But as teams grow, the conversational strings get longer and more difficult to follow. Side conversations start popping up, and the overall conversation gets "noisy" and hard to follow. The solution is threaded conversations, but this means different things to different people.

Slack users were requesting threaded conversations so regularly that the company promised last April that it would add the feature. Evidently, this required quite a complex architectural change -- Slack only just released threaded messaging a couple of weeks ago.

Slack’s implementation of threaded conversations is surprising because its threaded messages are specifically created and placed outside the main conversation. Slack’s threading separates side conversations to reduce noise, but these messages are private and can't be searched.

Microsoft Teams, still in preview, touts threaded conversations as a key feature. In Teams each message supports a single layer comment thread. These comments are visible, searchable, and potentially noisy. The current version does not offer any tools to reduce or manage noise. Teams is expected to become generally available this quarter.

We know from email, Twitter, and Google Wave that the topic of threaded messages is personal and controversial. Twitter was subject to user vitriol when it introduced its “blue line” conversation view in 2013. In email, threaded conversations have been a core philosophical difference between Outlook and Gmail. Outlook can now thread, and Gmail can now turn off threading, but their implementations are still dissimilar.

Key to the "workstream" part is integration with other applications. The workstream is a dashboard and portal into other workflow-related applications, bringing together people (teams, directories, permissions), content (documents, portal to other apps), and communications (asynchronous and real time) into a single environment.

Vendor-provided integrations make connecting to applications easy, and most vendors support integrations to popular CRM, email, and service ticket systems. However, integrations will never be enough. Prospects are advised to carefully evaluate API and vendor ecosystems. Ideally, a significant portion of the workstream solution should be accessible via API. This was likely the motivation behind Cisco’s acquisition of Tropo.

Continue to next page for additional considerations

Continued from previous page

There are two common approaches to presence. The more popular approach uses green, yellow, and red icons to indicate if a user is online and available. This approach is familiar thanks to pioneering Internet applications such as AIM and is used within most UC suites today. Most of these solutions use keyboard activity to signal availability.

The concept of presence changes in a mobile-centric world in which the correlation between keyboard activity and availability is weaker. The other popular approach is read receipts. The idea is that what matters most is knowing if or when a user viewed a message. Read receipts effectively reveals presence, but not until after the message is viewed.

The problem with color-based presence is that just because someone's icon is "green" doesn't mean that person actually saw the message. The problem with read receipts is people may avoid looking at a message to avoid committing receipt and starting a perceived response clock (Fleep has the ability to unmark a message back to unread). Also, it is possible to bypass acknowledging the receipt of a message by viewing the preview in a notification.

Some solutions are actually embracing both approaches. Applications such as Facebook and Google Hangouts now show both online status and viewed status.

Better communications can improve productivity, but why stop there? Several workstream messaging solutions offer productivity-boosting bots. The more advanced solutions utilize AI to learn appropriate responses and to associate people or events with tasks and actions. Bots don't necessarily have to be summoned; some will automatically perform their functions by passively monitoring conversations. Google and Microsoft both have access to detailed social graph data to better understand context and relationships.

Many system interfaces lend themselves well to a text-based, conversational UI. Ordering a taco through Taco Bell's Tacobot may seem trivial, but it demonstrates the power of messaging. Interpretation of verbal interfaces is far more complex than text. Messaging bots can act on human and/or machine-generated text, and implement actions across integrated systems. Messaging is positioned to become an entry point for enterprise-wide processes and queries.

Factors to consider regarding bots are their underlying technology, including AI engines and APIs. We aren't likely to see any breakthrough bot applications immediately; however, they can improve productivity.

The value in persistent communications lies in the ability to retrieve information later. But, search is not equal among these applications and deserves careful evaluation. These applications are built on advanced database structures that can deter or enhance search. For example, searching for something you know exists is a different exercise than discovery. Search should include people and content. Key considerations include:

Search capabilities and encryption are interrelated.

These apps are intended to encompass most enterprise conversations and content, so encryption is critical. Encryption involves transmission of the content and storage of the content. Network encryption will likely use standard encryption methods across most of the solutions. There are, however, significant differences in approach to stored encryption.

It would be nice if the data was just encrypted, end of story, but that complicates content search and discovery. Many enterprises are uneasy about having the majority of their internal conversations indexed and off-site (if delivered as a service). The concern goes beyond compliance issues. It's also about trusting all of the vendor's administrators, contractors, and security practices.

If the provider's security practices are not sufficient, then common alternatives are onsite servers and customer-controlled key management. While most team messaging solutions are available as a service, Atlassian HipChat and others are available for deployment on corporate servers.

A premises-based model enables the enterprise to physically retain control over its data, though that doesn't necessarily equate to increased security. Premises-based solutions also transfer the responsibility of upgrades, back-ups, disaster recovery, and remote access to the customer. Additionally, premises-based implementations may lack optional capabilities such as AI and deep analytics that are typically only available from service providers.

Another approach is customer-controlled encryption keys. Cisco uses this model with Spark. The customer can have full control over its encryption keys. Even though Cisco stores the data in its cloud, it has no access to it, even under subpoena. This approach offers a zero-trust security model with cloud-delivered benefits. The downside is complexity, and limited server-side search capabilities.

Final Thoughts
Other key differences include support for multiple teams, centralized administration, and data export, to name a few. The space is very fluid, with significant changes occurring regularly. Most of these solutions have embraced Agile development methodologies. Unify, for example, did 26 development sprints last year and has a long list of 2016 improvements implemented in Circuit to show for it.

These are some of the many differences across this emerging category of workstream messaging applications. Join me at Enterprise Connect 2017, March 27 to 30, in Orlando, Fla., where I will be covering this topic in more detail in the session, "The Essentials of Team Collaboration Apps" as part of the new Next-Gen Messaging & Team Collaboration track. And, if you haven't already registered, do so now using the code NOJITTER and receive $300 off an Entire Event pass or a free Expo Plus pass.

Editor's note: The original version of this post incorrectly stated Mitel's MiTeam was available for premises-based deployments.

Dave Michels is a contributing editor and analyst at TalkingPointz.

Follow Dave Michels on Twitter and Google+!
Dave Michels on Google+