Intro to SharePoint & SOA

I've been developing and configuring SharePoint for about 4 years now. I was involved with the MOSS 2007 TAP Program and used it to gain an all-expense paid trip to Europe to train others upon its release. Let me start off by saying 'I love the product'. It integrates well with Office products and if my contacts on the product team are telling the truth, this will improve immensely in "Office 14". The document management capabilities are the best I've used in a web-based solution. Finally, it has a fairly simple object model that make it easy to interact with.

However, one thing I've learned is SharePoint is NOT a development platform - nor do I believe it is truly intended to be - nor do I believe it should ever be. SharePoint is a 'portal' application. (See here for the community definition.) It is intended to be a central access point to other applications. What I have been guilty of and what I continue to see others fall prey to is the temptation of developing even the smallest applications within SharePoint. Most often these applications take the form of complex web parts with lists as data sources or ASP.NET web pages stored in various locations within the SharePoint database or file structure. Often, this tight-coupling to the SharePoint server breaks SOA tenets and/or wreaks havoc on any kind of flexibility requirements. (The ALM difficulties of developing and deploying apps in SharePoint also indicate the need for small one-man efforts.)

Resources from Redmond Developer Magazine:
Platform Rising
SharePoint Does It All

Forrester Report (this one costs money folks!):
Now Is The Time To Determine SharePoint's Place In Your Application Development Strategy

Having said all of that, I truly believe SharePoint is integral to any SOA initiative in Microsoft-friendly enterprises. Its use of web services to provide access to its object model is extensive. The various ways SharePoint provides access to external data is also SOA friendly. Like Microsoft CRM provides services to expose its related entity data and Team System provides client object model access to work items, etc., SharePoint should act as a way to have your other applications interact with your documents, simple lists, and even kick off workflows.

Sidebar: Speaking of workflows, I've also seen too many developers go straight to Visual Studio to develop workflows. SharePoint Designer reminds us all of FrontPage, but there really is a lot of power there. When the workflow becomes complex enough to really warrant Visual Studio development, try to build custom workflow activities. These activities can then be used throughout your enterprise. Workflows that map critical business processes should be treated like any other application and not be tightly coupled to SharePoint. Host the workflow in a service and let it call into your custom database, document library, etc. (I've talked to developers that have made state machine workflow versions of existing sequential ones as if the fact that it is a state machine somehow will improve the end-user experience. When writing methods, some logic is easier to do recursively than iteratively and vice-versa. The same is true for state machine versus sequential workflows.)

So, keep your portal a portal. Build your web applications in ASP.NET and put a hyperlink to them in your portal pages. Don't struggle trying to get AJAX or Silverlight to work in SharePoint, thereby adding significant time and complexity to your efforts. Do it faster and keep the larger enterprise in mind outside of SharePoint. As developers and architects, it's important we keep the business needs in mind and not simply push products and technology to its limits because we can get away with it.