LCLC Not SDLC: Low-code Life Cycle Needs a Different Operating Model | Blog
Low-code platforms are here to stay because of the rapid application development and speed to market it enables. But why is no one taking the same “life cycle” view for low-code applications and workflows as typical software development? A new model of Low-code Development Life Cycle (LCLC or LC2) is needed for enterprises to realize the potential benefits and manage risks. Read on to deep dive into these issues in this latest blog continuing our coverage of low-code.
Our market interactions suggest enterprises adopting low-code platforms to build simpler workflows or enterprise-grade applications are not thinking about life cycle principles. Though enterprises for ages have adopted Software Development Life Cycle (SDLC) to build applications, it is surprising no such initiatives exist for low-code applications.
As we previously discussed, low-code platforms, requiring little or no programming to build, are surging in adoption. We covered the key applications and workflows enterprises are focusing on in an earlier blog, The Future of Digital Transformation May Hinge on a Simpler Development Approach: Low Code.
Given its staying power in the market, it’s time to consider Low-code Development Life Cycle (LCLC or LC2).
Here are some recommendations on how LCLC can be structured and managed:
Rethink low-code engineering principles: Enterprises that have long relied on SDLC concepts will need to build newer engineering and operations principles for low-code applications. Enterprises generally take long-term bets on their architecture preferences, Agile methodologies, developer collaboration platform, DevOps pipeline, release management, and quality engineering.
Introducing a low-code platform changes most of this, and some of the typical SDLC may not be needed. For example, these platforms do not generally provide an Integrated Development Environment (IDE) and rely on “designing” rather than “building” applications. In SDLC, different developers can build their own code using their IDE, programming language, databases, and infrastructure of choice. They can check in their code, run smoke tests, integrate, and push to their Continuous Integration/Continuous Delivery pipeline.
However, for most low-code platforms, the entire process has to run on a single platform, making it nearly impossible to collaborate across two low-code platforms. Moreover, enterprises might be exposed to performance, compliance, and risk issues if these applications and workflows are built by citizen developers who are unaware of enterprise standards of coding. This also might increase the costs for quality assurance beyond budgeted amounts.
Even professional developers, who are well aware of enterprise standards while building code in an existing manner, may not know how to manage their LCLC. Many low-code platforms allow SDLC steps within their platform, such as requirement management. Therefore, all the collaboration will have to happen on the low-code platform. This creates a challenging situation requiring enterprises to have different collaboration platforms for low-code applications separate from the other standard tooling they have invested in (such as Teams, Slack, and other agile planning tools) – unless they are integrated through APIs, adding overhead and cost.
Also complicating issues is the desire by some developers to have the developer portal of these low-code platforms extend to their IDE. Most platforms prefer their own CI/CD pipelines, although they can also integrate with third-party tools enterprises have invested in. A different mindset is needed to manage this increased technological complexity. Because low-code applications are difficult to scale for large data sets, some of the scaling imperatives enterprises have built for years will need to be rethought.
Manage lock-in: Most low-code platform vendors have a specific scripting language that generates the application and the workflow. Developers who are trained on Java, .net, Python, and similar languages do not plan to reskill to learn proprietary languages for so many different platforms. While enterprises are accustomed to multiple programming languages in their environment, they normally have selected some primary languages. Though low-code platforms do not extensively rely on developers coding applications, enterprises generally would want to know “under the hood” aspects around architecture, data models, integration layer, and other system elements.
Build governance: We previously covered how low-code platform proliferation will choke organizations that are blindly prioritizing the speed of software delivery. Therefore, governance is needed not only in the development life cycle but also to manage the proliferation of platforms within enterprises. Enterprises will need to closely watch the low-code spend from subscription and software perspectives. As low-code platforms support native API-based access to external platforms, enterprises will need to govern that spend, risk, and compliance (for example, looking at such issues as whether some third-party platforms are on the blacklist).
What should enterprises know?
Low-code platforms can provide enterprises with a potent platform. But, if not managed well, it can be risky. To manage the potential risks, enterprises need to be aware of these three considerations:
- Understand vendor solutions and their history: Different vendors can have different views and visions around low-code based on their history around being led by API, Business Process Management (BPM), BigTech platform, or process automation. Most will need their run time engine/platform to be deployed to execute the application/low-code. Others may allow code to be run outside of their platform. Moreover, their capabilities around supporting aspects such as forms, process models, simple-data integration, application templates, and library components can significantly vary. CIOs need to understand these nuances
- Require business and CIO collaboration: Businesses love low-code platforms as it allows rapid application development and shortens time to market. However, as the adoption scales, businesses will realize they cannot manage this low-code ecosystem on their own. Whether CIOs like it or not, the businesses will punt over their responsibility to the CIO organization. Therefore, CIOs need to proactively address this requirement. They will need a strong discovery model to take inventory of their low-code adoption, workflow, and applications that they are supporting
- Assess the applications and workflows the low-code platform can support: Vendors normally claim they can build “complex” applications through their low-code platforms. However, this definition is not consistent and may not be as complex as vendors say. Enterprise-class applications need code standardization, libraries, documentation, security, recovery, and audit trails. Most of these platforms provide out-of-the-box or custom integration with other enterprise applications, project management, and other SDLC tools. CIOs need to evaluate the cost, performance, maintainability, and security aspect of these multi-point integrations
Expect M&A activity
Enterprises’ desires to drive digital transformation will make low-code proliferation a reality. Currently, most low-code vendors derive a small $100-500K revenue per client, indicating the focus is mostly on Small and Medium Business (SMB) segments or small line of business buying. As a result, we expect consolidation in this market with large vendors such as Salesforce, ServiceNow, and Microsoft furthering eating into small vendor’s share. Enterprises should keep a close watch on this M&A activity as it can completely change their low-code strategy, processes, and the business value they derive out of strategic investment into a low-code platform.
What has your low-code journey been like, and how are you using life cycle concepts? Please reach out to share your story with me at [email protected].
