Skip to content

Intra-Domain Co-Existence Federation

November 30, 2011

This is the first part of a three part series of blogs looking at scenarios for short-term and long-term intra-domain federation as well as inter-domain federation.

By the time a company becomes a medium to large sized enterprise, part of its growth will have been as a result of one or more mergers or acquisitions.  While this is quicker than organic growth, M&A events create new challenges, not least of which is the inheritance of disparate IT systems that are not a close match with the systems of the other entities.  With PBX systems, the QSig standard allows these systems to interoperate without any problem.  However, the advent of the unified communications (UC) era has created a new layer of complexity to this situation.

The decision to deploy UC provides an IT department the opportunity to review its communications vendor strategy and to consolidate communications infrastructure on a single vendor platform.  However, with recent acquisitions or prior vendor affiliations, it is likely that there will already be a mix of UC infrastructures, provided by PBX vendors, application vendors as well as network layer vendors.  Before you know it, you have to contend with a mix of systems such as Jabber/XMPP, IBM Sametime, Microsoft OCS/Lync, Cisco UCM and Google Apps.  And none of them interoperate…

Having different parts of the company working on separate UC systems completely undermines the value proposition of UC.  One response to a fragmented infrastructure would be to implement a migration strategy to consolidate onto one platform (migration strategies will be the subject of a future blog).  However, in this scenario, there are good reasons for maintaining a mix of UC technologies: the challenge is to make them co-exist.

There are gateways that will address the co-existence of two systems: for example OCS-Sametime gateways from either Microsoft or IBM.  However, these systems often require the two interoperating systems to be on separate domains, which can be problematic.  Additionally, the interface can be broken when ‘the other’ vendor ships a new version: this will require patches/hotfixes that will lag the vendor upgrade.  Furthermore, when there exists more than 2 systems, the co-existence challenge increases exponentially for every additional system.

Session Border Controller vendors will also claim to provide a solution for “any-to-any” UC system interoperability.  However, unlike the purpose built gateways, these ‘babel fish’ elements implement intermediation via configuration and/or scripts, often placing the onus on the IT department or external consultants for correct configuration or script definition.  Once again, additional costs can be incurred when one or more vendors upgrade their interface.

By far the most optimal and least risky co-existence mechanism would be a service ‘in the cloud’ that would take the onus of responsibility for the intermediation between disparate UC systems, thereby ensuring that two or more mission critical communications infrastructures work seamlessly.  Such a service might look a lot like NextPlane.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s