Tip

Evaluating business collaboration architecture types and vendors

Part two of our four-part guide on facilitating business collaboration provides IT leaders with insight into developing effective collaboration architecture. This section describes

    Requires Free Membership to View

various types of collaboration technologies, how they intersect and how to best evaluate competing and complementary vendor products and services.

Table of Contents

Part 1 – Assessing business collaboration benefits

Part 2 - Business collaboration architecture types and vendors

Part 3 - Questions to ask your collaboration vendors

Part 4 - Collaboration services: Decisions and final factors

Technical overview of collaboration architectures

It is important to think of collaboration not as a single product but rather as an architecture that integrates various forms of real-time and non-real-time applications within and outside of company boundaries.

Collaboration architecture standards

Many existing standards facilitate the integration of collaboration products, including:

  • Session Initiation Protocol (SIP): A standard defining how two or more endpoints establish and tear down communications sessions (like voice or video);
  • SIP Instant Messaging and Presence Leveraging Extensions (SIMPLE): An extension to SIP to support instant messaging and presence;
  • eXtensible Messaging and Presence Protocol (XMPP): An XML-based messaging protocol widely used for instant messaging, presence sharing and machine-to-machine communications;
  • International Telecommunications Union (ITU) H.323: An older signaling protocol for establishing and managing voice and video sessions that is still widely used, even though most vendors are phasing it out in favor of SIP.

These standards only define system-to-system connectivity. For example, voice systems may use SIP to establish calls between PBXes or to the public switched telephone network (PSTN). A voice system may use XMPP or SIMPLE to share presence information with an IM platform (e.g., to tell the IM platform to change a buddy's icon from green to red if they are on the phone).

In addition to signaling and message transfer standards, each collaboration application may use its own set of standards for various features. Examples include:

  • Video encapsulation protocols like H.264 Advanced Video Coding (AVC) and H.264 Scalable Video Coding (SVC), which define how video is captured, converted into digital format, transmitted and converted back to video;
  • Voice encapsulation protocols such as the International Telecom Union's G.711, G.722 and G.729, which define how voice is captured, compressed and converted to and from digital formats; and
  • OpenSocial, which provides the ability for applications to work across multiple social computing platforms.

But despite these open standards, many vendors still rely on proprietary protocols or extensions to standardized protocols for their collaboration products. In some cases vendors will support open standards but with more limited functionality compared to their own protocols. In recent years, vendors have formed a number of standards bodies to address these interoperability issues, including the SIP Forum, the Unified Communications Interoperability Forum (UCIF) and the Open Video Communications Consortium (OVCC) -- but vendor support for these organizations varies.

Finally, many vendors deliver application programming interfaces (APIs) for third-party application developers to integrate their collaboration features into other applications. For example, application developers may leverage APIs to extend presence and click-to-call functionality from an enterprise unified-communications platform to other business applications, like HR, ERP or CRM.

Create a successful collaboration architecture

Building a successful business collaboration architecture requires selecting a set of applications and being mindful of their ability to interoperate not only with each other but also with legacy-installed platforms and established business process applications.

Thinking about collaboration as an architecture rather than as a product allows IT architects to:

  • pick appropriate applications;
  • find appropriate integration points;
  • select proper protocols;  and
  • understand any limitations proprietary standards impose.

A visual representation of an integrated collaboration architecture is as follows:

Figure 1: Integrated Collaboration Architecture
 

Source: Nemertes Research 2012

 

This architectural model defines the following components:

Collaboration applications: Employees can use these services to communicate and collaborate, both internally and externally. Most organizations start with VoIP and email, building in additional applications like video, unified messaging, social networking and Web conferencing as they evolve their collaboration deployments.

Presence: This is the "glue" of unified communications that enables applications to share information about user status, availability and collaboration capabilities.

Common protocols: Unified protocols are the standards for linking various services to each other and to external applications via gateways or application interfaces.

User interfaces: These provide access into various UC services. Interfaces can be standalone desktop or mobile clients, or they can provide collaboration services access via a portal, office application or through custom-written applications designed for a specific organization, vertical or job function.

Gateways: Gateway components are external systems, such as legacy PBXes, external wireless networks, or business applications via APIs, Web services or service-oriented architecture (SOA) frameworks.

Management, directory and security services: The core infrastructure supports UC and includes security, network and performance management/optimization, and directory and identity services.

Perhaps a bigger challenge than interoperability for IT leaders is the growing number of potential endpoints. Collaboration interfaces are rapidly growing beyond the traditional PC desktop into the following:

  • mobile devices, which include smartphones, tablets and role-specific devices like two-way communicators, radios and hardened devices; and
  • virtual desktop infrastructure (VDI), which includes thin-client software running on a PC and zero clients with no local processing.

Trying to support these growing endpoint options presents a moving target. More than half of all companies now allow employees to bring your own device (BYOD). Mobile device vendors are racing to deliver new devices with new features, including video conferencing, high-resolution screens, location awareness, near-field communications and the ability to access ever-increasing wireless data speeds.

At the same time, most wireless service providers are imposing data caps with additional fees for users who exceed their monthly caps, and that can lead to potentially higher costs for companies wishing to leverage bandwidth-intensive applications like video for their mobile users.

A prerequisite to a successful BYOD plan is the deployment of a mobile device management (MDM) platform to enable centralized policy administration and application management for a variety of potential endpoints. More than 30 vendors and managed service providers (MSPs) offer MDM platforms. Evaluate which one works best for you, or check with your security and mobility teams to see if they have already deployed a solution. If so, coordinate your collaboration strategy to minimize potential conflicts.

Virtualization integration is another challenge for collaboration architects. By centralizing application processing in the data center, VDI can reduce endpoint cost and complexity. But real-time applications like voice and video aren't well suited to centralized processing. They can cause excessive delay because of the amount of bandwidth required to transmit raw voice and video back to the data center for encapsulation.

The deployment of real-time communications using VDI is currently low (only 2.9% of organizations use it in combination now). A third of organizations are testing tools and evaluating their options. A lack of coordination between those responsible for collaboration and those responsible for desktop virtualization can lead to implementation failures, excessive costs and unhappy users.

Continue reading this series for questions to ask collaboration vendors.

This was first published in July 2012

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.