My last post discussed the fact that an increasing level of integration to create new features by the Office server products creates some issues for hosting companies (other than Office 365) and on-premises customers. At least in the case of Exchange, Microsoft uses the same code base for its cloud and on-premises products, so why does innovation appear in the cloud and not flow through to the on-premises versions?

I think the answer lies in three reasons. First, Microsoft obviously has the resources necessary to design, develop, commission, and operate all of the necessary components drawn from the different products to deliver more complex software than before. On-premises customers and other hosting companies might find it cost-prohibitive to embark on similar integration projects because they don’t see how the effort involved can be justified.

On the other hand, Microsoft is obviously in the software engineering business so complex projects are in their bloodstream and the benefits achieved from the work can be measured in different ways such as investment in future software directions, creating a competitive advantage over Google, something different to trumpet in the market, and so on.

Second, the Office 365 fabric that Microsoft has created allows them to test and refine new features with relatively small communities of users before gradually rolling out software upgrades en masse across the world. This is the approach taken, for instance, with the transition from RPC over HTTP to MAPI over HTTP currently under way within Office 365.

Microsoft has also indicated that they will need to make frequent and ongoing updates to the Office Graph after it is first made available to Office 365 customers to tune and refine the machine learning algorithms that discover the connections displayed by the “Delve” product based on graph data.

By comparison, when Microsoft delivers a new feature to on-premises customers or the hosting community, that feature had better be fully baked. If it isn’t and flaws appear, Microsoft will have a terrific support load to deal with. Getting updates out to the installed base is easier (in some ways) than before given the new servicing model for Exchange 2013 that delivers quarterly cumulative updates, but that’s nothing like the ability that Microsoft has to tweak and tweak again to refine new features running inside Office 365.

Finally, Microsoft does not have to deal with all of the complications that occur inside on-premises deployments when they design something for Office 365. Although the Office 365 infrastructure is massive and growing like a weed, it is relatively simple and extremely well-understood because every component is standardized. There is no notion of being able to install a third party application because it is requested by one or more Office 365 tenants. No one gets to vote about Office 365 delivers. If something is not in the playbook, it is not available. In short, Office 365 is a highly defined infrastructure that delivers a highly consistent environment for software developers to design against.

These three factors make it possible for Microsoft to take on very complex engineering projects like Delve. The question is whether the same brains who come up with these features can turn their minds to how to package the resulting software in a way that it can be run outside Office 365.

Using the same code base does not automatically mean that the same features apply to every version that flows from the code.  Branching happens. We shall just have to see whether the gap that is now appearing between cloud and on-premises versions closes over time or if the cloud will always have the upper hand in terms of new features.

Follow Tony @12Knocksinna