Unless you have been hiding beneath a rock for the past few months, you will have noticed that the Collaboration market is trending towards the cloud and that means less on-premise equipment for Collaboration Engineers to install, configure and maintain. Central to Cisco’s collaboration cloud strategy is Cisco Spark. This is an app that allows secure business messaging / file sharing, meetings through Spark rooms and video/audio calls.
In July 2016 at Cisco Live in Las Vegas, Cisco SVPs Rowan Trollope and Jens Meggers, and Cisco VP Jonathan Rosenberg gave a sneak peek into what the future holds for Cisco Spark. The demonstration at the keynote showed the audience that a new telepresence unit can be taken out of the box and connected to the cloud in a matter of minutes with very little technical configuration. There is no need for anything on-prem- you just need an account in the cloud and the Serial Number of your client you are good to go. Furthermore, in Fall 2016 Spark will be integrated into iOS 10 which will allow enterprise voice/video calls to be made from an iPhone or iPad. Lots of cool new things in the pipeline! Keep a close eye on Rowan’s blog.
For customers that have an existing legacy on-premise collaboration solution, Spark can be integrated using Spark Hybrid Services which utilizes Cisco Expressway
Job Market for Collab/Voice Engineers
So now that I have covered everything important that has happened in the last 2 years- the question is what does this mean for CCIE Collaboration and the job role of Collaboration Engineers?
The simple answer is: you have to embrace change. I remember being at Nortel in 1997 and the Telco guys thought they could configure DMS switches till retirement and VOIP would never take off. It feels like history is repeating itself with the shift to cloud-based solutions. For greenfield implementations going to the cloud is a no-brainer and I doubt there will be much work involved for your traditional collab/voice engineer. There are always going to be exceptions to the rule – government, large enterprise and niche customers that are slower to embrace newer technology for whatever reason are always going to be exist but make no mistake about it- contraction will happen!
When we talk brownfield, there will be a gradual shift away from on-prem. Lots of companies will want to amortize their investment and will “wait and see” before revising their collaboration strategy. During this transient gap there will be a strong market for Collab engineers being able to design and configure hybrid solutions. Of course the skills for Communications Manager and other on-prem voice solutions won’t go away overnight but the market will inevitably shrink.
And we haven’t even started to talk integration to other clients such as Skype for business and WebRTC clients which will become more and more prominent (see Cisco Acano a bit later on). That is a conversation for another time- for now we will pretend the entire world only knows one vendor and that is Cisco.
Best guess-timate for CCIE Collaboration v2
From the past couple of Cisco Live conferences it is clear that the Cisco DevNet program is gaining momentum. This is no coincidence! In the new world Collab engineers are going to see an increase in demand to help enterprises integrate collaboration tools into their existing infrastructure. The demand for engineers capable of using Tropo/REST/Java/Python/etc will increase and if you are reading this article you might want to start thinking about re-tooling in the coding direction.
I would expect the next version of the CCIE Collaboration to reflect the job role trends that are beginning to happen. Below is a list of likely technology that can be added to the blueprint- bear in mind that this is based on common-sense and no information has been disclosed from any authorized source (they tend to keep these things hidden from everybody).
- Cisco IOS gateways? CME, ISDN PRI, MGCP, H323. Maybe the end is nigh!
- SIP Trunking? will for sure be central to any network diagram for the foreseeable future.
- Mobile Remote Access (VPN-less jabber)? very likely to be introduced in v2 and has been keeping many collab engineers busy over the past couple of years.
- Cisco Meeting Server? Cisco acquired Acano in Jan 2016 for on-prem conferencing and interoperability to Skype for business and webRTC clients. The Acano Bridge has been renamed to “Cisco Meeting Server”. Likely to be added.
- Updated version of Communications Manager, CCX.finesse, Jabber? Yes to all of the above.
- Physical devices? could be a thing of the past! This would allow a fully virtual testing environment.
Vik Malhi, CCIE#13890
Facebook: https://www.facebook.com/VikMalhi
Twitter: @vikmalhi
www.collabcert.com
I am already having panic attacks Vic.. Though I do study Python and Linux, as a voice engineer unless we are working in a company with current requirements for those applications, it’s really a hard job to keep up.. Can you suggest anything or probably a plan about how and what to keep up with as honestly with dozens of things out there, I am really confused what to learn and what to not.. Hoping for a reply from you to get an enlightening perspective..
Obviously I’m not Vic, but I am a UC engineer (or is it Collaboration Engineer…hard to keep up) who also uses Linux and Python quite a bit.
Personally, I started using Linux at home — nothing ingrains technology better than repetition and figuring things out on your own terms and on your own time. Maybe a Mac would be a good intermediate OS choice with the requisite Windows VM for Visio, CIPC (if you have a need), vSphere, and RTMT (sure there are Linux installers and you can install RTMT on a Mac…but some functionality is a little buggy), and any other Windows-only apps. You’ll find yourself needing to do something that you know how to do on Windows, but not on your alt OS. You’ll google and figure it out, and each time it will get easier.
For Python and other scripting/programming languages, I pretty much started the same way — slowly introducing at home and gradually bringing to work. For example, several years ago I had to create a couple thousand translation patterns. There was no BAT option then and still isn’t unless you do an export/import maybe but that’s a pain and requires trial and error. I spent the better part of a day playing around and ended up creating an AXL script which created the translations from a CSV file. All in all, it took far less time than manually creating the patterns, and was a good easing into using AXL which I still use heavily today. Now, that wouldn’t translate directly to using Python for more NetEng-type tasks like SDN but it would give you a foundation in Python (importing modules, string manipulation, maybe some regex, etc) which could be directly applied to that. This evening, I’ll be migrating a couple of large offices between two clusters and altogether making somewhere north of 15,000 AXL requests along with a few BAT operations. I didn’t start there, but starting with those translation patterns was the foundation. …and in all honesty, it took some time up front but is paying off with huge dividends now (in terms of saving time).
I’d suggest looking at your tasks/projects with an eye for something simple(r) that isn’t a drop-everything-and-do-this-instant thing…and automate it. Then you’ll build on that again and again.
Great article Vik,
Thanks to you, i may not have to undergo the gruesome v2 but I have been thinking its about time Cisco skills up people on collaboration on the cloud. Better get started on python!