Whether you’re considering Microsoft SharePoint Workflow for the first time or planning an upgrade you’ll be faced with many factors that influence your decision. Even if you’ve already decided to change your SharePoint workflow strategy, the questions raised here will help you broaden your horizon and shape a long-term strategy.
What You Get with SharePoint
Before embarking on any journey, its best to know where you’re starting from, so let’s consider what’s provided by Microsoft SharePoint. There are two components to the Microsoft SharePoint Workflow solution, the workflow engine and the design tool. The primary design tool is SharePoint Designer 2013. Additionally, Visio 2013 and Visual Studio can also be used for declarative development. Neither offers more or less functionality, so it’s more of a choice in familiarity and cost (e.g., SharePoint Designer is Free; the others are not)
Microsoft’s Two Workflow Engines
Currently Microsoft SharePoint supports two very different workflow engines as part of their SharePoint and SharePoint Online (Office 365) offerings. The legacy system is based on Windows Workflow Foundation (WWF), which is the workflow platform included in SharePoint versions prior to 2013. With SharePoint 2013, Microsoft introduced Workflow Manager 1.0 (WFM 1.0), which runs outside of the SharePoint Web Servers on its own farm, making it more scalable. Unfortunately, Microsoft does not provide an upgrade path for SharePoint 2007/2010-based workflows to Workflow Manager, making adoption of the newer Workflow Manager a bit of a chore. Workflow manager is robust, but not easily extended beyond the actions provided by SharePoint Designer 2013.
A Workflow Manager 1.0 Paradox
The new development pattern with Workflow Manager is completely declarative with no-code options. No-code is great, in fact, it’s where we ultimately want to be with our IT investments, but Workflow Manager presents a bit of a paradox. When out-of-the-box capabilities run out, the user is confronted with developing web services as his/her only means of extending into new endpoints, making the no-code, live-style potentially short lived. This web services necessity also presents a personnel challenge; it’s hard to find people who are capable workflow developers who are also capable web services developers. Technically there are other ways to extend the capabilities of Workflow Manager, but these existed in the past too. The eco-system of vendors offering new actions as plug-ins for SharePoint Workflow simply never materialized.
With this as a background, if you are considering a change to your SharePoint workflow strategy, here are six questions you should ask before making a move:
Question 1: Should you consider a SharePoint workflow extension?
Extensions are meant to provide additional capabilities over Microsoft SharePoint’s native capability. Workflow Manager has improved in lots of ways as well, making SharePoint 2013 much closer in functionality to third-party workflow extensions offered in the past. So if you’ve found that SharePoint’s own workflow functionality doesn’t suit your needs, you may also find that third-party extensions to SharePoint may not either. The relatively few number of choices can also make this path discouraging.
Question 2: Should you make the jump to a Low-Code BPMS?
There is, of course, a big difference between workflow—no matter how sophisticated it may be—and low-code Business Process Management suites (BPMS), which enable in-flight process modifications and management as well as extensive instance and rights-management features. Likewise, low-code BPMs utilize diagnostics to enable you to continually refine and improve processes. The key issue with many BPM suites designed to work with SharePoint is that they, themselves, might be built on Windows Workflow Foundation/Workflow Manager creating additional limitations on what a vendor can offer.
Question 3: What’s the connection between Low-Code BPMS and WSF/WM 1.0?
Some low-code BPMs are built on top of Workflow Foundation (WWF) or Workflow Manager (WM). This is an important fact given that Microsoft designed neither of these technologies for enterprise-class application development, delivery, and management. (Note that with WFM and Microsoft Azure Services, Microsoft seems to be trending in this direction, but they haven’t gone all in to this point.) Consequently, hundreds of thousands of instances of complex process applications running simultaneously could cause performance issues with BPMs built on WWF/WFM.
The WWF/WFM connection is relevant for other reasons, too: First, low-code BPMs built on Workflow Foundation may end up modifying your on-premises SharePoint server or MOSS codebase (never desirable). Coded modifications are not supported on Office 365 making them a relative dead end.
Scaling out WWF/WFM is doable but can be costly and a lack of management tools makes performance tuning a “seat-of-your-pants” exercise. You could argue that building on top of WWF/WFM could actually contribute to long term problems and increase costs over time. The easy conclusion is this: if SharePoint’s indigenous workflow capability doesn’t satisfy your enterprise needs, you may want to look beyond it and any third-party system that relies on it.
Question 4: Will your SharePoint apps need to be embedded in other systems?
Some low-code BPMs and workflow extensions are designed to build workflows just for SharePoint. SharePoint is moving past its common role as a content management system and collaboration platform, and becoming a business critical application platform. As such, it’s likely that you’re workflow sophistication will require functionality and data from other line-of-business systems, such as Salesforce, SAP, or Oracle. It’s extremely possible other collaboration and productivity tools like OneDrive, Box or Yammer will come into play, too. Making all these interoperate seamlessly within a single workflow is challenging enough, but users will ultimately demand the same user experience across all their systems, not just within SharePoint. In other words, whatever system you choose, make sure the resulting app can be embedded in virtually any on-premises or cloud application.
Question 5: Are you considering a move to SharePoint Online/Office 365?
If you’re like much of the IT world, you’re probably already transitioning from on-premises software, infrastructure, and platforms to cloud-based services. In which case, you might already be contemplating a move from your on-premises SharePoint farm to SharePoint Online, which Microsoft now includes with multiple Office 365 plans. Likewise, Microsoft makes it possible to add SharePoint Online to other Office 365 plans for just a few dollars per month, making the change as attractive as possible.
But here’s the kicker: If you’ve ever augmented your on-premises SharePoint codebase in any way—either via your own IT department or through a 3rd-party workflow extension—your existing apps may not run in SharePoint Online/Office 365. When choosing a new system, make sure it works equally well with SharePoint on-premises and SharePoint Online, in fact you may chose a SharePoint hybrid model (on-premises and cloud), so make sure the platform you choose works with both seamlessly and without limitation.
Question 6: Is it time to stop throwing good money after bad?
The fact is you’re already facing complex decisions about your SharePoint future. Do I upgrade to the latest version on-premises? Do I move to SharePoint Online? Do I start using Workflow Manager, and if so, how do I upgrade my older workflows? How do I incorporate my enterprise line of business systems into new apps? How do I take them mobile? The decision tree, looks far more like a bowl of spaghetti than a roadmap!
There is no silver bullet, but one thing is for sure: You should stop wasting money on your legacy systems and settle on a future-proof application platform.
AgilePoint NX—a Low Code Platform for SharePoint and Beyond
Because of AgilePoint NX’s stateless process engine, it is infinitely scalable, extremely reliable, and will never need to infiltrate your SharePoint code base. AgilePoint NX has the sophistication to build business apps of any complexity, is easy to use, easy to deploy, and provides a great user experience. And perhaps most compelling of all is the fact that you can be up and running with AgilePoint NX in days or weeks, rather than months or years, as is the case with other elite, low-code BPMs.