The Case for Temperance
How solution accelerators can impact your K2 projects.
There is a common theme I have observed with many solution-oriented platforms in the last several years. Platforms and their partners offer a myriad of prepackaged solutions or bespoke methodologies promising to enable customers to get their first solution live faster.
For the purposes of this post, I will use the term ‘accelerator’ to encompass both pre-packaged solutions and bespoke methodologies.
When businesses are spending precious capital on new platforms, it is entirely understandable that they want to start seeing a return on that investment sooner rather than later.
The increased pressure of the impending deprecation of the SharePoint workflow engine has teams scrambling for an easy button as they look to migrate those legacy solutions to new platforms.
Nintex Automation K2, for example, offers a series of prepackaged solutions called Smart Starters. In contrast, many Nintex partners provide their own tools or methodologies to help them stand out in a crowded field of implementors, each promising faster time-to-first process-live.
And some of these are great approaches, but what I feel needs to be said is to proceed with caution when adopting a framework or methodology.
Think back to grammar school and early math classes. In the same way that you were discouraged from using a calculator until you could prove you understood addition, you should avoid leaning on an accelerator for help until you are familiar with the platforms.
An accelerator should not be used in place of understanding how to use a platform effectively.
I have recently said in class that K2 is not highly opinionated regarding how it is implemented when crafting a solution. There are a few solid rules that you should never break, like using the API to make changes to a running workflow from within that same workflow, thus creating the digital equivalent of a bootstrap paradox, or, in DBA terms, database locks.
That is both the joy and the challenge of working with K2.
There are multiple ways to achieve various goals in the platform. It is a primary reason that when speaking with seasoned K2 consultants, their first words in response to many questions will most likely begin with, “It depends.”
It isn’t deflection; it is just an honest response from a wise consultant who knows there are options for addressing business requirements, and that your choices should be driven by an understanding of the fuller picture of what is trying to be accomplished.
The myriads of options can present a challenge to a new K2 developer, and it is that glut of choice which drives the appetite for accelerators.
Used in the proper context, accelerators can be an immense help in providing direction, but they are not without risk.
Accelerators are generally meant to obscure complexity in exchange for velocity. Build new solutions faster without going too deep. The risk here is that K2 is already obfuscating complexity in exchange for visual design tooling and reusability. Many times, accelerators try to obfuscate the perceived complexity of K2. What do you get when you obfuscate complexity that is obfuscating complexity? New complexity!
Am I suggesting you don’t use accelerators? Absolutely not. They can be great tools, but they aren’t meant to be a substitute for knowing how to leverage the software’s features.
Methodologies or “better” practices can serve as excellent starting points and guides for managing your solutions on the K2 platform. The K2 Center of Excellence materials on the K2 Community website are a good resource for approaches that can help your foray into K2 development go smoothly. Just don’t feel you are obligated to craft your solutions exactly as shown in those documents. Find what works for you and your organization.
When using something like a Smart Starter, for example, a K2 developer is going to be beholden to the K2 product team’s opinion on how to build a solution. K2 uses its own product to make K2, so its understanding of how to build with K2 is constantly evolving.
A K2 developer needs to know how K2 solutions are put together so that they can maintain a prepackaged solution or customize it to meet business-specific requirements.
My recommendation is to take the time to build your first solution from scratch when getting started with K2. Learn how the parts fit together, how they behave, and how you troubleshoot problems. Use accelerators as a cheat code to gain inspiration for building your solution, but make it yourself. The hands-on experience will serve you well as you move into more complex solutions, or if you decide to adopt an accelerator, you will be in a much better position to both customize and maintain your project.
What do you think? I would love to hear your thoughts on different approaches for getting to your first process live.