Low Code: facilitating digital transformation

The Low Code and No Code concepts and the solutions that support them are back in fashion. The challenges that the digital transformation process is posing to organizations in terms of speed of response, cost reduction and adaptability make all the benefits offered by these platforms very attractive and necessary, as long as we adequately address their implementation.

In this article, we will review past experiences, what lessons we learned, and how to apply them to make our Low Code Application Platform a success story.

En este artículo hablaremos de:

1. What is Low Code?
   1. Low Code is not new…
   2. … but now it has found its place in the world
2. Advantages and risks of the Low Code philosophy
3. How to face the incorporation of Low Code
   1. Introducing the Low Code philosophy in an organization
   2. Okay, now how do I approach a development on my LCAP?
4. Keys to success: Our approach
   1. Low Code as an strategy
   2. Realistic customer expectations
   3. Low Code is not Low Architecture
5. Conclusions

The Low Code philosophy and its No Code extreme arise from transferring the principles of industrial manufacturing to the latest great craftsmanship that is application development.

Along these lines, the solutions that support this philosophy seek to provide the user with:

• Standard building blocks (OoTB) that adapt to the specific needs of each user via parameterization and combination, easily replicable and maintainable.
• Easy to use  and very visual construction tools that do not require specialization in IT, and even do not need previous programming knowledge (No Code).
• Tools for the exploitation and monitoring of the built applications: Global management of the different environments (1-click staging), OoTB objects for monitoring the consumption of resources, use of flows, etc.
• Tools for the extension of the OoTB and integration with the rest of the platform through exposure / consumption of services. In this area the IT specialization requirements are concentrated.

Thus, the Low Code philosophy can be seen as the way to evolve the IT development industry towards the productive maturity that we can find in the automotive or naval sectors.

In IT, the search for automation and reuse at an industrial level is not something new: RAD platforms from the late 80s, 4GL languages ​​and platforms from the 90s, lotus Notes platforms or CRMs from the beginning of this century are clear examples. All of these solutions promised:

• Drastic reduction of development time with savings of orders of magnitude compared to custom development.
• Decrease in IT investment both as a consequence of the reduction of development times, as well as by avoiding the involvement of specialized and expensive profiles, in addition to a reduction in operation and maintenance costs
• Anyone can build applications, without the need for programming knowledge. The end user is the one who knows the business and reflects it directly on the application without intermediaries.

But reality is stubborn, and serious problems appeared:

• The ecosystem of applications suffered from a strong coupling to the platform, in addition to high integration costs where all the promised cost reductions escaped.
• The BlackBox effect generated the loss of traceability of the solutions as well as introduced security problems
• No type of lock in philosophy was contemplated, so changing them involved costly migration projects.
• The lack of customization and the concept of everything is possible caused the explosion of "Wild Custom Code" that normally contained all the business logic, without documentation and with serious compatibility problems with the evolution of the platform that caused the entire system to be anchored in a specific version soon obsolete.

Thus, serious doubts were raised about a good idea. In IT departments, the viability of its use in mission critical applications was questioned and it generated distrust in CIOs due to the dangers of technological and financial leverage. Integration problems and poor development practices compromised when they did not nullify investment savings.

So, the Low Code / No Code solutions started their desert journey…

In the last decade, with the explosion of digital transformation, the market situation has changed dramatically. Application lifecycles have been significantly shortened so the times to obtain an acceptable ROI are much shorter. Great opportunities and business needs appear to which we must give a quick but ephemeral response based on opportunistic applications that are difficult to approach from a traditional approach. Business units are intimately involved throughout the conception and development phase, extending the practice of using prototypes that prove the goodness of ideas in real situations for their rapid evolution or discarding.

On the other hand, Low Code platforms have come out of their journey strengthened with a change of focus, which, depending on the manufacturer, seeks to solve the problems of their predecessors: reduction of the danger of coupling, openness to the community, emphasis on no Lock -in, evolution of integration capabilities, etc.

Thus, the Low Code / No Code option is back on the table with force, but to avoid falling into the same errors, they must be approached with a different approach.

As we have seen in the previous chapter, solutions based on the Low Code philosophy have great advantages, of which we highlight:

• Significant reduction in development and start-up times, even reaching savings of orders of magnitude.
• Greater user involvement in the entire definition and construction process, managing to better refine and adjust the result to the needs of the business.
• The visual definition of the flows in the platform itself allows "self-documentation", avoiding the costly and often heroic reverse engineering processes to know what a module, library or application does.
• Reduced development costs by requiring smaller teams.

A quick response, focused on business needs where all the actors in the organization are involved from the very beginning, is possible and facilitated by Low Code solutions, as long as we control the risks that made them capsize in the past, highlighting:

