New engineering philosophies drive innovation within Office 365

New engineering philosophies drive innovation within Office 365

Office 365 means different things to different people. Someone who moved from Exchange on-premises probably takes an email-centric view of Office 365 while those who now use it for SharePoint Online see Office 365 through a different lens. This is natural because each of us views the world from our own personal perspective.

It's inevitable that Office 365 would be like this. After all, as I noted in a previous post, its history lies in a loose combination of some very distinct and different applications (SharePoint, Exchange, and Lync – now Skype for Business but earlier Office Communications Server) that didn't really have much time for each other. Sure, Microsoft made an attempt to have SharePoint and Exchange work better in the Wave 15 (2013) release with a common search platform and site mailboxes, but nothing really changed then in terms of a common vision of how software should be delivered to end users.

But all of that was in 2012 and three years later a strong feeling exists that change is in the air. That feeling was reinforced by many of the sessions and demonstrations offered by Microsoft at the recent Ignite conference.

I see three catalysts driving change across Office 365:

New ways of using available technology, including acquired software. In the on-premises world, a software designer is restricted by the capabilities of the product for which they are responsible. An Exchange architect can't assume that SharePoint will be around, or Skype, or anything else. They work with the bare fabric of Exchange. It's a different world inside Office 365 because a lot more technology is available, especially in the enterprise plans, so architects can stitch together components from different products to create new capabilities. it's almost as if they can choose from the spare parts bin of Office components to come up with something different.

Take the Delve People Experiences announcement from April 14. On the surface, you might regard this as just another refresh of the card-based Delve user interface, but beneath the surface you find that the old SharePoint user profiles are being refreshed to become Office 365 user profiles, the old SharePoint blogs are becoming blogs that can be published by any Office 365 user, and a greater integration with Yammer (all that "Praise" stuff that remains a mystery to me but seems to make people happy) and OneDrive for Business.

Although Delve is now in general availability, the new interface is just showing up in First Release tenants and is incomplete (compare the screen shot from my tenant below with the one shown in the Office blog). But as that blog states; "some of the features pictured …, like Working on and Praise, will ship in the near future after today’s announcement."

Technology is also being stitched together in Office 365 Groups, which provide a common identity for access to many different types of information held inside Office 365, including a mailbox, calendar, notebook, and document library with more on the way, including integration with Yammer. The interesting thing here is that the members of a group don't have to care about which part of Office 365 stores and manages the data they access. Over time, Office 365 Groups are likely to replace traditional distribution groups for some tenants (nested distribution groups, dynamic distribution groups, and universal security-enabled groups are acknowledged challenges).

The Office 365 Video Portal is another example. This portal leverages SharePoint to store metadata and permissions about video content and Azure Media Services to hold transcoded copies of the videos suitable for display on different types of device. It also leverages the Office Graph to track videos that are watched so that it can recommend videos to users.

New engineering philosophy. Looking at the on-premises world again, the classic approach is to have engineering teams responsible for different feature sets that are brought together in builds and eventually shipped as a product version. Office 365 blurs the line because it is a service not a product. Microsoft is responding to this by using engineering teams who are responsible for developing capabilities across the service.

The team working on Data Loss Prevention (DLP) is a great example. DLP started in Exchange (and is available in Exchange 2013) and now it is being brought to SharePoint and OneDrive for Business. The implementation details are different and reflect the reality of the different products, but the goal remain the same: to make sure that sensitive data types are managed correctly within a tenant.

The advent of the new Compliance Center as a one-stop shop for anything to do with retention, preservation, archiving, search and hold is another example. This initiative gathers functionality that is present in Exchange 2013 and SharePoint 2013 and wraps it into a new admin portal that can be used to create and deploy policies across multiple data sources within Office 365.

Competitive pressure: Google hasn't gone away, you know, and the pressure to stay one (or maybe several) steps ahead of the nice people from Mountain View is felt in Redmond. The result is a constant stream of announcements on the Office blog and the Office 365 Roadmap.

The features are imperfect when exposed to First Release tenants and even when they attain Standard Release status. But that doesn't matter because the rapid development cadence will fix bugs and smoothen bumps.

The gap between on-premises products and their Office 365 equivalents is widening all the time. It will not reduce because Microsoft is not going to reverse course. Instead, the number of links and connections between the previously standalone products will grow and develop to become a spider's web. And of course, once a customer is caught in that web, it becomes very different to reverse course and go back to on-premises because it's hard to get data out and impossible to get the same functionality outside Office 365.

Follow Tony @12Knocksinna

Hide comments

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish