Low-Code Doesn't Mean Low-Analysis
This is a blog I wrote a few years back and seems relevant now that low-code is making more waves across the industry.
For the past few years, low-code solutions for business process management software (BPMS) have been released by many BPMS vendors. As a BPM consulting company, ClearCadence tries to keep tabs on low-code solutions, especially with the companies where we specialize, namely Alfresco, OpenText, and K2.
The premise can be one of high value: Use a low-code platform to speed the development and delivery of BPMS-based applications. This is achieved as most low-code platforms are easier to use because they provide a visual interface with drag and drop capabilities, out of the box components and simple form design. The platforms can be given to end users (or civilian developers) or used internally by IT staff in order to speed up the completion of business requests for new applications. Lastly, low-code platforms can ease the burden of having to maintain custom code, compiling that code, and re-deploying.
The Up Front Questions
There are a number of questions a company should consider when looking at a low-code platform for their BPM development:
Is it flexible? Low-code is a great start for an application but what happens if functionality is needed that goes beyond what low-code can provide? In other words, can the low-code platform also support medium and high-code?
Is it expandable? If a well-formed and fully functional low-code application is a hit with the user community, can the underlying architecture support an increased number of users and transactions?
How will the platform be governed? Experience has shown that when a company puts out a “fast ramp” application to the user community, the number of solutions can quickly turn into "application sprawl." So, what was intended to be a boon for IT becomes a bane due to the number of applications, environments and hardware required by the solution which, of course, all needs to be supported by IT. We can look historically at Excel, Access, and SharePoint as proof of this issue.
Is it affordable? Serious consideration of low-code pricing models to end results needs to be evaluated to make sure it is a good investment.
Is it as easy as its being advertised? Low-code is a common buzz-word these days and BPM platforms are touting it, but low-code doesn't always mean "easy to use," "easy adoption," or "easy implementation."
But Let's Not Forget...
The above list is just a start of things to consider but there is one additional question that should be easy to answer (but I fear may get pushed to the wayside):
Since this is so easy to do, do we still need full analysis, requirements discovery, and a detailed design for our low-code platform projects?
The very obvious answer should be YES. The reality, however, is that having a tool that enables a fast ramp-up of an application may cause people to sidestep the importance of knowing what the application is for, why they need the application, who is going to use it, when will it be needed, where it will be used and how they intend to use it. As many analysts have stated before, the 5 W’s and 1 H for journalism very much applies to analyzing an application development project, low-code or not.
Avoid Impulse Coding
The impulse is easy. Departments with access to the tool use it to “solve” a problem that either just came up or has been a thorny issue for some time. They do so by simply diving in, creating what they need and putting it out for people to use. Little to no planning is done on how the application should look, making sure it is satisfying all requirements and achieving the proper departmental measurements, or if it should be one step in a much bigger process improvement initiative. When the application is used, it is invariably modified as functionality is found missing from the initial roll-out. It’s not a big deal in a low-code platform to make changes but it becomes additional work that could have been avoided if the proper analysis was done up front.
Additionally, from a citizen developer perspective, very little thought is given to how often the application is accessed and by how many users nor is much consideration given to the number of transactions the application will need to handle. Is the architecture appropriate and will it scale for such an application or will it cause a server failure within the first day because the usage of the application was not part of the planning?
"This application doesn't do that, so let's build a new one"
The other danger is that instead of updating an existing application because it’s missing a key feature is to just create a brand new application that does 95% of what an existing application does except for the one new feature. This easily leads to application sprawl which was the core problem with the other end user development tools mentioned previously. Ten applications may get built when one or two could have covered all the features of the ten. This type of sprawl happens because the up-front analysis work was not performed properly (or not done at all) and no formal application governance was instituted.
What Does This Thing Do?
The lack of analysis and the associated documentation that should come with an application implementation can bite an organization later down the line if the original developer has moved to another department or worse, another company. Suppose a new feature is needed for an existing application and a new person has been assigned. What documentation is available for the new person to review? Do they know the specific business problem the application was trying to resolve? Do they know why a certain piece of the application was included when, on the surface, it doesn’t look to be doing anything? Chances are there isn’t anything to refer to or if there is, it’s more than likely a single email asking for the application with limited requirements. Often when this happens, we go back to the notion of needing a new application because they don’t know enough about the existing one.
A strong IT organization has procedures and processes in place specifically to guard against issues like this. They span from established methodologies to source code repositories to specific steps for moving applications into production. If a low-code platform is put out to citizen developers, it is important that these same types of methodologies and guidelines be in place to ensure proper documentation is completed, consistent development practices are followed and deployment procedures adhered to. A low-code governance should be in place before low-code development occurs, not after.
Low-Code Has Its Place
This isn’t to say low-code platforms don’t have their place within organizations. They most definitely do, but just like a project that has high coding and integration with multiple applications, analysis and documentation is needed up front to know what is being built instead of just building it and hoping it covers everything. Does it need to have the level of detail as a big project? Maybe not, but it definitely should cover the “5 W’s and 1 H” at a minimum and documentation should be written and made available to anyone who may need it in the future. This all leads to the need for some sort of governance over such a platform. The governance doesn’t need to be super stringent but at a minimum, there should be a list of guidelines that a low-code civilian developer or a low-code team to follow when building an application.
And the very first of those guidelines should be “Do your analysis first.”
Kevin Beddingfield is Managing Director at ClearCadence and heads up ClearBPM, a packaged service for companies to help gauge their BPM readiness in addition to doing full analysis, requirements documentation and functional design for a BPMS project from a software agnostic point of view.
