SharePoint challenges IT as the Excel, Access of the day

Just as the use of Microsoft Excel and Access grew at unfettered rates in the 1990s – often under IT’s radar – the vendor’s Office SharePoint Server is spreading quickly through large companies as a development platform for users, according to a new study from Forrester Research Inc.

As the Web sites, workflows, electronic forms and dashboards built using SharePoint tools mature, users are turning to surprised IT operations for support, said Forrester analyst John Rymer, who wrote the report. Oftentimes, the requests for support are the first time IT officials learn of the applications, he said.

“This research resulted from inquiries from clients – expressions of pain and concern,” he noted. “We started to get questions late last year from application development groups suddenly being asked to support this new platform – SharePoint. They were being asked to provide custom applications [and] to support applications that were built by power users.”

The report compares the spread of SharePoint to that of the Access and Lotus Notes databases in the 1990s. Departmental users used those tools to build applications that collect and manage data because they couldn’t quickly get the projects onto IT’s development schedule.

And SharePoint ups the application development ante by allowing users to add workflows to business processes and build their own collaboration sites, Rymer noted. “It’s the same idea that drove the Access and Excel phenomenon but users have more rope to hang themselves with.”

For example, one large industrial conglomerate, which Forrester did not name, has for the past three years provided a Windows SharePoint Services site all of its 140,000 employees. Some employees have administrative privileges, allowing them to customize Web sites, while others developed applications using SharePoint Services. The result: employees created thousands of SharePoint sites, making useful information hard to find, the report said.

At another company, a single user at an unnamed large financial services company built several popular custom applications using SharePoint and assumed that the application development group would support them. However, that support required specialized skills that neither the company’s application development group nor its operations group had, the report added.

The problems can be exacerbated by multiple major gaps in SharePoint’s application development capabilities, the report said. First and foremost, the Application Lifecycle Management (ALM) features in SharePoint are incomplete. It does not provide source control and other ALM tools, and its content database not compatible with popular source management products, Forrester said. Users interviewed for the report noted that all they can do to tackle the lack of ALM in SharePoint is create custom policies and approaches to ALM using Visual Studio extension for SharePoint or third party approaches.

“To really embrace this as a platform, [development groups] are going to have to cobble together something on their own,” Rymer said. “The nature of the beast is that SharePoint allows for pretty rapid changes to applications. That really puts a lot of pressure on ALM to maintain control. Don’t underestimate that.”

Other major gaps in SharePoint for application development noted in the report include: Reliability availability and scalability features are not well understood; Enterprise data integration for SharePoint is primitive; SharePoint skills are scarce; and Tools to upgrade SharePoint 2003 3.0 and 2007 are limited

To adequately to prepare for the use of SharePoint as a development platform, companies must first whether to replace .Net or other programming methods with SharePoint or not and what types of applications will be sanctioned to be created using SharePoint, Rymer said. “The key thing is to ensure that the development that is being done is commensurate with the organization’s commitment to budget and commitment to the platform,” he added.

Companies also need to incorporate policies and educate users about what type of development – if any – will be allowed using SharePoint, Rymer noted.

“If you’re going to allow them to create sites, they have to have guidelines,” he pointed out. “They are not developers. Can they create new code or can they only add content to the site. You’re really sharing the work between end users and IT. IT is really delegating a portion of the creation and deployment and ongoing maintenance of these applications to the business people.”

Other best practices noted in the report include: Keep SharePoint customization to a minimum; Require that all new code be evaluated for quality and safety; Define an information governance policy; Build an ALM environment; and, Employ Agile development’s joint teams and iterative releases

Despite the gaps in using SharePoint for development, Rymer said that users like it because it meets a broad set of their needs. In fact, Rymer next plans to document the productivity gain of using SharePoint for development versus .Net. “You can build and deploy applications with a very small amount of the effort that is required in using .Net,” he said. “That could be a big win because there is this insatiable demand for more applications. We have to create more and more of them very rapidly.”