SharePoint 2010 ratchets functionality up a notch across the board. But if Workflow's your thing, you need to do a sanity check before pulling the trigger. Here's a template for that sanity check.
I've done three SharePoint consulting gigs for government agencies, and these days, they all seem to want the same thing: process automation, to make up for workforce attrition. The public yammers endlessly about reducing the size of government, but they want to do that without giving up services. And decision-makers in government have lately been looking to SharePoint for that automation.
We get into tricky territory here. Yes, SharePoint can streamline processes out of the box. Yes, SharePoint has workflow built in. Yes, this workflow is .NET-based, and extensible. But whether to rely on SharePoint, even in its 2010 incarnations, for your organization's workflow platform is far from a no-brainer.Workflow, top-to-bottom
SharePoint's canned workflows are very good at what they do; the thing is, they don't do that much. They execute from top to bottom, in sequential steps. If you're creating a document for public consumption, and the steps are writing, reviewing, approving, and publishing - and it gets no more complicated than that - then SharePoint workflows will do the job, out of the box.
But what happens when your process is iterative? Suppose the content being created requires simultaneous review at multiple levels? That many rounds of revision are anticipated?
Then there's the problem of multiple versions of documents and multiple approvals. I saw lots of this in government, documents with their own lifecycles that required approval and presentation in various stages of development. SharePoint assumes a document is completed once, approved once, presented once. That's often the case, but when it's not - wow, the complexity piles up fast.
And if that isn't enough to send you running for cover, consider compliance issues (as many government agencies must). The requirements placed upon document management and approval by either government or industry regulatory practices are rigorous and complex. Workflows that accommodate such complex requirements must be incredibly robust.
At this point your process is no longer a clean series of sequential steps - it's a tangle of loops. And SharePoint doesn't do tangles of loops.
Ah, but while SharePoint can't, .NET can. Can your developers get you there?If you build it, they will come
SharePoint is, as most Microsoft server products are, built out of the standard MS parts: .NET, SQL Server, web services, XML. And most competent .NET developers can put together a robust, flexible workflow from scratch. So it stands to reason that any shop with competent .NET development capacity can put together complex workflow that can be hosted in SharePoint. This turns out to be the case, and there are plenty of resources out there for the shop that has these skills and the need to go this direction.
But, consider: once you build it, you have to maintain it. Custom code tends to evolve, and so the expense will be on-going. Consider also that if you want to deploy complex workflow that is not just a one-off, but useful generally to a large number of users, you're looking at a lengthy design phase.
On top of this, there's no guarantee that your home-grown workflows will transition seamlessly when you implement the next SharePoint release - meaning you may end up rewriting the workflows.
At this point, you're looking at a third-party solution (and there are quite a few out there to choose from), and crunching the numbers. The third-party solution is likely to win; whatever the cost, the workflows will be generalized from the outset, and compatibility with the next release of SharePoint is foremost on the third party's mind.
This isn't to say that home-grown .NET workflow for SharePoint isn't the way to go. If you can handle 90 percent of your workflow needs with the out-of-the-box workflows, and only have a couple of complex workflows to think about, then you may well be better off rolling your own than shelling out big bucks for a third party solution. And it may, in these lean times, be better to leave process automation on the back burner for the time being. The point, in the end, is that workflow in a SharePoint environment is a complicated question. Think long and hard.