One of the common problems I meet when talking about Office 365 is when people discuss the service as it was in the past instead of how it is today. Like all technology, Office 365 has evolved over time. When Microsoft launched Office 365 in June 2011, it really wasn’t much of a cloud service. Instead, customers bought into a loose collection of cloudified on-premises applications with some administrative bits to make everything hang together.
Today, after massive engineering efforts and some acquisitions, Microsoft has transformed Office 365 into a very different beast. The stovepipes that once isolated Exchange and SharePoint are gone. New applications built from multiple components drawn from Office 365 and Azure are taking a lot of market attention, and new APIs allow developers more access to Office 365 than ever before.
A critical part of the evolution of Office 365 is the development of the Office 365 substrate (Figure 1). If you search for a description of what the Office 365 substrate is, you won’t find a crisp definition. To me, after observing Microsoft for many years, the substrate is all about a set of common services that tie Office 365 together. We see these services turn in in places like the data governance framework and search today. In the future, the common services might become more important than the Office 365 headline acts of Exchange, SharePoint, and Teams are today.
Jeffrey Snover, a Microsoft Technical Fellow most famous for being the “father of PowerShell”, underlined the importance of the substrate on March 6 when he announced in Twitter that he had started a new role as the architect for the Office 365 intelligent substrate, explaining that he’d be leading the application of artificial intelligence (AI) to Office 365.
When quizzed about what this might involve, Snover gave some interesting hints about what the role might involve (Figure 2). First, he said that the model is to move all Office 365 assets to a single common store and called that the substrate. Today, Office 365 uses multiple repositories from ESE (Exchange mailbox databases and Azure Active Directory) to SQL (SharePoint) to Azure data and media services (Teams and Stream) to Cosmos DB.
You could read the statement to be a declaration that Microsoft will merge all current repositories into one uber-database. That might be the intention, and it might well happen one day. Although Microsoft certainly has the capabilities to execute such a massive transformation, the need to keep operational systems running means that a phased approach would be necessary. You could, for instance, see SharePoint Online and OneDrive for Business move from SQL to ESE in one step. Such a move would put the two major Office 365 workloads on a single platform and allow greater advantage to be gained from the database and I/O improvements made in ESE over the last 15 years.
If Microsoft doesn’t physically rationalize the Office 365 storage layer, another approach would be to construct the substrate as a common logical view over many repositories, much like the Graph API offers programmers a consistent method to access data drawn from multiple Office 365 sources.
Microsoft already built intelligence into different parts of Office 365. Consider these examples:
However, these are all point solutions. For example, there’s no equivalent of the Focused Inbox in Teams, so the Teams Activity Feed can become a blurred mass of notifications from hundreds of channel and personal conversations. MyAnalytics is great at understanding email activity, but knows nothing about how people work with documents, spreadsheets, and presentations. And so on.
Given that Microsoft accumulates so much data about how people work inside Office 365 (too much data for some), it’s a reasonable bet that AI might help people cope better with the information available to them that’s scattered across directories, mailboxes, sites, channels, plans, groups, and web sites. In applying any AI to user data, Microsoft must walk a tightrope to ensure that any results achieved are not at the expense of weakening user privacy. That’s quite a challenge given the different regulations in place around the world.
I think Office 365 will continue to evolve away from its on-premise heritage. In 2029, we might not talk about Exchange, SharePoint, and Teams in the way we do today. Instead, we might consider items of information managed in a unified substrate with differences between items being exposed by clients and how they are processed by the substrate.
Figure 3 is my sketch of where Office 365 might be heading. Cloud consumers shouldn’t worry about how data is stored – just that it is available, secure, and useful. A set of common services that work against the data, including AI, eliminate the problems that we have today where some Office 365 services deal with data differently than others. For instance, you can search against Data Loss Prevention sensitive data types for items stored in SharePoint but not in Exchange. The set of services will be comprehensive (just a few are shown here).
We know that the amount of data available to users grows over time. Office 365 users store much more information today than they did in 2011. Mailboxes have grown, archives expanded, SharePoint has made more storage available, and Teams doesn’t control storage for its messages. In fact, Microsoft likes when people store information inside Office 365 because it makes it harder for tenants to move somewhere else.
Intelligently applied in a way that focuses on real-world problems, AI has the potential to help users cope with Office 365 in 2029, whatever that might be. It’s a big challenge, but I can’t think of someone better than Jeffrey Snover to take on the task of making AI relevant and useful to Office 365. It will be fascinating to see how this story develops.