In Findur, every “D’oh!” moment begins as a clever idea. Over-customisation, hidden logic, and forgotten user tables turn smart solutions into technical debt. This paper shows how to reduce technical debt in Findur.
“Well, it was like that when I got here. It really was!”
Many Openlink Findur implementations start with good intentions but end up burdened with complex customisations, sprawling user tables, and plugins that are difficult to maintain. Each new enhancement becomes harder to deliver, each upgrade becomes riskier, and small operational changes require disproportionate development effort.
McKinsey reported up to 20% of costs go into resolving issues related to technical debt. The best way to address tech debt is to design solutions that minimise it up front. This white paper, in our series on reducing technical debt in Findur, outlines a practical design philosophy for building supportable solutions within Findur. It proposes a configuration-first mindset, reducing reliance on custom code, and prioritising long-term maintainability.
“To user tables! The cause of, and solution to, all of life’s problems”
Findur is a powerful system with extensive flexibility. However, this flexibility can lead to over-customisation when developers use that power too freely. Plugins written in JVS or OpenComponents often contain intricate business logic. User tables are used as makeshift data stores for configuration, proliferating unchecked and often undocumented.
The immediate consequence is technical debt in Findur. Every custom plugin or user table becomes an artefact that must be understood, tested, and maintained during upgrades. Even small changes to business processes can trigger wide-ranging code revisions, causing unnecessary delays and operational risk.
The deeper issue is that these solutions are sometimes designed with the developer’s convenience in mind rather than the future user or support analyst. A well-intentioned piece of code may deliver today’s requirement but leave tomorrow’s users dependent on scarce developer knowledge. When the person maintaining the system six months later cannot easily see how to adjust a rule or workflow, the design has already failed the principle of supportability.
“Why do my actions have consequences?”
The core principle is simple: whenever designing a solution in Findur, imagine the user who will perform the action, troubleshoot the process, or support the change in the future. A supportable design is one that enables that person to adapt and maintain the solution without deep technical intervention.
D’oh!
Can this requirement be met using standard configuration? Findur provides a wealth of configurable functionality that should be the first approach. Use core or custom fields that can be maintained through the GUI rather than user tables. Avoid embedding complex branching logic in plugins when the same result can be achieved with parameterised rules.
When custom code is genuinely necessary, it should be as lightweight and generic as possible. Business logic should be externalised to configurable sources, parameters, or data-driven tables. Code should be modular, reusable, and clearly annotated to explain its purpose and dependencies.
Ay Caramba!
Solutions should be designed so that non-technical users can make small, safe adjustments. This may include maintaining lookup values, changing thresholds, or re-routing a workflow. Using custom fields or parameter tables that are visible and editable in the GUI gives control back to the business and support teams.
Trade Process Manager (TPM) workflows are an excellent example of an in-system, user-maintainable capability. A simple, well-annotated workflow that triggers a straightforward activity is far more supportable than a hidden plugin performing multiple conditional actions. Keeping logic visible in the system’s standard interface makes it easier for end users to understand, operate, and adapt as processes evolve.
Excellent
Every design should anticipate change. Ask how many artefacts would need to be altered to implement a small adjustment to the requirement. If the answer includes several plugins, multiple user tables, and additional code deployment steps, there is likely a simpler approach.
Evaluate each parameter to determine where it should be maintained. Ideally, you want to expose parameters, thresholds, and mappings in data objects that can be modified independently of the code. That said, do not create a new info field or user table to expose a single parameter that likely will never change. A good litmus test is whether a business analyst or support specialist should make a controlled change through configuration alone.
“No, no honey, I love everything you force me to do.”
Here are some simple tips for designing enhancements to reduce technical debt in Findur:
- Use core or extended fields to capture additional attributes instead of creating new user tables.
- Leverage TPM workflows for approvals, exception handling, or process routing rather than scripting custom workflow logic.
- Keep logic in code generic and refer to user tables for data-driven mappings only for more complex requirements.
- Where user tables are necessary, ensure they are versioned (using a last_update column and user table history functionality).
“Your ideas are intriguing to me, and I wish to subscribe to your newsletter.”
Lucido works with clients to design and deliver supportable Findur solutions that minimise long-term maintenance requirements. Our approach begins with assessing your existing customisation landscape, identifying areas where configuration can replace code, and developing a roadmap for reducing technical debt in Findur.
Our delivery model focuses on configuration-first designs, ensuring that future maintenance can be handled within the system’s standard GUI rather than through repeated code changes. If your organisation wants to simplify its Findur landscape, reduce upgrade risk, and empower users to maintain their own solutions, Lucido can help. Reach out to discuss how we can make your implementation more supportable.