Obla De OBA Da

This week Microsoft kicked off a major partner initiative around what company executives call OBAs, or Office Business Applications. The OBA effort is yet another Microsoft attempt to reposition Office as a development platform and front end—or what the company calls a "Smart Client"—to back end corporate data.

The strategy is intimately connected to OOXML (Open Office XML) file formats. The OOXML effort coupled with development repositioning like OBAs would likely create more customer lock-in, should Microsoft's plans succeed. Microsoft's platform efforts remind one of IBM during the heyday of its mainframe monopoly. Differently stated: Google is the new Microsoft; Microsoft is the new IBM; and IBM is, well, the old IBM.

To be fair, Microsoft seeks to solve real world problems with respect to helping customers glean more value from their information. But the approach depends on enterprises adopting an end-to-end Microsoft stack—vertically from desktop to server and horizontally across desktop and server products. The development glue is .NET Framework, while the informational glue is OOXML.

Microsoft seeks to create sales pull along the vertical stack between the desktop and server. Cross product feature integration creates dependencies such that customers need to buy several products to achieve the fully stated functionality. For example, Office 2003 or 2007 collaboration and rights management features require purchase of one or more server products.

File Format Trojan Horse
Microsoft partners and customers really need to understand what are Microsoft's OOXML objectives, and they are much, much bigger than file formats. Microsoft rightly recognizes that XML (Extensible Markup Language) offers tremendous informational utility. XML is lightweight and easily tapped by many types of applications. Anyone distributing or subscribing to RSS (Really Simple Syndication) feeds uses XML.

Microsoft's approach to XML formats offers as much or more benefit to the company as its customers. Briefly:

• Microsoft's major XML-based format development priority was backward compatibility with its proprietary Office binary file formats. To get there, Microsoft supports the somewhat—OK, maybe more than somewhat—convoluted XSD (XML Schema Definition) to achieve its objectives. While XSD is supported by the W3C (World Wide Web Consortium), it had limited adoption before Microsoft came along. Argument could be made that without Microsoft's support, XSD wouldn't be widely used (and for good reasons that aren't appropriate for this post).
• Microsoft's backwards compatibility priority means the company made XML-based format decisions that compromise the open objectives of XML. Open Office XML is neither open nor XML. OOXML uses Microsoft proprietary schemas, which are at least partially documented, that the company can change at will. The format is XML-based, not pure XML. If XML is a language, schemas are dialects. Proprietary schemas introduce dialects that may not be properly parsed by other programs. Hence the need—and I contend unnecessary one—for file format translators.
• The use of proprietary schemas may be, in part, a me-first approach. Microsoft may have anticipated, and possibly rightly so, some other major developer would push XML-based formats with proprietary schemas. Microsoft got there first to protect Office.
• By adapting XML, Microsoft can offer businesses many of the informational sharing and mining benefits associated with the markup language while leveraging Office and supporting desktop and server products as the primary consumption conduit. To be clear: There are huge customer benefits with Microsoft's approach, but they are somewhat truncated from XML's true, open potential.

Vertical Apps Along the Server Stack
While OOXML's importance can't be understated, Microsoft's approach to the file format(s) approach is merely a newer piece to a grander strategy. Microsoft has attempted to reposition Office as a development platform for years. The most concerted effort started with Microsoft's 2003 release cycle and cross-feature dependencies with Office 2003 and server software (other than the longstanding integration with Exchange Server).

Microsoft wants customers and partners to treat Office and Dynamics products as develop platforms like Windows. The idea is that customers and third-party developers would create vertical applications—for industries like finance, health care or human resources—on top of Office and Dynamics products, which would tap into into Microsoft server software features and capabilities.

The approach perhaps would fit best with end-user companies developing custom applications.

Couple weeks back, Daz Wilkin, a program director with Microsoft's Platform Strategy Group, came by for a visit. Topic: OBAs. He brought along customer Allen Emerick, director of IT applications and integration for Skanska USA Building.

"Because of Microsoft, our focus is more on data management than application development," he said, referring to plugging in pieces of the Microsoft's vertical stack and quickly building up capabilities specific to his business' needs. Skanska, which is a construction group, employs 56,000 people worldwide.