• Ease of use and extensibility provide the false “Swiss Army Knife” feel: “solution for everything” orientation results in over-customization, poor design and a schematic breakdown that brings together the worst of both worlds : A code that is difficult to maintain, poorly documented and where the business logic has been transferred, making us leverage not just a specific platform, but an obsolete version of it.
• The confusion between drastic decrease in development requirements with bridging IT supervision generates development without control and without government integrations, which not only compromises the stability of the entire architecture, but its future evolution. The dreaded lock-in appears.

The maximization of the former and the minimization of the latter goes through a controlled process of global introduction of the Low Code philosophy in the organization as well as an effective and efficient methodology in the development of projects on the implemented platform.

The adoption of the Low Code philosophy implies a change in the way of thinking about possible IT solutions to business problems. We are facing a strategic project in which its success depends, to a large extent, on a correct implementation process that we will structure in four phases:

• Phase 1: Architectural study / Business
• Phase 2: Request information from different manufacturers (RFI)
• Phase 3: Proof of Concept (POC)
• Phase 4: Deployment plan

PHASE 1: ARCHITECTURAL STUDY / BUSINESS

In this first stage we will make an analysis from different perspectives of how to carry out the implementation of the future LCAP and whether it is really useful to our organization

• OPS Vector: Those responsible for architecture will identify the adaptation needs in the current platform to fit the new LCAP. Likewise, we will define the technological requirements for deployment, operation and integration to be satisfied by the LCAP.
• IT Vector: IT managers will identify the development and maintenance needs that are generated with the implementation of the LCAP as a whole: cost of licenses, interface development, reverse engineering processes, migrations, etc.
• Business Vector: Together with IT, we identify those business areas that due to their needs or implications are candidates for the new LCAP. A global update of the back office processes supported by obsolete and amortized technology are the type of situations in which the Low Code option can be more than successful.

The first and fundamental decision that we have to make is go/no go based on the cost/ benefit ratio defined in the work of the three vectors. If we go ahead, with this study we have the context where our new LCAP will be useful and identified the technological requirements of the LCAP and our current ecosystem.

PHASE 2: REQUEST INFORMATION FROM DIFFERENT MANUFACTURERS (RFI)

Although it is an optional phase, if it is recommended, either directly or through trusted suppliers, to ask different pre-selected manufacturers in phase 1 for additional information on the main architectural, development and business requirements to complement the collection of requirements made in the study.

As a result of this RFI we recommend selecting two or three applications for phase 3.

PHASE 3: PROOF OF CONCEPT (POC)

An axiom in IT that we all know well is that "paper can take everything." The
Phase 3 is, therefore, essential to verify that everything analyzed in the two previous phases is in accordance with reality, knowing that "the truth suffers when examined."

To be truly useful, this POC must be:

• Based on realistic use case, if possible a real business process of those selected to be supported by the LCAP
• With a reasonable number of interactions with the other components of the organization's architecture (CRM, ERP, event bus, etc.)
• Limited in time to really check the benefits of the LCAP and have information in a timely manner
• Limited in cost, since it is still a test and not a real implantation, to which we will try to get as close as possible

We will study the different preselected platforms in various dimensions, evaluating various aspects of the LCAP:

• Development: We will analyze the cost, time and necessary equipment regarding a custom development, involved profiles, requirements and facilities for migration, goodness of development support tools, or adaptation to different methodologies (Waterfall, Agile)
• Architectural: Following the requirements identified in previous phases, we will study aspects such as integrability, stress tests, deployment environments (cloud, on premise, hybrid), lock in and coupling, and the aspects of DevOps defined.
• Manufacturer: We will evaluate aspects such as the licensing policy, the technical support provided or the versioning policy (majors releases, minor releases, patches, update policy, etc.).
• Functional: We will review features such as OoB coverage regarding business needs, the adaptability and extensibility of the platform or, the ability to personalize.

As a result of this test we will have selected the manufacturer that will supply our new LCAP according to our requirements and needs.

PHASE 4: DEPLOYMENT PLAN

In this phase we will define how we are going to implement our new LCAP. To ensure its success, the entire organization must be involved in its construction from the outset, led by IT.

This plan must include, as a minimum, the following elements:

• Migration roadmap of the selected business area, with a special emphasis on managing customer expectations, for which we will involve them throughout the process.
• Roadmap of all the adaptations, evolutions and changes within the architecture to fit the new LCAP
• LCAP governance guide, where it is clearly defined how we are going to use the LCAP for the implementation of the new solutions. In this context, a new figure appears within the organization, the LC Solutions Architect. Among his responsibilities we find:
  • Ensure compliance with the criteria of good governance.
  • Select and validate which applications are really candidates to be supported by the LCAP.
• Cost/benefit analysis to make this project a reality.

Candidate projects to develop on our new LCAP usually have one or more of the following characteristics:

• High indefiniteness of requirements
• Short time to market
• High user involvement
• Changing business needs

The Agile methodology is the best one to face these projects. Their iterative nature, the user integration and the demanding management of their expectations make applying a waterfall strategy the prelude to failure.

