Kirk Evans is a Microsoft Architect for the Azure Center of Excellence.
Introduction to SharePoint and Azure IaaS
Building SharePoint Apps with Windows Azure Platform as a Service
SharePoint Solutions and Architectures on Windows Azure Infrastructure Services
Understanding Authentication and Permissions with Apps for SharePoint and Office
I've had several conversations with customers lately about creating some type of gadget gallery for their intranet, something that will allow users to create their own widgets that can be reused by others within the organization. Folks are familiar with creating web parts using C#, but that requires you to write code and install it via a solution package. What they typically are asking for is something that an end user can create and upload without requiring IT support. It turns out that SharePoint provides this concept out of the box simply by creating a .webpart file and uploading it to the gallery.
This is done by customizing an existing web part, such as the Data View Web Part. For instance, there's a cool post that shows how to create a weather web part by customizing the Data View Web Part. The web part in that post is created using SharePoint Designer 2007, obtaining XML data from a remote data source and customizing the view of a Data View Web Part. There's another great example of creating a Tag Cloud for SharePoint Blog Sites. Again, a very cool example of customizing the Data View Web Part that is reusable simply by exporting the web part to a .webpart file and uploading it back to the gallery.
Besides the Data View Web Part, you can also leverage the Content Query Web Part. Heather Solomon has a great post that shows how to customize the Content Query Web Part and control the display of data. The Enterprise Content Management team also wrote a great blog post on customizing the CQWP.
The point is that there is a great "widget" framework in SharePoint already. You can do some pretty amazing things with SharePoint as an end user without requiring IT operations to deploy code. See EndUserSharePoint.com for more examples of the great stuff that you can do with SharePoint without IT intervention.
I know that most of my audience is developers, so it is uncomfortable to hear this. "But Kirk, people are going to build lots of junk that we're going to have to end up supporting anyway." Yep, that's right! People are going to be able to get their jobs done, and probably are going to do things that aren't best practices by IT standards. But think of the value here… this frees you up to create the higher-value stuff (workflows, site templates, lots of stuff) without boring you with creating yet another CRUD data entry application. And if the application outgrows the end user capabilities and requires developer intervention, then you already have their requirements in the form of a working example sitting in front of you!
The point is that SharePoint is a fantastic platform for end users as well as developers. The more that developers and IT operations can enable the end users to be self-sufficient, the more value that the business will see in IT.
As someone with his roots in development I understand the sentiment, however, your weather web part perfectly illustrates the conflict that will always exist. Such a web part can be easily crafted from a number of Google or Bing results but an enterprise level solution would have to consider the contract that is created with the XML/RSS feed; in most cases these are either not available for commercial use or carry no guarantee of future stability or consistency.
Thanks to the likes of EndUserSharePoint.com a better quality of self service solutions are more within the reach of the "power user" than ever before but not a single one of those users will understand the implications of using SharePoint Designer and few will appreciate that a solution that took them half an hour to copy and paste will take 20 days to develop as a deployable , supportable and maintainable solution.
I agree that a higher level of end user self-sufficiency is desirable but it inevitably impacts SLAs, raises expectations and creates an additional burden of support. I am first and foremost on the side of the end user but spare a thought for the poor old developer and IT support.
Here's a great example. There's a very, very large telco that adopted SharePoint for collaboration, but their development standard is ColdFusion (yes, they seem to be the last remaining customer for ColdFusion). The business realized that they didn't have to wait for (literally) 6 months for a new web page with a data entry form, that they could use an InfoPath form with an SPD workflow and store the data in a list. The end users went through training and quickly started building simple forms processes.
Once the IT folks got wind of what was happening, their first inclination was to rebuild everything in ColdFusion, even though the SharePoint process was fitting the customers' needs nicely and the customers were happy with their self-sufficiency. They were convinced that it had to be wrong because they didn't create it.
I am a developer, I completely understand the implications of handing someone a loaded shotgun. But the end users are much more technically savvy in many enterprises. They can use tools like SPD to create simple workflows, layer in InfoPath forms, and quickly build processes.
As developers, we should embrace this and find ways to enable the end users without the front of maintainability. We should work with the end users to show them these types of solutions, how they can create solutions on their own, and guide them to information so they can understand how to be more effective.