Why do so many different administration interfaces exist inside Office 365?

One of the criticisms I have heard leveled against Office 365 is that its administrative interfaces are a confusing mash-up where the browser is the only common thread. In the vernacular of those who occupy the world of user interface design, many different aspects of design language can be seen scattered across Office 365. Put a different way, Office 365 can look, behave, and react differently depending on what part of the service you need to use.

And while the differences might not bother you if you only want to work with a cloud version of your favorite on-premises application, it can hinder those who want to leverage the full potential of Office 365. Just figuring out how to perform an activity in a specific application can sometimes be challenging – and not in a good way.

There's some truth in the feeling that Office 365 does not deliver a consistent experience across all the places where administrators interact with the underlying technology. But when you think about it, this situation is hardly surprising. In fact, what is surprising is just how well-connected the different pieces are. Here's why.

Multiple products, each with their own history: It's only recently that we've seen the first blossoms of unique Office 365 offerings in the form of Office Delve and the Office 365 Video Portal. The other major Office 365 applications have been transformed from their enterprise-centric on-premises historic roots. SharePoint 2001 might have shared a common database with Exchange 2000, but rapid divergence began with the 2003 versions and continued until recently. You can argue that the “Metro” design language introduced for the 2013 versions brought some commonality to the browser-based consoles, but the UI designers working with Exchange, SharePoint, and Lync obviously have different ideas about how applications should be managed.

Another factor is that some commonality has to be maintained between the on-premises software and its cloud counterparts. If Microsoft completely rewrote the administration interfaces for Exchange Online and SharePoint Online, it would create another barrier to smooth migration for companies who want to move workload to the cloud. That's not desirable, so the rate of possible change is moderated by this need.

It’s true that the Office 365 Admin Center attempts to put some order across the service, but it’s really more about components like accounts, licensing, and reporting rather than getting down to the nitty-gritty of application-level management. What’s more interesting is the motion that now exists to build common management for features that extend across multiple servers. The best example is the Compliance Center, which provides a framework to manage features like search, retention, and data loss prevention across Exchange, SharePoint, and OneDrive for Business. It's imperfect at the moment, but the Compliance Center shows how it is possible to assemble the various bits of common functionality from various products into a collective whole. More of this kind of joined-up thinking is what’s needed in order to develop unified administration across Office 365.

Different layers and scale to work against: Office 365 inherits much of the goodness created by the on-premises versions of Exchange, SharePoint, and Lync but it’s a very different operating environment. The layers that an on-premises administrator has to be deal with are well-defined. For instance, Active Directory and Exchange. But that's because a single company uses a single instance of Active Directory alongside a single Exchange organization. Office 365 is more multifaceted. Azure Active Directory is there, but so is Exchange Online Directory Services (EXODS), used by Exchange Online in each of the Office 365 regions. Exchange uses EXODS to hold information about objects such as mail-enabled public folders that don't exist in Azure Active Directory. The two directories synchronize in a pretty seamless manner with the join only visible occasionally when slight delays occur in objects being visible in one place or another. But it's a big difference and when that's added to the multiple Office 365 datacenters deployed in multiple regions to serve tens of thousands of entirely separate tenants, all of whose data must be isolated and protected, it's obvious where the differences lie and how those differences might slow progress toward a unified whole.

Different functionality and different ways of delivering functionality: Exchange 2013 and Exchange Online share a common code base but they're not the same product. Exchange 2013 operates independently; Exchange Online is part of the Office 365 parts bin where new features like Office 365 Groups can be built by taking bits from Exchange, bits from SharePoint, a smattering of OneDrive for Business, a soupcon of OneNote, and some other components. In short, Exchange Online serves the greater good of Office 365 rather than being king-pin of its own deployments. This is why any company that moves email to the cloud must immediately consider how to leverage the totality of Office 365 rather than being satisfied by having cloud email.

But there's more. Microsoft is now happy to deliver new features to customers in an imperfect manner. That is, in the eyes of administrators, many of whom expressed concern when Office 365 Groups, Office Delve, and Office 365 Video appeared accompanied with little or no management capability. Users could care less because they get to use great new software that appears on a regular basis. In the cloud, IT is moved out of the way to become a supporting rather than a controlling influence over the business, which is where IT really should be. 

Microsoft was criticized in the past for not being fast enough to release new products. It might be unfair now to complain when features appear without all the bells and whistles, but that's just the way of software development today. The notion of "MVP", or Minimal Viable Product, holds sway, which is really just a way of saying that you ship software when it contains a minimally acceptable level of functionality with the intention of completing features as time allows and in response to user feedback. In many ways this is better than assuming that engineers and product teams always know best, which is the traditional approach.

We're unlikely to go back to the old ways. Competitive pressure and customer demand drive software to evolve faster and faster. All of this means that management interfaces and consoles struggle to keep pace and provide a coherent picture to administrators.

I guess that there's always PowerShell. If you don't like what Microsoft provides, write your own administration tools. That is, if PowerShell is supported everywhere, which it isn't, even if PowerShell is a big part of the Office 365 automation story.

We live in an imperfect world. This is just another example of imperfection. I'll get over it – some day!

Follow Tony @12Knocksinna