Originally published by SD Times
SharePoint comes with most of the components needed to create line-of-business applications, including Web parts, lists, workflows and more. So the question for organizations is: When do you bring in developers? Are they merely customizing these features, adding some small piece of functionality, or doing full-blown application development with SharePoint as the underlying infrastructure?
The answer, of course, lies in the needs of the organization, as well as with the expertise of the IT staff.
"Because SharePoint offers so many options, there's a lot you can do before you even start with developers," said Chris Keyser, Microsoft program manager for patterns and practices for SharePoint guidance. Keyser said a lot of Microsoft customers are still just getting a feel for SharePoint and are only working around its edges.
"Building Web parts, changing a workflow... these are things you can do with a limited understanding of the platform. Getting into custom lists, event and feature receivers, things like that, the more you need to know," he said.
While SharePoint might be foreign to the information workers who are learning to assemble business applications from these out-of-the-box and custom components, the architecture should be immediately recognizable to Microsoft developers.
"If you're coming in from .NET, concepts like master pages and Web parts are familiar," Keyser said. "You can get moving quickly. At some point, depending upon how far you want to go, there are some good resources out there."
He pointed to MSDN as an onramp for .NET developers moving to SharePoint. "You should understand how features work in SharePoint, how solution packages work in SharePoint..."
After the decision is reached to customize SharePoint or build out entirely new applications, putting in place a good set of practices is critical, as it would be for any new development work, Keyser said.
"You should think early about putting in source management [and] testing, and consider how it will be deployed," he said. "Sometimes we see patterns where business users get excited and want to do their own thing with SharePoint. It's like the old days of [Visual Basic]. The departmental guys crank things out, and you end up with lots of things deployed with no source control. You need governance mechanisms in place to control developed assets and how sites grow."
Yet as familiar as the concepts might be to developers, SharePoint application development is modularized, which forces developers to think in new ways, according to Mike Fitzmaurice, vice president of product technology at Nintex, who formerly was responsible for developer evangelism efforts at Microsoft.
One of the underlying intentions of SharePoint, Fitzmaurice said, is a drive toward declarative development and component development. "SharePoint facilitates declarative development," he said. "Declare a form, get a Web application. Declare a data source, get Web parts. Declare a spreadsheet model, get a Web service. Create feature definitions and site definitions. It takes a different set of skills."
