We know from past experience (the global economic crisis of 2008, for example) that, during and after times of economic stress, companies pivot from exploring new opportunities, back to lowering costs and improving efficiencies.
While process automation/workflow management should be part of one’s strategy for aspirational goals like digital transformation, it has always been seen as a way to ensure fiscal responsibility – and rightly so. It’s also been a key to ensuring that fewer mistakes are made and fewer steps are overlooked or forgotten.
But that won’t be true if the applications in question look like Rube Goldberg machines; designed intentionally to perform a simple task in a complicated way. Wikipedia notes that “Usually, these machines consist of a series of simple unrelated devices; the action of each triggers the initiation of the next, eventually resulting in achieving a stated goal.”
Sounds like a lot of low-code/no-code tools, doesn’t it? And a number of thought leaders (or thought-leader wannabes) have found attention, if not outright fame, advocating how to build applications that are fundamentally fragile.
You know your application is fragile when…
- It has a lot of different moving parts.
- A change to even one of them breaks the whole solution.
- Finding what changed and determining a repair/adaptation is anything but clear.
- A deliberate change in one place will necessitate changes in countless other places.
- Those countless resulting changes are hard to know in advance.
- Deploying those changes involves a lot of discrete manual steps and post-hoc tweaks.
Fragility is expensive
Tool acquisition costs money. Development time costs even more money, though. And what can cost the most of all?
- Maintenance.
- Debugging.
- Adjustments.
- Deployments.
- Updates.
- Auditing.
- User feedback.
- Business metrics.
- Evolved procedures
- Data requirements.
If your application is made up of a lot of barely-connected moving parts, all of these curation-related activities will be a nightmare.
As one low-code workflow vendor I know used to put it, you might find it best to regard such applications as “disposable”, because curating them would be a nightmare.
Well, I don’t think you want disposable applications. I think you want reliable applications. I know I do.
This doesn’t mean integration is bad
Integration is actually essential. But we ought to be integrating rock-solid applications using well-understood rules for which fail-safes and error-handling procedures are in place.
And application that is 99% juggling activity among a bunch of other applications? You’re tempting fate.
You knew I’d eventually bring up WEBCON…
Everything I’ve said is true. I said it long before I joined WEBCON. But I joined WEBCON because this is another one of the fundamentals they nailed nicely.
WEBCON BPS applications are developed as an integrated set. Deployed as a set. Secured as a set. Updated as a set. Analysis is built into the platform and doesn’t require extra work. Ditto auditing. They contain workflows, forms, data, reports, dashboards, data connections, and linked data sources, and curation is wired into the platform’s DNA. They’re not fragile.
But it’s not only about WEBCON
WEBCON isn’t the only low-code application platform that cares about reliability. Other companies who make low-code tools think you ought to avoid fragile solutions, too.
We sometimes compete with each other, but that happens a lot less often than when we compete with an idea: companies willing to bet they can hack something together with in-the-box, do-it-yourself tools. Plenty of people with YouTube channels and blogs have told them they could.
That approach is fun, and seemingly cheap at the start, but deceptively and ultimately fragile and expensive.
If you don’t use the right tool, you will become the tool
Deployment of your applications still has to happen. Deployment of all the assets needed by your applications has to happen. Updates (either through careful exchanges or radical rip-and-replace procedures) still have to happen. Finding out how a solution is used ought to still happen. It’s not a matter of if, but how, they will happen.
You can use a platform that has this built in or you can do all of that yourself.
Smaller-scale experimental applications to scratch a tactical itch can be solved with anything. But when you cross a line, what got you to that line won’t get you past that line.
So think about it – please.
