Redmond Review

Apps for Office 2013: Software plus Services, Indeed

The new "Apps for Office" model allows developers to build add-ins for Office that are implemented with HTML5 and JavaScript.

• By Andrew J. Brust
• 10/01/2012

In 2005, Ray Ozzie joined Microsoft through the acquisition of Groove Networks. Shortly after coming on board, he began to advocate Microsoft's embrace of the (Web) services model in virtually everything it did. Ozzie departed the company in 2010, leaving his mandate only partially implemented. But with the release of Office 2013 Preview and its new extensibility model, Ozzie's vision for a new Microsoft may now be complete.

The new "Apps for Office" model allows developers to build add-ins for Office that are implemented with HTML5 and JavaScript. Such apps (code-named "Agaves") are akin to HTML5-based Windows 8 immersive applications, but Agaves run on Web servers, not in the Windows Runtime. As such, they tie together the Web, Web services and the Windows desktop in a paradoxically logical way.

Combined with the other Microsoft cloud initiatives, this model rounds out much of what Ozzie advocated. To see this, let's retrace some of Redmond's steps in its services journey, then consider the change that journey signifies -- and the Microsoft heritage it maintains.

To the Cloud and Back
Microsoft began its services crusade in fits and starts, but eventually came to implement the vision along three pillars. This first pillar involves hosted versions of Microsoft server products, including Exchange, SharePoint, Lync, SQL Server and, soon, Team Foundation Server. The second pillar involves creating browser-based versions of client applications, most notably in the form of Office Web Apps. The third pillar involves the provision of a services infrastructure, with Windows Azure. The Office 2013 extensibility model now brings these pillars together, in service (double entendre intended) of the Windows desktop.

Apps for Office can run in Office desktop apps, Office Web Apps or in SharePoint (be it on-premises or online). Apps for Office can be hosted on any Web server, making use of any Web service, but Windows Azure will work especially well for both. Apps for Office can be distributed via the public Office store, a private file share, a SharePoint list (online or on-premises) or even from Exchange (online or on-premises, once again). Apps for Office can be developed in the lightweight, browser-based Microsoft "Napa" tool, or in Visual Studio 2012 -- and can even be started in Napa, then migrated to Visual Studio.

Apps for Office tie together the Microsoft services and cloud push: the hosted servers, Web apps and cloud infrastructure all come into play, and can be mixed and matched with their on-premises counterparts. The JavaScript/HTML combination makes the Apps for Office model compatible with non-Microsoft languages and platforms, consistent with the outreach strategy I discussed in last month's Redmond Review ("JavaScript Diplomacy").

But all of this inclusiveness, all of this tolerant heterogeneity and all of the public Web-cloud-datacenter agility comes home to roost -- and adds value to -- Microsoft's historic core assets: Windows and Office. Microsoft has changed, and yet stayed the same.

Not All Rainbows
There are some challenges and risks here. First, the Office COM-based add-in model, and its Microsoft .NET Framework and Visual Studio integration points, are still available and are still the most powerful option. Will enterprise customers, who dominate the Office market, embrace the new, more-limited model? Conversely, will the app developer and customer demographic be drawn to a productivity and collaboration suite as a platform? These may both be tough sells.

And it's not as if Microsoft hasn't tried this before; in fact, it did so 10 years ago, with Office XP 2002. With that version's smart tags feature, an underlined piece of content in a document could be clicked on to invoke contextual Web services and data. With the Research Pane, Web-borne content could be rendered in a task pane, alongside the document. Will the Agave model's content apps and task pane apps encounter the same weak adoption, or will things be better the second time around? It's hard to guess, but it's clear that Microsoft is intent on giving the Windows client a seat at the services table.

Microsoft's journey to the cloud began under the moniker "Software plus Services." But that name suggested Microsoft was looking at the cloud too much through the lens of the desktop. The name was dropped, and Microsoft built cloud services unfettered by desktop bias. The Apps for Office model grants the cloud its independence, but federates it back with the rich client. The Software plus Services name may be gone, but its spirit -- and Ray Ozzie's battle cry -- are alive and well in Redmond. With Office 2013, they'll be more fully implemented, and now they'll be fully tested.