Sixty million Office 365 targets light up for developers

A recent conversation with Rob Lefferts, Microsoft GM of Office Extensibility (I bet some think he is in charge of extending office space) moved me to think just how extensible the overall Office suite is right now.

In this context, Office is the complete collection of the desktop applications (Word, Excel, etc.), the servers (Exchange, SharePoint, etc.), and includes new offerings such as Sway. As such, it’s a pretty broad canvas for which Microsoft has to provide the necessary APIs and tool sets to allow developers to work their magic.

Microsoft divides Office extensibility into three types. Add-ins such as those available for Outlook and Outlook Web App allow applications to take advantage of the contents of messages. For example, taking an airline confirmation received as an email and inserting flight details into your calendar. APIs provide access to the content of mailboxes and other repositories and connectors extend Office to be able to process external data.

The big news announced at the Microsoft Connect () developer event yesterday is the “Microsoft Graph”, an evolution of what was known previously as the Office Graph (for more details, see their blog post). As you might know, the Office Graph is the “intelligent fabric” that gathers signals about the activities of Office 365 users to be able to map the relationships between people. The data in Office Graph are then exploited by applications such as Office Delve and Delve Analytics, which will become available as part of the new high-end Office 365 E5 plan that’s available from December 1.

One of the interesting factoids supplied by Microsoft is that Office 365 commercial now has sixty million active users monthly. In other words, this is the number of individual users who connect to Office 365 at least once a month and do something, like send an email. In other words, they do real work. This is an increase of ten million in the number claimed last May.

The number of mailboxes provisioned inside Office 365 is much higher for many reasons. Some are created but not yet used because the tenant is not ready to begin using the cloud; some are shared, inactive, or resource mailboxes; and others are used by application such as site or group mailboxes. I still don’t think that 35% of the installed base has moved to Exchange Online, but there’s no doubt that Office 365 possesses considerable momentum right now, which makes it a very attractive target for developers.

Microsoft Graph builds on the experience of the Office Graph and work done on graph databases by Microsoft Research (here’s one example) to become the single entry point for an integrated graph that draws information from multiple data sources. In effect, you can think of the Microsoft Graph as having the ability to draw from many different sources within Microsoft cloud services and making that information available to developers through a unified REST-based API (previewed earlier this year at the Build conference).

Microsoft views the Graph and the API as one and the same thing; in graph terminology, I guess that the API exposes the nodes and edges that represent the various data sources represented by the Microsoft Graph with a good helping of intelligent algorithms to make the connections seamless and interesting. The data remains in the various repositories: in this case, because the first iteration of Microsoft Graph exposes APIs, data, and intelligence from Office 365 and Azure Active Directory, the data comes from Azure Active Directory, Exchange Online, SharePoint Online, and so on. You can expect more sources to be connected in the future.

The Microsoft Graph is now in general availability. The API provides developers with a single endpoint (https://graph.microsoft.com) from where they can navigate to any of the data sources available to the Microsoft Graph. The metadata allows developers to navigate through mailboxes, groups, users, documents, and anything else known to the Graph. And once an application is authenticated using OAuth 2.0, it can navigation within the Graph without needing to provide further credentials.

Microsoft wants these APIs to be very approachable, meaning that they support languages such as JavaScript, PHP, Ruby and Python as well as ASP.NET. Essentially, the idea is that any developer who is used to work with current web development technologies should be able to work with the Microsoft Graph without any difficulty. The promise is that developers will have less code to write than with previous APIs (such as Exchange Web Services) and will therefore find it much easier to develop solutions that need to use Microsoft cloud data. According to Microsoft’s post, where 50+ lines of code are required today, the promise is that only five are needed using the Unified API.

In addition, the apps built using the Unified API are adaptable to multiple display formats. In particular, they will automatically accommodate the many different form factors found in mobile devices. However, the developer remains in control of the final shape and finish of their app as it’s entirely up to them as to how they render information returned from the Graph.

As you’d expect, Microsoft’s own development teams are using the new APIs to build applications such as the lightweight project management capability promised by Office 365 Planner. Office 365 mobile apps will also use the Unified API.

In the future, because the Microsoft Graph enables access to many different forms of data consumed by a product like Outlook for Mac, it’s conceivable that future versions might use the Unified API to replace its current underpinning of Exchange Web Services. Of course, this is entirely conjecture on my part, but it seems that such a project would be a reasonable target because Outlook for Mac has never been as functional as its Windows counterpart. But when I speculated, Rob laughed and said that the Outlook team wasn’t looking to make the transition yet.

Although replacing older APIs with the Graph might be an interesting project, you have to keep in mind that the Microsoft Graph is focused on cloud services and wouldn’t work in hybrid or on-premises scenarios. Microsoft recognizes that these scenarios have to be accommodated but the work to fully flesh the right approaches out isn’t yet complete.

It’s also true that many of the components of the Microsoft Graph are inherently linked to cloud technology and so pose a real difficulty in transferring this technology in any meaningful way to on-premises environments. In addition, relatively few on-premises IT departments would be willing to take on the financial and technical requirements of deploying something as complex as the Microsoft Graph.

When asked how he thought third-party developers would react to the Microsoft Graph, Rob said that he thought they would be surprised that Microsoft had taken “such an open stance” and remarked that this is yet another example of how the “new Microsoft is reinventing itself”.

I asked him what success for this initiative would look like. Rob said that he tracked an “extensibility usage metric” based on the number of apps and the number of people who use the toolset. He figures that this helps him to understand the “energy in the ecosystem”. Success means “an order of magnitude increase” in the index. When pressed, he felt that a 10x increase would be good. That seems like a good goal to have.

Time will tell whether Microsoft can convince developers to embrace the power of the Graph. Ease of access to data drawn from across Microsoft cloud services and support of the programming languages that drive the web seem like good steps to make sure that the Graph will be popular. Only time will tell.

Follow Tony @12Knocksinna