I’ve heard it before… so have you. You see someone stand on stage and say how they want you to think about something as a platform. It’s the cool thing to say these days as everyone wants to be a platform or have “.js” at the end of their library name and make it onto HackerNews. I’ve heard the same thing from Microsoft in the past about Office 365… people say “it’s a development platform” just like they said about SharePoint when we were only working on-premises… hell even I said it ( September 2007 - SharePoint is a Good Development Platform for Applications)!
But I do believe…
Things are Different this Time Around
When Office 365 was released, we had access to some APIs. We had the CSOM & REST API for SharePoint Online as well as some APIs for Exchange via EWS. The late last year, Office 365 released first class & top-notch REST APIs (with corresponding native SDKs for .NET, iOS, Android & cross platform options as well). These APIs were a break from the past in the sense they were truly enterprise ready and friendly to real app development. They conformed to the OData 4.0 specification, they are versioned with the version number in the URL & they are secured using OAuth 2.0, facilitated by Microsoft Entra ID.
Then in the last two weeks at the Microsoft Build in San Francisco & Microsoft Ignite in Chicago conferences Microsoft announced a ton of new APIs for us to play with. There are now APIs for OneNote, OneDrive, the Video Portal, Skype, Groups and tons of improvements. There’s a new Unified API that is a proxy to all the other APIs to simplify our lives as developers with a single endpoint which means we only need a single access token.
What Does This Mean For Developers?
So many organizations are either already in, or are going to, Office 365. They flashed stats at Ignite that 70% of Fortune 500 companies have bought Office 365 in the last 12 months. There is over 470 petabytes of data in Office 365. There are 830 million monthly meetings. There are over 4 trillion emails.
My point: that’s where enterprise data is… maybe not everyone’s today, but that’s a damn big chunk!
When we build applications, we want to integrate a person’s data within the application. We want them to stay in the application and not have to jump between platforms or apps to copy-paste stuff from one place to another. These APIs make it easy for us to achieve this task!
Plus… when we build custom apps that live outside of Office 365, we can take advantage of some of these services and products within Office 365 within our own custom applications.
That brings me to…
Office 365 is ePaaS For Custom Apps
In the cloud we have terms like IaaS (infrastructure as a service… or hosted virtual machines), SaaS (software as a service, like Office 365) and PaaS (platform as a service… building blocks for custom apps). Azure has done a great job with it’s PaaS offerings.
But I think you should, as a custom app developer, consider Office 365 as ePaaS: Enterprise Platform as a Service. What I mean is that there are tons of business / enterprise services you can leverage within your custom apps that Office 365 brings to the table. Contact lists, calendars, email, video, content management, workflow, file storage… I could go on and on, but you get the picture. There are APIs for all these services. Why reinvent the wheel and build this stuff into your apps? The data is already in a native experience for your customers in their Office 365 tenant, just surface it and let people work with it within your apps!
Another term that is floating around in the cloud dev space is BaaS (backend as a service) which is usually used for services like Firebase… you can think of Office 365’s services and APIs as BaaS too… but I prefer ePaaS as they are more enterprise like service offerings whereas BaaS is more of a commodity storage like service label.
It doesn’t just stop at Office 365 either. Office 365 has tight integration & is very easy to integrate / hook Azure offerings into your custom applications. Heck the two platforms (Azure & Office 365) are in the same data centers around the world. So you’re free to leverage all the PaaS offerings Azure has to offer in your custom apps too!
What is the take away here? Just keep it in the back of your mind when you’re building a custom application. Think consider all the different things you already have access to, licenses to, and where your customer’s data already is. Why not, when applicable and where it makes sense, include that data for your users within your app to keep them more productive. Seems to make a lot of sense to me. This is a message I’ve been using for a few months at different everts and it seems to be resonating more lately… so I thought “I better blog it!” It’s long overdue…