His company is also example of the kind of sales pull Microsoft gets from cross-product feature dependencies along the vertical stack. Skanska started with SharePoint and will add other Microsoft software for additional capabilities.

"We will upgrade to SharePoint 2007 first in the next couple of months, then start deploying Office 2007," Emerick said.

Microsoft's Office platform approach could require lots more commitment and risk for software developers than end-user companies like Skanska. Developers would trade the benefits of offering independent applications on a shorter stack (e.g., operating system) for those on a taller stack extending from productivity client software. Conceptual benefits include quicker time to market and less development effort. But developers also would risk losing their company or brand identities in Office's big, brassy brand, while narrowing their platform for delivering applications. For example, more people use Windows than Office. There also could be real problems developing for other platforms when committing to Office.

Then there is the risk that Microsoft might some day incorporate similar features as third-party products into future productivity software. Microsoft's moves into business intelligence, collaboration, communications or rights management are examples of separate technologies being incorporated into the company's desktop and server software.

Bette Crocker Cooks for Microsoft
OBA is really Microsoft's newest moniker to describe Office as a front end for accessing back-end data systems. Smart Client name would easily do. But the OBA strategy is more complex, because Microsoft's vertical stack is higher and there is a bunch of new 2007 products with tightly-integrated features. The song remains the same, with a few new verses tacked on to the chorus.

The stakes are higher, too. Microsoft talks about OBAs connected to ERP software from the likes of Oracle and SAP. But Microsoft's long-term goal clearly is to subsume these products' functions; the approach would be similar to what Microsoft is trying to do now with business intelligence. Microsoft will vie for the whole business software stack, a strategy that I believe will be indisputable by early 2009 at the latest.

While Microsoft talks about integration benefits, reality is more complexity rather than simplicity. Along the way Microsoft has released what Michael Gartenberg, JupiterResearch research director, has described as Bette Crocker recipes. Office Accelerators are an example. These tools/blueprints are designed to help partners and enterprises deploy real world solutions around Microsoft's integrated stuff. The recipes are necessary because the so-called integrated benefits are so complicated to achieve.

Microsoft offered more Bette Crocker recipes this week—OBA Quickstart Kits handed out to partner conference attendees. Microsoft also provides additional information at the OBA Web site.

Increased complexity is plenty good reason to ask why Office has to be a platform running on a platform (Windows) and dependent on features in yet another platform (Server System). Exactly, how many platforms do customers really need?

Office is Microsoft's other cash cow, and, of course, the company wants to keep the sales revenue coming in. The sales proposition gets more difficult as more businesses stick with whatever version of Office they've already got.

The computing trend is towards simpler computing—with Web services or Apple's iPhones being good examples. Microsoft's overly ambitious, overly complex platform strategy is contrary to the computing trend and customer calls for easier set up, management and information processing. Complexity is good for Microsoft's partner channel, which sells the companies software. But is that what business customers really want?

I'm convinced that Office as a platform is an eventual dead end. But Microsoft is going to lead lots of customers and partners down that platform path. Office's current dominance is just too compelling. Wait. Maybe a cliff is the better metaphor.

What do you know about lemmings?

Related Posts:

• Why This Services Stage?, Microsoft Watch, July 11, 2007
• Ballmer is the New Gates, Microsoft Watch, July 10, 2007
• Channeling Microsoft Hosted Services, Microsoft Watch, July 10, 2007
• Which Comes First, Software or Services?, Microsoft Watch, July 10, 2007
• Microsoft's Licensing Response, Microsoft Watch, July 9, 2007
• Software Assurance Storm Warning, Microsoft Watch, July 9, 2007
• Is Microsoft's First Customer You?, Microsoft Watch, July 5, 2007
• Microsoft's Closed Book on Open Standards, Microsoft Watch, July 2, 2007
• Microsoft BI Goes MDM, Microsoft Watch, June 8, 2007
• Microsoft's Integrated Stack Gets Higher, Microsoft Watch, May 18, 2007