Blog and Research
Offering a synopsis within key enterprise challenges and some of my ongoing, future and past research topics.
A successful architecture of an enterprise network within a Multi Cloud strategy
Applications adopted by organizations reached a vendor agnostic model at the advent of the decade and hence was birthed the spinal issue faced by many organizations today- A multi vendor application niche, with no single cloud and hosted provider able to host all workloads with the sense of ease that the cloud was promised to present. Whilst simple to blame the lack of long term vision, the pace at which technology has developed was unforeseen anytime in the past, and unparalleled to keep up with.
Most reliable and reputed cloud service providers today, have restrictions that prevent organizations to migrate all workloads to the cloud leveraging the services of a single provider. In addition, if one were to be present, arguments could be made along the lines of risk management within IT - Hosting all application with a single provider. Hence, - The Multi Cloud (Not to be confused with Hybrid Cloud).
Whether this was a consciously and logically arrived at methodology or a way, to term, to justify, the only way out, is a somewhat pointless discussion and one that is second in line as soon as we know if the 'Egg or the Chicken came first'.
Without any further ado; diving into why you are reading this write up, a mere opinion - What would the state of the Network servicing a Multi Cloud environment - look like? The answer - Decentralized, Software Defined and topologically, Multi Hub and Spoke.
Enterprise Telephony, UC- An overpopulated spectrum, demanding over-simplification
'Time to ditch the PBX' - An ubiquitous tag line used by many UC Product companies marketing their cloud based voice solutions to cash in on the race to the cloud (riches). Further, Managed services Providers are - in what has never been a new thing - white labelling solutions and posturing themselves as cloud UC providers. The market place, which is akin to sand on the beach, is crowded enough to force Enterprise(s) today in making potentially detrimental decisions due to the increased adoption requirements enforced by executives and stakeholders alike.
To call it as I see it - Enterprise telephony is not a simple to understand discipline and there isn't a technology partner who is able to offer an easy migration of all dependent workflows to the cloud. Enterprise telephony, in many cases (and in an ideal scenario) is a convoluted architecture composed of (for MID-CAP and Larger) - Contact Centers, Operator Consoles, API integration with other CRM and business critical software, conventional telephony, Conferencing solutions, auto attendants, IVR's, Mobility, IM and presence - at a minimum.
The easiest workloads to migrate to the cloud being IM, conventional telephony, AA's and IVR's.
While complexities will continue to exist in tying up other 3rd party software integrating with the telephony core, substantial efforts are required to be put in by providers of the services to allow for conjunctional hosting within proximity of the core for a successful and acceptable solution . Due to the nature of telephony and UC being a sensitive application, and one that is prone to generating more frustration amongst the consumer base and those whom they are serving, it is vital for enterprise(s) today to either:
A) Focus on Architectural efforts to change the outlook of their telephony system and simplify it, so as to ensure a minimalistic design, OR
B) Migrate without changing the underlying architecture, with an increased focus on migrating feasible workloads to the cloud while exploring hosted solutions for those that cannot.
In either case, the challenge is less the technology, more the procedural factors involved, and acceptance of a cyclical review methodology that will require 5+ flush cycles to ensure a golden state. But in adopting B), arguments can be made on whether the impact of cloud has really changed much as opposed to simply creating a few Co-Lo's to do the same thing.