DEVOPSdigest

I'm hoping that low-code ceases to be a topic of conversation. It won, it's everywhere, and thus it's no longer special.

Start with: I'm Tired of Talking About Low-Code; Bigger Issues Are at Stake - Part 1

What I'd like to see us talk about more is that there's an overall approach that can address a lot of these at the same time. And while I use the term more frequently than most, I'm hardly the only person advocating the idea of an application factory.

An application factory is not a piece of software or a set of tools or methodologies. Yes, some tools and techniques are more helpful than others, but this is about a mindset, an approach to solving business problems. Characteristics of an application factory include:

Thinking beyond a single application

A workbench approach looks at each application as a unique creation, fit to purpose, and individually crafted. Two applications might look and feel quite different, especially if they were built by different people. But in a factory approach, there's a consistency to the way information is presented and reported, the way logic is described, the way data is accessed, the way tasks are assigned, and so on. Instead of designing applications, you design services that can be used consistently across many applications.

Budgets are less for single-delivery projects and more for ongoing retainers, as the assumption is that applications are going to be built and revised on a regular and ongoing basis.

A reliance on the platform itself

If the platform provides a data catalog, an auditing facility, telemetry logging and analysis, comment logging, feedback management, and so on, each application can make use of that and not have to do the work themselves.

A commitment to consistency

If one application resembles another, not just in interface but experience and infrastructure, additional training is minimized. Integration costs are lowered. Time to delivery is shortened, and time to adapt and update is shortened further still.

A focus on the entire lifecycle

It's not enough to speed up construction. An organization seeking to implement an application factory approach needs to speed up requirements gathering, design, deployment, user assistance, and continuous improvement.

A focus on total throughput of the system

It's more important to pay attention to the time it takes for five applications to be delivered rather than one. It's also critical to look for bottlenecks in the continuous delivery cycle.

For example, in an environment where construction claims only a small part of that cycle, perhaps making design and requirements gathering more accessible to non-technical people (with technical professionals still handling construction) makes more sense than giving those people construction tools and asking them to figure everything out for themselves (citizen designers instead of citizen developers).

For another example, if application design details and annotations can be harvested and reused, creating documentation and user instructions becomes easier, and delivery time is shortened.

These ideas aren't new; many people have espoused the value of reuse for decades. For that matter, tool/platform offerings aimed at being an application factory have been available; Lotus Notes might be one of the most well-known such efforts.

To be fair, since implementing an application factory is ultimately about corporate culture, an organization could theoretically accomplish it while wielding any set of code-based or low-code tools. In practice, however, the right kind of platform helps in several ways:

■ First, if it provides a number of services built into its platform, those services don't need to be created from scratch. For example, a common approach to auditing is a worthy goal, but it's harder to get there if you have to build it yourself; the temptation to build a limited auditing facility for just one application is strong, and frequently the creation of a common auditing becomes postponed over and over again.

■ By shaping the way deployment, telemetry, auditing, documentation, task management, etc. are done, the odds of individual apps "going rogue" are greatly reduced.

■ If platforms designed with an application factory approach in mind provide tools for design and feedback, and gear those tools for non-professionals.

As for whether the time is ripe for promoting and adopting application factory thinking, we are admittedly early in the adoption curve. Early adopters are already very much on board, and according to surveys WEBCON has commissioned in both Germany and the United States, the trend is taking shape on both sides of the Atlantic. 99% of American CIOs stated that delivering multiple applications was one of their biggest challenges, so the time is ripe for a better idea.

Whether or not the application factory approach has a better chance of addressing that first list of fundamental challenges, I'm hoping we can return to that list with all possible haste, because low-code hasn't magically solved them — nor will AI do so, either. Digital transformation is a matter of cultural transformation — it always was, and always will be.