X
Tech

SharePoint: The team that makes the donut(s)

When Microsoft officials describe SharePoint Server, they often refer to what's called "the donut" diagram -- a picture of the six server workloads that comprise the overall product. But who actually makes the donut(s), and how does the team decide which features to bake into a new release of the product?
Written by Mary Jo Foley, Senior Contributing Editor

When Microsoft officials describe SharePoint Server, they often refer to what's called "the donut" diagram -- a picture of the six server workloads that comprise the overall product.

But who actually makes the donut(s), and how does the team decide which features to bake into a new release of the product? I was curious about the people and the processes of the 5,000+-member team that is working on the SharePoint 2010 release. To get a better feel for the SharePoint team, Microsoft gave me a chance to interview over the past few weeks not just the "usual suspects," but some of the other lesser-known but key SharePoint managers.

SharePoint is built by the Office group and includes approximately 40 teams. According to company officials, the core teams are in Redmond, but there are other large SharePoint teams in Silicon Valley, Boise, Boston, Ireland, Norway, India, China and Japan.

The first thing I noticed during my interviews was that everyone with whom I spoke mentioned the calming, analytical influence of the" father of SharePoint," Corporate Vice President Jeff Teper. Sure, the SharePoint team can have fun; after all, the team's mascot is the Flying Screaming Monkey that can and has been flung via slingshot onto unsuspecting targets of all kinds. But SharePoint isn't a team that lurches from crisis to crisis or one characterized by all-night coding marathons and mandatory pancake breakfasts during the final "death march" of a new product release.

The SharePoint team, which is patterned intentionally on the same culture/processes that have characterized the Microsoft Office team, spends a lot of time and energy talking to customers. Like the Office team, the SharePoint folks spend countless hours watching how customers use (and attempt to use) their product. Team members actually count the number of clicks it takes users to perform specific tasks, with the goal of making each and every feature easier and quicker to access.

When planning a new SharePoint release, the team starts with "an intuitive sense of what should be in here," said Lauren Antonoff, Partner Group Program Manager and 13-year Microsoft veteran. "We look at what's currently hard and why it is hard. We ask why can't it be better."

"We're working with our partners differently than we did in the past," Antonoff added. "In the past, TAP (the Technology Adoption Program test phase) was a nominally assigned kind of thing. It gave us a fractured picture of what our customers were doing."

But starting in 2007, the team started asking users more and deeper questions, which led to the reegineering of the SharePoint development process, particularly the customer feedback loop. Microsoft began hooking up customers with whole teams inside of a product group so they could talk to developers in different disciplines across the whole SharePoint team so that the SharePoint folks could better understand users' businesses and pain points, Antonoff said. Going forward, the new structure should give Microsoft more real-world feedback earlier about how customers are using SharePoint, she said. The new processes are somewhat similar to how the Exchange team operates, she added.

Principal Program Manager Rob Lefferts also played up more and earlier real-world customer exposure as something the SharePoint team is doing differently these days. Microsoft itself is one of these customers. He noted the entire Office division has been running SharePoint 2010 for over a year now, since it was in the alpha test stage.

"We're putting a new build on our servers every week now," Lefferts said.

Another change with the current SharePoint cycle has been the focus on scalability, said Eric Fox, Partner Development Manager and a Microsoft "lifer." (Fox joined Microsoft as an intern in 1993 and held a variety of jobs in the Office client team since then.)

"Scalability has been much more of a core focus this time around. We are making sure we target (scalability) with our architecture and design. We're asking whether any feature has any particular scalability issues," Fox said. "Social networking is a big test case for this."

With the 2010 release, for the first time, the SharePoint product team and the SharePoint Online team are working hand-in-hand. Up until now, the SharePoint Online team has been more focused on studying the Exchange Labs and Exchange Online teams' work, Antonoff said. But with this release, "we're working on it (SharePoint Online) way earlier than we would usually. " She said it's more like "one blurry virtual team" now, instead of two teams working in parallel. The goal is to make the SharePoint/SharePoint Online experience more consistent -- which is key to Microsoft's mission of allowing users to choose how and when they use the hosted version vs. the on-premises version of SharePoint.

