Multi-Organizational UC

As a rule, UC systems are best shared with others. Typically, UC systems support multiple users within a single organization. UC solutions may provide a personal experience, but are inherently shared infrastructure. Taking it to the next level is sharing the system among multiple organizations. This concept is rapidly becoming more prevalent with the boom of service providers that offer services to multiple organizations.

From an evolutionary perspective, the PBX wasn't commonly shared. Typically, a single organization purchased their own system and connected to it to desired services such as operator consoles, call recording and call accounting systems, music-on-hold sources, etc. Because the programming of these systems were very detailed, there were various approaches to creating virtual splices with trunk groups or service classes, but such attempts were both complex and restrictive.

There are two modern approaches to sharing systems across organizations: multi-tenant and multi-instance. These two approaches should not be confused.

Multi-tenant may or may not include server virtualization. It means the system itself is inherently designed to accommodate multiple organizations, and effectively means the core system can be sliced into virtually separate systems. Each tenant can have the same or different dial plans, each IVR is totally unique even with the same options. Multi-tenant systems were initially designed for landlords that wanted a single solution for an entire facility.

Multi-instance systems are directly related to server virtualization. In this case, the system software can be run multiple times on separate virtual instances. Each tenant effectively receives their own dedicated instance. There is no risk of accidental cross communication or conflicts as each virtual server only knows about the others as separate systems - perhaps connected via TIE lines.

A multi-tenant system can be run in multiple instances - we will call that a multi-multi tenant instance system - that's for the advanced class.

Multi-instance implementations are more common because most UC solutions were designed for single tenant implementations. A traditional premises-based solution that can be virtualized with minor modifications can be made suitable for service provider implementations. The primary benefit of this model is that single tenant systems are inherently simpler to manage and there's more choice. The downside is they require larger implementations to justify dedicated virtual overhead. Also, during upgrades, each system needs to be upgraded separately which can create a significant amount of work.

These issues don't just apply to core platforms, but to applications as well. For example, multi-tenant advanced call center features or analytics engines could be less expensive to SMB users when shared among multiple organizations. Providers that promote "big company features" to small businesses probably utilize multi-tenant systems.

Multi-tenant systems offer more scalability. Both approaches can scale to large implementations, but multi tenant systems accommodate small business users as well. Another advantage of multi-instance systems is that a single upgrade will upgrade all hosted tenants. However, it can also be problematic if some customers don't want to upgrade. Also, multi-tenant systems require more consideration regarding disaster recovery as a single failure could take down several organizations.

If it is done right, these distinctions should be invisible to end users. It's a far bigger issue for the provider. This is quite simply why some providers target larger accounts only, and why some are quite comfortable with small customer implementations. End users should be aware of the technology in use.