• On the other hand, the team that is going to implement the new solution varies not so much in composition to a tailor-made development, but in its level of participation. To be more specific, in the following:
• The involvement of UX/UI is essential, and it is convenient to keep them in mind throughout the project. Ensuring usability criteria, defining the user journey and having people who speak the same language as users within the team ensures the success of the project.
• The figure of the Business Analyst is key in the implementation. They are in charge of the correct mapping of User Stories within OoTB, as well as detecting the needs of "custom development", aligned with the guidelines set out in the governance guide.
• The figure of the Architect is complementary to that of the Business Analyst and equally key, since they will review and define all the connectivity and extensibility needs that the new application requires of the LCAP
• The development teams are smaller, their main tasks being:
  • Implementation of the defined custom code
  • Implementation or adaptation of the APIs and connectors necessary to consume ecosystem resources.

At Opentrends we are convinced that the success of incorporating the Low Code philosophy described above is supported by three main pillars or paradigms:

• Low Code is a strategic decision
• Management of customer expectations and business units.
• Low Code is not Low Architecture

Successful adoption of a Low Code Application Platform (LCAP) requires that it be considered a strategic decision within the company. Considering the implementation of an LCAP as a tactic to solve an isolated problem or emergency or a simple cost reduction is a condemnation to failure.

The implementation of an LCAP must be approached in a global way because:

• LCAPs have significant exit costs in the form of licenses, learning curve, training and internal communication that require time to obtain the desired ROI. It is essential to define the business target area where to apply it according to volume and number of applications, resources involved...
• It implies a change in the way of dealing with how to give the necessary technological support to market requirements. The balance of involvement of the different actors shifts from development to business and architecture.
• They require mobilizing resources in IT and business areas.
• Requires creating new figures and practices within the IT and business departments
• The training of all the actors involved in understanding the capabilities of the platform is essential to harness its full power, maximize benefits and minimize risks.

The entire organization is involved in the change and must be a participant in it. Taking advantage of the speed of response to business needs and the significant cost reduction provided by LCAPs involves realistically involving and exciting all future users, so it cannot be seen as a merely tactical IT decision.

One of the most powerful and most repeated messages when we talk about "what is Low Code" is that these platforms allow us to build applications without having programming knowledge (No Code) or very basic knowledge (Low Code). The direct consequence is generating the “fierabras’ balm” syndrome in the users: LCAPs are the panacea that allows me to solve all problems by myself, without any type of supervision by IT. Not taking this phenomenon into account and mitigating it from a good start is having failure served.

Managing end customer expectations of what they can actually do on the platform, which is a lot, is vital. Internal communication actions that make the business user aware that they have a very flexible tool, that really have development requirements are much lower and allow them to efficiently and effectively address the needs that arise at full speed, whenever we are very strict in the observance of good governance criteria and in the selection criteria of which solutions are candidates to be supported on the LCAP. In solving all these needs, IT participation is critical to success.

A classic mistake is to consider the Low Code Application Platform as an autonomous entity, a black box isolated from the other solutions that make up the organization's IT ecosystem. Our approach considers LCAP as one more element within the IT infrastructure, which must follow the defined architectural paradigms and must meet the following criteria:

• Weak coupling: LCAP cannot become a point of technological leverage that generates a loss of agility in responding to requests, as well as conditioning its evolution.
• Lock - in: The LCAP must incorporate mechanisms and / or strategies that allow not only to dispense with it in the future, but also to incorporate an effective and efficient support to the management of platform incidents or update policies.
• Integration: The LCAP must be able to consume and expose services to the rest of the architecture components following the defined standards (REST / SOAP API, webhook ...)
• Personalization: The brand image that we transmit to the market is nowadays crucial for any organization. The LCAP must respond to all the requirements in UX / UI contemplated in previous sections: Pixel Perfect, reuse of patterns, generation of new design patterns, etc.
• DevOps (CI/CD): The LCAP must meet the operations requirements under the CI / CD strategy such as integration with tools such as Jenkins, compatibility with deployment in containers, support Cloud, On premise and Hybrid strategies, monitoring of use and consumption of resources.
• Security: The LCAP must be integrated with SSO, authentication and authentication systems, as well as provide Roles management mechanisms.
• Traceability: The LCAP must provide mechanisms that minimize the Black Box effect. It must allow collecting and exploiting information on the use of the created flows, objects, consumed resources, etc.

The success of a Low Code initiative is only possible with good piloting from IT and its smooth fit within the technological architecture.

The Low Code philosophy has reached maturity. It is a good strategy to address current and future market needs, it facilitates the transmission of knowledge and the democratization of the generation of solutions within the organization, bringing IT and business departments closer together, which are no longer strangers.

Not repeating past mistakes involves addressing LCAP as a global strategy and not as an answer to an isolated problem. The management of user expectations, the involvement of IT in its correct governance so as not to exceed its limits, ensure that we can harness the full power of solutions that allow organizations to face the challenges of the changing reality in the hurricane of digital transformation.

Definitely, the Low Code philosophy is back to stay.