Unleashing The Full Power of Low Code Platform
The lesson I’ve learned in managing low code platform for automation.
The Low Code Platform Is Slow?
Building a program in GUI is slower than writing code in plain text, and I hated it! If you’re unfamiliar with Low Code Platform, it is a tool that lets you drag and drop a series of logic to develop a program on GUI instead of programming syntax on text editor. The tool is significantly slower compared to typing on a lightweight text editor. Most experienced programmers will think the same way. Imagine performing a series of clicks just to pass a few parameters in a function. For me, it’s not a fun experience.
My view about the platform stays the same until I distill what this platform intends to solve. It turns out that it is bigger than I thought. I started to understand the massive potential of the NC/LC platform. It can generate substantial value for the organization if we design it the right way.
In this writing, I will share how I came up with this realization and some fundamental concepts you need to know when maintaining the Low Code platform.
The Challenges We Encountered
It all started when I was assigned to manage the workflow orchestration platform, primarily for automating IT Ops request fulfillment and complaint handling. The platform has hundreds of jobs and multiple groups of developers (IT operation, service desk, and platform teams). Even though we had numerous developer teams involved, at that moment, I didn’t allocate more time to design a proper playbook for the team. My sole purpose was to deliver many automation jobs that immediately bring value to users.
Then, problems and challenges started to arise. With various departments developing their automation, we could not keep up with the details of each automation job. Half of them don’t have any documentation. Even when “PDF style” documentation available and later being enforced, it’s not entirely accurate. It may not be updated when changes of logic happen on each automation. Eventually, we need to read the logic of each job to understand what it does, which can be time-consuming and inefficient.
This lack of governance and control on building automation produces another set of challenges. We often find duplication of processes, which leads to inefficiency of resources and can be troublesome to maintain. In addition, troubleshooting failed workflow is complicated. How developers instrument logs and metrics may vary, and it creates complexity.
How to Solve It
We must establish standards, policies, processes, and best practices to solve these challenges. However, I believe the old-school formal PDF documentation describing a standard and policy is insufficient. We must embed them into the platform as some form of restriction, automation, or shared component whenever possible. Otherwise, there would be too much control that we need to check to ensure compliance, especially with numerous developers on board and an increasing rate of new automation.
For example, if we want to establish a standard logging format, then create a reusable component specifically for writing logs. Moreover, If we want to make sure each process has this logging component, then apply some restrictions before deployment whenever the component is unavailable in the workflow.
In another instance, If we want the most accurate documentation, write a clean code (flow) and define a better configuration. If we’re going to ensure the developer follows it, then guide them by providing a variety of templates.
I hope you get an idea.
While not all policies can be implemented using this approach, it still can reduce manual review over compliance before deployment. The exact implementation might also vary depending on the platform. It is crucial not to over-customize when implementing it. Instead, we should follow each platform’s best practices to maintain developer familiarity with the built-in platform’s features.
The concept resembles custom mission-critical application development, adopting automated testing and deployment. We should also be aware of common programming principles like loose coupling and high cohesion when creating a component in the platform. The difference is that we need to enforce this concept to automation developers with less technical capability, like citizen developers.
Therefore, the platform team’s mission is to setup an easy playbook for developers while maximizing compliance with the platform’s best practices and ensuring scalability.
The Three Foundations
It is the nature of the LC platform to allow multi-users to create various services or content on top of the platform. After all, it aims to deliver faster solutions and empower users with less technical capability to build one. However, as described earlier, the platform team needs proper governance to manage these dynamics.
From my observation, there are three essential aspects that we need to be aware of when designing a platform that can scale.
Standardization
It is important to settle standardization that multi-developer teams need to follow. Otherwise, it would be too complicated to maintain. The standard can be applied to logging mechanisms, queueing, naming conventions, etc. The goal is to make hundreds of automation jobs run cohesively and have predictable pattern. It will make it easier to manage and scale up.
To show sample implementation, the figure above illustrates how we can enforce standardization by defining input parameters. Then, developers must reuse this workflow when they want to write logs. However, there are many ways to implement standardization to the platform. If it can’t be embedded in the system, we may simply communicate in the developer manual guide.
Reusability
To have an easier and faster development effort, reusability plays a significant role in the platform’s success. Moreover, it will avoid any process duplication and inefficiency in the resources. So, we must enforce reusability in the guidance or design review.
The illustration above shows two different automated processes. However, you may uncover that “Check Status on System #A” is not using the same workflow. The developer might potentially rewrite the entire thing from scratch with slightly different steps.
Duplicated workflow is a common problem in a LC platform with multiple groups of developers. The root cause can be the developer having difficulty finding whether a specific workflow already exists in the platform. Or it can be that the workflow exists but is not configurable (having a static setting instead of a variable input parameter).
We need to avoid this redundancy, and the workflow should be reused.
Easy
One of the biggest problems the NC/LC platform is trying to solve is to empower business users to develop one. Or at least to strengthen collaboration between the IT developer team and the user, as it allows both teams to communicate in the same language due to the nature of the graphical flow in the platform.
When we already have many high-level workflows in the platform, it will be very easy and fast to develop automation. In the best-case scenario, process owners in all department can build automation independently (with less IT developer assistance).
Therefore, whatever use case and design decision we must make, always remember that the workflow in NC/LC platform should be easy to develop and easy to understand.
The Low Code Platform is Fast!
When I first interacted with the low-code platform, I didn’t like it because it was slow. Now, I believe the opposite. I imagine workflow development on top of the platform would be like the illustration below,
Suppose the three foundation principle are applied in every design and governance decision. In that case, we can have a platform that enables the organization to deliver automation fast and foster citizen developers across entire organizations.
Ultimately, organizations can achieve digital/automation excellence and increase organizational productivity.
Key Takeaway
- GUI-based programming in the platform is happen for a reason. It empowers non technical users to develop automation, which can help scale up the implementation across organizations.
- To fully maximize the power of the NC/LC platform, we need to establish a good design and governance.
- In any decision to leverage the NC/LC platform, always consider these three principles: standardization, reusability, and ease of use.
It’s a Learning Process
This concept is something that I realized by learning from the challenges that I encountered. I have yet to implement all of these principles and establish good governance. However, this idea makes sense, and I will use it as my strategy moving forward.
I believe any type of NC/LC platform can apply this concept, not only for workflow orchestration.
What are your thoughts about this story? Let me know if there is something I missed or should consider. Formulating ideas through writing helps me think critically and remember what I have learned. Therefore, this story is part of my learning process and, hopefully, can give you value too.
You can find another story on how we solves problem in managing failed production workflow.