Ribbon wasn't a shoo-in for SharePoint

Despite the SharePoint team's close ties with other teams -- especially Office client -- team members don't assume what's good for Office users is automatically good for SharePoint ones.

Gail Giacobbe, Principal Program Manager, is on the team that is responsible for the SharePoint end user experience. Before joining Microsoft in 2000, she was a teacher specializing in anthropology and ethnography. At the start of the SharePoint 2010 planning process, Giacobbe and her team were wondering whether the Ribbon in Office would be useful to SharePoint users.

"We didn't want to take something blindly that worked for client and slap it on there," she said. "But a lot of (SharePoint) customers didn't know how to find specific commands. We did some early wireframes with the Ribbon and then did a cognitive walk-through to see how customers might use contextual menus, the Ribbon and other options. But because people got how the Ribbon worked, we ended up deciding to use it" in the release of SharePoint due out by mid-2010.

(Since SharePoint is the server complement to Office, I'm assuming there won't be as much kicking and screaming over the introduction of the Ribbon in SharePoint as there has been since Microsoft first Ribbonized Office 2007 a few years back. Guess we'll find out soon....)

The user interface change isn't the only new component of SharePoint 2010. As the Softies announced last week at the SharePoint Conference in Las Vegas, there are more than 100 new features coming in the next release. But quite a few of the most noticeable ones in the 2010 release fall into the social networking category.

Even though SharePoint has included rudimentary social networking capabilities for a few years, the product's social networking features really weren't on many people's radar screens," the SharePoint management team admitted. The earliest implmentation of social networking in SharePoint was MySites, which the team introduced first into SharePoint back in 2003.

"With profiles, we let you document what you know. Then we got people search in there -- this was before Facebook existed," recalled Christian Finn, Director of Collaboration Product Management.

But, according to Finn, there's been a dichotomy in SharePoint up until now: People vs. documents. SharePoint originally was conceived of as more of a back-end document server for Office. But it has been a lot more, with all kinds of tools to create and manage "user-generated content." With the 2010 release, the team will be pushing on getting the word out about the kinds of enterprise social networking functionality is in SharePoint.

"We want to make sure Team Sites are a living place... something people come back to and refresh. We want there to be no dead team sites. I don't want it to be that a little piece of me has to die ever time I see a dead Team Site," Lefferts joked.

Getting current and potential customers to think about SharePoint as not just an application but also a development platform is yet another big focus for the 2010 release team. Besides working with the Development Division on making sure that Visual Studio 2010 tools will be available for SharePoint 2010, the SharePoint team is making sure it's obvious to programmers that their ASP.Net and SQL programming skills will enable them to build SharePoint apps, too.

The formerly independent LOBi (Line of Business Interoperability) team, as of the 2010 release, is now part of the core SharePoint team, as is the team building out the Business Data Catalog (now known as Business Connectivity Services) -- further cementing the positioning of SharePoint as a platform in its own right.

(SharePoint actually has always been a toolbox/development platform and Microsoft has been working to make it more appealing to developers -- "the real" audience in Microsoft's eyes -- throughout the product's life cycle, said J. Boye analyst Janus Boye. But there's lots of room for improvement, Boye said. "Compared to other products on the market, SharePoint is much less 'out-of-the-box' and requires several third-party modules, even for basic administrative features," he noted.)

So back to the "donut." The SharePoint diagram is a source of much debate and revision, at least within the SharePoint marketing team. By design (as the Softies like to say), the donut is supposed to reflect the capabilities that SharePoint users actually see and care about ... but to avoid industry buzzwords as much as possible (that's why business intelligence/PerformancePoint is referred to as "Insights" and document-management as "Content." Whatever the ingredients end up being called, the SharePoint team is speeding ahead toward a public beta of SharePoint 2010 in November and delivery of the final product by mid-2010.

Editorial standards