Low-Code Not Low-Control
Here at ClearCadence, we work with many low-code business process management software (BPMS) platforms in relation to solving our customers' business challenges. Having this exposure has given us insight into how low-code platforms should be governed. Notice I am not saying how they should be used, but how they should be governed. It’s an important distinction. Companies need to keep control over their low-code initiatives.
A few years back we published a blog called “Low-Code Doesn’t Mean Low-Analysis.” This centered on the notion that just because something appears to be easy to do, like some low-code BPMS applications can be, it doesn’t mean you should just jump in and abandon standard project management regimen like requirements gathering, design, and testing. Now that low-code continues to be more widespread and common in businesses, it’s probably a good time to talk about the importance of the governance of these applications.
Don’t Let History Repeat Itself
Remember the early days of applications like Excel, Access, and SharePoint, which gave business units the ability to create their own spreadsheet applications, databases, or user sites? The idea was that allowing end users to do this themselves would free up development teams so they could work on bigger and more complex projects. And allow the business to be more nimble. Seemed like a good idea, and probably went well for a while. But then those development teams started getting calls about…
The end-user created SharePoint sites being slow.
Queries against Access not working right.
One department needed data that another department stored in an Excel file.
Servers started to run out of space due to the number of files and databases created by each department.
Performance degradation spread across the enterprise because of the number of SharePoint sites being generated.
This is known as “application sprawl” and if you are not careful, low-code platforms could introduce a new wave of the same and it could end up being much worse.
Low-code BPMS applications do more than just store data like an Access database or run a few formulas in an Excel spreadsheet. BPMS processes can have hundreds if not thousands of transactions running across multiple process flows at one time. Users could be accessing data and forms in these processes many times an hour or even a minute and if the servers running the low-code platform are not sized properly, applications across the enterprise could suffer. This would be evident in user tasks loading slowly or searches taking longer than expected, for example.
Control the Sprawl
Low-code BPMS applications are better suited when there is a plan in place to control how they are used. A low-code platform should be seen as an extension of other programming languages like Java or .NET. In some businesses, the low-code platform could be used within an Information Technology (IT) department where Java Developers who are not fully utilized could work within the BPMS. Same for a .NET programmer. BPMS provides that tool to expand an IT department’s resources since knowing a particular programming language is not necessary to build solutions within it. By using this approach, it allows IT departments to pass their requests for projects across more developers compared to companies without a BPMS platform.
To make an even bigger impact, you can include business units into the mix by having them build their own solutions or build some percentage of the solution and then pass them over to IT to complete the rest (implement JavaScript or REST calls, for example). This approach spreads out the development of the application allowing requests and projects to get completed much quicker and by utilizing each team’s strengths.
The next step to this approach is building “Low-Code Teams.” These teams make sure governance is applied on top of the development. A Low-Code Team would consist of business analysts (BA), Power Users (PU) and IT Developers (IT) with oversight from IT and business unit management. Multiple Low-Code Teams should be created where there is one in each major department within an organization. This would work more optimally than having a single team over all departments.
Each team would have one or more managers from IT and the business units to oversee them and to ensure the teams meet on a regular basis. Look at this as a center of excellence (COE) for BPMS applications. These groups and their meetings would…
Ensure better communication of what is going on in each department.
Provide standards for creating BPMS applications.
Share the information about the applications and re-usable components being developed so everyone knows what is running and can review at any time.
Provide performance metrics so the business users know how their applications may be affecting the system.
Provide training on the BPMS tool where and when needed.
By having all of this in place, it’s possible that one department’s proposed (or existing) low-code application could be leveraged and used in another department, thus decreasing the sprawl.
These meetings would also give IT a chance to better understand what applications are being developed:
How many steps are in the process?
What is the expected number of process instances being created weekly, daily, or even hourly if it is a high-volume solution?
How much data is being collected in each application?
How many users will be utilizing the solution?
Are there any governance rules for the accumulated data?
Are the applications being designed properly and adhering to the platform’s best practices?
Do any of the servers require any type of upgrades and/or load balancing to properly scale?
All these factors impact the servers supporting the BPMS platform. If they are not sized properly then issues will occur. By having knowledge of the applications ahead of deployment, it can be determined if the environment needs to scale up to accommodate the proposed applications or if the solution needs to be redesigned, or possibly merged with an existing application to lessen any potential impact.
It’s all about communicating, anticipating, and planning for the applications versus letting the Business Units run rampant with a new application that addresses a single issue instead of trying to combine and leverage functionality into less applications.
It’s important to note that while the Business Units certainly know their business processes the best, they are generally not technologically inclined enough to consider what impact an application would have at the server or network level. This is why it’s imperative that IT is an active participant in the Low-Code Teams.
Make BPMS the Hero, Not the Villain
Introducing a BPMS platform to your organization can be and should be a benefit across the enterprise. Without the proper controls in place, however, it could quickly turn into a problem and be looked at as a failure and potentially abandoned. ClearCadence published a white paper that goes into this in much greater detail, “BPMS as a Development Platform.” It dives into the governance topic as well as several other points to consider when you are considering adopting a low-code BPMS platform.
As always, ClearCadence is here to guide you through this process and make sure your implementation and continued use of a low-code BPMS is done properly by providing expert level skills and real-world experience in developing and using BPMS.
Kevin Beddingfield is a long-time BPM architect with a specific focus on automating business processes - from training on BPM concepts to designing, developing and implementing end-to-end BPM solutions for Fortune 1000 clients.
ClearCadence has a long track record of assisting customers with analyzing, planning, designing, and implementing solutions. Visit the link below for more information about our organization.
