Richard Harbridge recently posted an article on SharePoint workflow, explaining rather brilliantly what they are, how they work, how you should think about them, and so on.
He asked for comments on Facebook, and I responded with one thing I feel he is forgetting, that is vital to securing SharePoint success.
You see, unlike that may be the attitude of many, a SharePoint workflow is not a business process. A SharePoint workflow is there to support a business process, but it isn’t and should never be the process itself.
Let me elaborate what that means.
The Lock of Doom
A lock of doom, well, I’m not really sure it is a term, but it sounded ominous, is when you have something that is so important you can’t live without it but so complex that you don’t dare change it. A lot of legacy software systems are like this; they were built as atomic units and 20 years down the line, the original developers are gone and nobody knows how to maintain the system. You’re locked in and you can’t change.
A key feature in well-designed software solutions is the ability to create loosely coupled components that work together to achieve a goal. If any component fails, needs to be modified, or replaced with different functionality, that’s fine because we can work on a single component only, leaving the others to go about their business.
I’m not going into too many technical details here, but think of it like a mobile phone charger. The process at which we’re looking is to get power from somewhere into your phone.
To get your Android or Windows phone to work, because you’re an idiot if you use iPhone, you need three loosely coupled components. You need
- The power grid
- The charger
- The phone
Each of these components have specific tasks that they do successfully (another reason why I can’t include the iPhone in the list). The power grid delivers electricity to your socket, the charger converts that electricity into a format that the phone can use, and the phone eats that electricity like it’s candy.
You can replace any of these components, however. If your charger breaks, you can get another one or a different one. The power grid doesn’t even need to be the power grid, it can easily be a USB port on a PC. In fact, with these components, provided again you stay away from that god-awful iPhone thingy, you can charge other things too, like your MP3 player (no, not iPod), your tablet (no, not iPad), or your headset.
The interchangeability of the components means you have reuse and adaptability.
Imagine what the world would look like if all electrical devices had to be built into the power grid, like one giant atomic super-entity. It would be really impractical; you couldn’t put away your vacuum cleaner, for example, and you’d have to have the world’s longest cable to have a mobile phone. And, if something broke, you’d have to fix the entire grid. This would really be a lock of doom, because you would have to know about every single future device when you designed the power grid. Luckily, we have come up with far better solutions.
The process, however, is simple; you want to get electricity from wherever it is produced into your phone. The workflow and the components used to drive this process are the power grid, the charger, and the phone, but these are not the process.
SharePoint Workflows
Far too often, I see workflows that try to be the super entity of the former example. They try to implement everything into one workflow, often redesigning the process to accommodate the workflow rather than the other way around. “Sorry,” they say, “You can’t do it in that way because SharePoint doesn’t support it”.
The thing is, the workflow is not the process. The workflow is there to support and facilitate successful execution of a process, but like the charger isn’t the electricity or the charging process, a workflow isn’t the process.
Your workflows, then, should work to manipulate data to the extent it makes sense, but do so in a way that does not lock you into using that workflow. In other words, you can use a workflow to store data or even the status of a process.
This idea is actually already built into several aspects of workflows. For example, when a workflow assigns a task to someone, it does so by creating an external item in a task list. That task list is completely independent of the workflow, so the workflow effectively disconnects itself from the result of the workflow. The same happens with the workflow history; it is an external list that’s technically independent of the workflow.
Workflow designers need to think in the same fashion and understand that if you try to map a complete process in a single workflow, you will create a lock of doom situation, where you end up with a massive beast that you cannot touch from fear of breaking something.
It’s perfectly acceptable to create smaller sub-workflows that can run as part of a bigger process. For example, you may have an order execution process consisting of several ‘stages’. Each stage can be its own workflow, focused solely on supporting the process at that stage. On completion of an order entry stage, for example, you may trigger or update another workflow which will create and mange the subsequent stages of the process.
Note: Note my use of the words process and workflow; they mean different things.
I discussed workflows with one of my students a few weeks ago, and we discussed a somewhat complex business process involving many different stages and multiple levels of branching. The process itself was several pages of Visio screenshots, spanning at least two departments, and crossing several site collection boundaries.
Initially, the student was overwhelmed with the task, but as we broke it down into smaller components, we were actually able to build the entire process in a couple of hours. Then, when something needs to change, it is merely a matter of updating one small workflow, and the rest of the process goes on as if nothing happened.
A final point to make with this is that if you ensure the output of your workflow is not store in the workflow itself, you also ensure that if you decide to replace the entire workflow, no data is lost.
For example, if you have a report that shows the status of your latest 200 orders, well, if you get that status from the workflow and the workflow goes away, you suddenly have no data on the status.
Instead, if you update a status column or something like that as part of the workflow, then you can effectively remove the entire workflow, replace it with something else, and move on as if nothing had happened; no data loss, no broken reports, no redesign of taxonomy.
And that makes me a happy bear.
.b
Found this article valuable? Want to show your appreciation? Here are some options:
a) Click on the banners anywhere on the site to visit my blog's sponsors. They are all hand-picked and are selected based on providing great products and services to the SharePoint community.
b) Donate Bitcoins! I love Bitcoins, and you can donate if you'd like by clicking the button below.
Donate Bitcoins
c) Spread the word! Below, you should find links to sharing this article on your favorite social media sites. I'm an attention junkie, so sharing is caring in my book!
