Overview/Introduction | Round up 1 | Round up 2 | Round up 3 | Round up 4
As promised earlier in the week I’m delighted to have another great take on the O365 SfB onprem career conundrum from someone who is known as a bit of a rockstar developer in the SfB space. I’m also pretty sure that he’ll be key in the building of Skynet (Skynet will clearly leverage Azure and the Microsoft Bot Framework 😉 ) but then thats a quandry for another day…
Say hello to:
Twitter | LinkedIn | Blog | MVP Page
A while back Ben asked me for my thoughts on some good questions about the future of on-premise Skype for Business and those that make their living looking after it. The fact that it’s taken me 3 months to reply to him should tell you something about how things are getting busier, not quieter! But I wanted to sit down and collate my thoughts on this – I have a very different perspective to many. I’m a .NET developer first, and a Skype for Business developer second. I’ve only been in the Skype for Business and communications world for 5 years, before that I worked on retail and governance systems. That maybe gives me a view that isn’t so entrenched and encumbered by history.
Is SfB on-prem going to be left out in the cold because Microsoft wants everyone to have an O365 subscription?
Microsoft have always differentiated their offerings by the quality of software, far above every else. Their strategy is software. That’s why Skype for Business, Lync, OCS, and LCS is installed on standard Windows boxes, not special hardware. The magic is in the software. That sounds obvious today but in 2001 when Microsoft were first getting into the collaboration space everyone else was offering hardware-specific PBX solutions. Microsoft differentiated with a software offering, and its enabled them to stay current as the technology has changed and evolved. Moving to the cloud is nothing more than the next evolution in that technology. Microsoft are still offering a software-first solution, it’s just that the underlying tin has been replaced by a more abstract foundation.
As part of using software to differentiate, Microsoft have always strived (and continue to strive) to embed communication into applications which people use every day, rather than seeing it as a stand-alone offering. This goes right back to the “old days” (which is still today for many people) when users would be working on their computer and receive a phone call from a telephone handset on their desk. They would switch their focus away from the computer and onto the telephone. Microsoft have been trying to combine these two worlds in the way that they embed communication functionality alongside where people are working: whether that’s in something simple like desktop sharing, or in more complicated applications like rich embedding into line of business applications. In order to do this they need to provide developers with the tooling which allows them to do this, to enable them complete Microsoft’s vision. That’s the reason for the breadth of developer tools available on the Skype for Business platform. None of that changes with the move to Office 365 – the vision is the same, the challenges are the same, and Microsoft will continue to support developers to embed communications and collaboration functionality into process flows and applications so that it’s a seamless extension, there when you need it, not requiring you to switch contexts or programs. Focus on the user experience, let the technology get out of the way.
What does this look like over 5 years?
It’s not all completely plain sailing though. Moving Skype for Business to Office 365 was a huge conceptual shift and the underlying platform is very different. Many of the APIs and SDKs built for on-premise Skype for Business had no concept of a cloud offering, and don’t make any sense in a multi-tenant world. UCMA, for example, is a very powerful API for managing and manipulating a Skype for Business installation. Want to silently join every meeting and record what’s said, or send messages as someone else? UCMA is a good fit for both of those, but to allow that sort of power in a multi-tenanted installation without significant work to manage scope is very dangerous. New tools were needed. At the same time that Office 365 was being launched there was a growing realisation that the SIP protocol, which excelled on solid internal corporate networks, wasn’t so good in the occasionally-connected, WiFi/3G/4G, up/down, strong/weak network of the real world that many of us find ourselves in with our mobile devices. HTTP, and specifically REST-ful stateless communication, is a much better fit and will give a better user experience.
New tools, and a new protocol. A lot of work. This work continues, but over the past few years we’ve started to see some of the first fruits of this effort. Rather than completing each API to 100% Microsoft have instead decided to focus on enabling use-cases, and then doing work on as many of the APIs as needed to enable that use case for developers. In February of this year we saw the first combination of APIs come together to enable Remote-Advisor scenarios. It’s a combination of several new APIs – built for Office365, HTTP-based and working together to allow developers to provision and manage new meetings in Office 365 and join them via a web browser of mobile phone. That’s just the first such combination. As new features are added we will see more and more of these scenarios open up over the next 5 years. With each scenario comes new product opportunities, more ways to add rich collaboration into how people work and more chances to delight customers. Technology is constantly changing and evolving – it’s why we’re in this business: it’s exciting. But if you stand still, you die.
My job is based on installing/upgrading/managing SfB on-prem. If we go cloud, what do I do next? Is my job at risk?
This doesn’t mean that on-premise development is dead, though. There are still many things which can only be done using on-premise development, for instance call recording. Undoubtably this list will shrink as more features come to Office 365 but development capability should be taken into account when deciding whether to move to the cloud. And of course there will always be customers who will need or want to remain on-premise. Development tools for on-premise Skype for Business aren’t going anywhere and aren’t being depreciated. They still work, they are still solving problems in the real world today, and I think that will continue for a while to come. The reality right now is that new capabilities and features are coming to Office 365 first, and that reflects where Microsoft have their focus. However, the Office 365 tools have a long way to come before they can match the breadth, depth and power of the on-premise developer offerings. On-premise Skype for Business developers aren’t going to be short of things to do over the next few years, but they should be making sure they are keeping up with the advancements happening on the Office 365 tools as well – partly because they’re exciting, and partly so they are well placed to deliver what customers are asking, both now and in the future.
Thats everyone I had lined up for now but I’m hopefuly going to do a post roundup / summary soon. Do please chip in below or on social with your thoughts too