Thanks to the largesse of my employer, I had the good fortune to attend Sharepoint Summit 2009 in Montreal. It was not as large as Microsoft’s annual conference, but the smaller conference size allowed for greater interaction with speakers and vendors.
Mike Fitzmaurice of Nintex gave one of the more interesting talks, as part of the keynote speaker’s round-table. Fitzmaurice is current V.P. of Product Technology for Nintex, a Sharepoint work-flow application vendor. Previously, he spent ten years working at Microsoft. Much of his talk focused on the way software is developed at his previous employer, particularly as it relates to Sharepoint.
As Fitzmaurice described Microsoft’s process, Sharepoint and other major server products from Microsoft have a three year development cycle. This three year cycle is driven in by Microsoft’s three year software assurance contracts to major customers. Planning for each three year development cycle begins during the third year of the previous cycle.
Whatever doesn’t get built by Microsoft is left for their partners to fight over. In a sense, Microsoft builds the competitive playing field that vendors scramble over at the end of each development cycle. For example, Nintex, Captaris and a few other vendors are duking it out for competitive advantage as Sharepoint workflow tools.
If Fitzmaurice description is accurate, it seems to me that a Microsoft is doing a great disservice to their customers. A three year development cycle is incredibly long in the software field, and a product like Sharepoint is hurt by such a long development cycle. With product planning starting up to a year before a new development cycle, features in the released product could be outdated by the time the product is delivered.
For example, with today’s emphasis on transparency in companies today, Sharepoint’s complicated security model seems hopelessly out of step with the times. Yes, people want security, but if your aim is to empower end users by giving them Sharepoint, why saddle them with a complicated security model that demands a third party tool to properly administer, or the intervention of overworked IT staff?
Another consequence of this three year cycle is that newer computing paradigms and concepts that gather steam outside of Redmond may get shortchanged in the development process, arriving as afterthoughts to the final product. For instance, it seems clear that as the date neared for Sharepoint 2007 release, somebody in Redmond noticed blogs and wikis were “hot”, so, voíla, blogs and wikis were added to Sharepoint. Only the feature set is so weak that the Sharepoint blog and wiki offerings are barely acceptable.
Fitzmaurice characterized Sharepoint, to paraphrase, as something of an 80% solution. Without third-party vendor add-ons and support, Sharepoint out-of-the-box won’t fully solve real-world business problems. Microsoft’s aim is to build a solid platform for third party developers, and Microsoft and their partners both win by developing solutions on top of that platform.
But for many of the mid-market companies eager to use Sharepoint, a sumptious budget for add-ons is just not an option, especially in today’s economy. The consulting and support fees for those add-ons are just another budget-buster.
In the end, Microsoft’s strategy of taking a long time to build a good-enough solution serves Microsoft’s needs, but not necessarily the needs of their customers. Quoting Steve Jobs, Fitzmaurice praised Microsoft’s efforts to work with their VARs to create an “ecosystem” of products built around Sharepoint. But I’m not so sure their strategy works well for their customers, especially the small start-ups that are the heart and soul of innovation in technology today.