In an era when demand for new software easily exceeds developer resources in many organizations, low-code appears to promise a solution. Low-code tools let organizations build software, especially web and mobile applications, with professional developers in far less time. They also can empower so-called citizen developers to build their own applications. It's ideal, or so it seems.
In the real world, crossing the boundary between line organizations and development teams has proven complicated, but, in response, it has spurred some creative strategies. In the low-code examples that follow, two businesses, with confidentiality guaranteed, share their stories about how they overcame challenges and found satisfying results.
Low-code example 1: Insuring success
Our first company is a big insurance firm. Like most companies in that industry, the firm deals with frequent changes in state and federal insurance regulations, and, at the same time, needs to analyze losses and pricing to build a better profit picture. It has a variety of groups, ranging from highly technical actuaries to sales and support organizations. All of them need reports to support ad hoc projects.
The company adopted a respected low-code tool and introduced it to the key people in the line organizations. Yet, after six months, results had been disappointing.
Everyone had their own view of the problem. Developers said they were burdened by the need to support citizen development efforts that created nothing useful. Citizen developers found it difficult to get started with their applications, often because a group of line people would get together to discuss a problem and then try to find a solution to that problem. This often failed because what citizen developers thought were common requirements were, in reality, not at all the same in terms of integration or processing.
The developers tried to address this by building custom extensions to their low-code product. These extensions, though, weren't adopted by the citizen developer teams, who felt that they didn't address their needs. One said, in frustration, "I don't even know what this is supposed to do." Developers admitted that their extensions were their own ideas.
The solution was to develop a business process management (BPM) project based on domain-driven design principles.
BPM and domain-driven design are techniques used to align IT projects with business goals. In the context of facilitating cooperation between line organizations and developers for low code, the benefit with this is to get all parties on the same page with respect to requirements. The next step is to fit tools and features to those requirements.
The company had not previously employed BPM, and there was resistance at first to what seemed like a step back and a delay to the low-code initiatives.
The insurance company selected a design tool that allowed it to position its operations into business domains, which then became business processes. That led to a far better organizing of the teams needed to support specific kinds of application development. It had the right people involved in the process, and it had identified the specific relationships of each low-code development to other developments.
It took six weeks for a team of software architects and some key user stakeholders to complete a BPM model. The individual processes in the model were then prioritized to address first those processes that could quickly be made to support low-code development.
What makes a good citizen developer -- and a bad one
Each process was reviewed by a team of two architects and a user representative to lay out an application model, and a developer contact was identified based on the skills needed to support the model. The data and business dependencies identified the user organizations that needed to be involved, and the specific team that should take the lead on the business side. The result was that the teams labeled 12 business processes. Developers built nine new application templates, complete with four customized code objects. Using these, the citizen developers were able to generate the first code within two to three weeks. Code output and effectiveness improved steadily thereafter.
Developers and line departments considered the project a success.
Low-code example 2: Retooled retail
Our second company is a second-tier retailer. Feeling the competitive pressure of Amazon and other big players, the company began to ramp up its online and mobile sales efforts. It immediately ran into problems keeping applications up to date, and the company also realized that it needed a lot of new reports to assess the success of online sales, optimize the way it priced products and how those products were presented to potential customers.
Because the development organization had little expertise with mobile or web development, the retailer adopted a low-code tool. Unfortunately, the first three coding projects failed.
The tool's basic drag-and-drop approach was adequate for a simple web or mobile application. But to support a satisfying customer experience, the site and app needed to draw data from a variety of core applications and to provide a means of synchronizing the updates of multiple databases when a purchase or return was made. This capability didn't exist in the simple low-code tool the company had initially selected. That tool's ability to generate reports also proved to be lacking.
The development organization met with everyone who had been involved in the three failed projects to determine what had gone wrong. Armed with a wish list of user-level requirements, a team of two users and two software leads assessed available low-code tools. The company then selected a different low-code tool, one that had web capabilities, report capabilities and the ability to automatically integrate multiple application data sources and to create custom objects to augment the basic drag-and-drop objects provided within the tool.
These low-code examples make it clear that a project benefits from having developers create custom templates and objects or extensions that tune the product.
The team that selected the software identified 11 new objects that represented either custom integrations of multiple application interfaces or custom data relationships used in reporting or updating. The software leads worked with architects and developers to create these new custom objects, with the two users from the selection team ensuring the results matched business needs and that they understood how to use both the low-code package and the new tools. They prepared a set of templates to illustrate the use of these objects, and they ensured that the developers supporting the citizen efforts were familiar with the tool and the new objects.
The two users from the selection team then picked a pair of citizen developers from each of the line organizations involved. These users were put in charge of training those new citizen developers, with support as needed from the development organization. With one developer responsible for general support of the low-code product, and the same developers who built the custom objects handling questions on those objects, skill with the new product took only a bit more than a month to develop. It was at that point that the first fully useful code was produced.
Within four months, all but one of the citizen developers was able to pick up the new low-code technique.
Overcome the low-code challenges
These low-code examples make it clear that a project benefits from having developers create custom templates and objects or extensions that tune the product to the way it will be used in a particular business.
Also, we can see that, for a low-code project to be fully effective, the developer relationship with the line organization needs to be structured. This partnership starts with business project identification and ends with tool development and support. It's that combination that creates low-code success.
