Does Architecture Matter?

31 Jul 2016

We have a client who recently received several proposals for a UCaaS solution. We had specified the functionality the new solution must provide, but not the architecture. When we met with them initially to review the proposals, we asked them about their preference for a particular architecture model. To our surprise, the client said, "No. Does it matter?"

Yes, it matters.

The proposed solutions varied. A couple of proposals were for solutions originally developed as premise systems that were virtualized and hosted in the provider's data center(s). Others were for Broadsoft software from Broadworks (originally developed as a cloud solution) offered by various partners who host the services in their own data centers. Still other proposals were for solutions originally developed as cloud solutions and hosted by the company that created (and continues to develop) the software.

Each type of architecture has strengths and weaknesses; understanding the differences is key to choosing the best solution for your individual situation.

The systems that were originally developed as premise systems fall into two types:

Those that are essentially hosted versions of the on-premises products, and
Those that have been re-architected for the cloud environment (these are covered in the third type of proposal discussed below).

Pros

· Long history in telephony

· Feature depth

Cons

· Limitations in scalability

· Partner must wait for creator to update; not under their control

· Updates typically in the form of a new software release with a lot of new capabilities all at once; may require user training to get full utilization of new capabilities

· Typically a monolithic architecture under the covers

· Failure in one area of system can have impact on other areas

The second type of proposal our client received was for Broadsoft solutions from various partners, each of whom host the software from their own data centers. The capabilities provided by these partners varied considerably. This is due to the ability of partners to develop additional capabilities that enhance and expand the basic capabilities provided by Broadsoft. We saw differences in the tier levels of the data centers which were hosting the services, differences in failover and resilience capabilities, and differences in the levels of carrier redundancy offered by the partners. In addition, some partners had created applications that enhanced the basic Broadsoft capabilities, while other partners offered only the native Broadsoft features.

Pros

· Developed as cloud solution; scalable

· Been around a while; tried and true

· Partner can add their own "secret sauce" without having to worry about developing basic telephony features

Cons

· Partner must wait for Broadsoft to update base software; not under their control

· Native feature depth is somewhat limited when compared to older systems

Notes

When evaluating a Broadsoft offer, it is important to evaluate the capabilities of the partner in addition to the Broadsoft features.

The third type of proposals were for solutions developed for the cloud and hosted by the company that created (and continues to develop) the software. Again, there were differences in feature capabilities, data center capabilities, and architecture. The chart below generalizes some of the characteristics of these proposals. If you are evaluating options, be sure to ask your potential provider how they compare to the capabilities described below.

Pros

· Developed as cloud solution; scalable

· Continued development and updates

· Agility and rapid innovation as changes are made incrementally-no more software releases (no waiting, no training, no cost, no work to get the new capabilities)

· Some offer unique pricing models (all inclusive options)

· Scalability through distributed computing (every instance is able to handle all system functions, no centralized resources)

· Some offer load balancing between data centers

· Resiliency through multiple data centers

· Some offer edge devices that allow stand alone operation in the event of a connectivity failure

· Many are architected using microservices which support individual services; a failure in one area will not impact the entire system (improved reliability)

· Microservices can scale dynamically as needed to provide resources to areas that need them

Cons

· Newer solution; not as tried and true

· Native feature depth is typically somewhat limited when compared to older systems

· Often edge devices (if offered) are not monitored and parts are not stocked; replacement can take a couple of days or more

· Full resiliency requires secondary network connection (increasing monthly costs)

· Licensing can be a bit tricky in some cases

· May be smaller companies; may lack long term financial stability or be subject to acquisition

Clearly, there is a lot to think about. Here is a final thought: It is unlikely that any single solution will meet every need of an organization. Solutions that provide APIs that allow others to develop "Apps" to enhance the basic platform, and those that provide interoperability with other "clouds," offer organizations the most long term flexibility. In a world of constant change, flexibility is important.