Fallacy4

Avoid this Systems Development Mistake

Avoid this Systems Development Mistake

Posted on: May 10, 2021


"Don't fall into the trap of over-simplification just to get a software product out the door. Simplify the user interface and the business logic, but don't simplify your data model in a way that requires endless cycles of deep refactoring."

Have you seen this situation? The initial product looks promising, then ...

Many times, I've seen the development of systems within the credit origination domain take a familiar unfortunate path. In an effort to quickly stand up a system that can demonstrate tangible results, many simplifying assumptions are made. An initial product is successfully rolled out, only for the system to fail to evolve sufficiently to succeed.

Often the initial product is limited to a single, straightforward mortgage on a single property, to only single or married/de-facto PAYG applicants, which is a common approach. Whilst this may work to enable the simplest scenario to be delivered quickly, the way in which these assumptions are applied can dramatically hinder the future extension to more complex scenarios.

Don't ignore the 'Viable' in MVP

This approach is often aligned to agile methodologies and the idea of building a 'Minimum Viable Product'. The 'Viable' term needs to be considered not just in the terms of what business functionality can be put in front of a user to obtain feedback. It also needs to consider what type of changes can easily be incorporated in the future. If I can't easily incorporate more complex scenarios in the future, just how viable is my minimum viable product?

Rapidly evolving an entire system where there is already live data in the database is extremely complicated. This is accentuated in the mortgage world where a mortgage application can be actively in progress for many months. Evolving a UI and business logic in isolation is relatively easy. When significant changes to the structure of the underlying database are required (whilst supporting all existing data at various stages of the workflow) it becomes extremely difficult.

A minimum viable product (MVP) is a concept taken from various agile methodologies that describes a product has just enough features to learn about the viability of the product. It is a key concept in enabling the product to evolve by receiving rapid user feedback and iterating to improve the product.

LIXI2 increases the long term viability of evolving a system

This is where the LIXI2 data standards can help enormously. LIXI has spent the last 20 years gathering an extraordinarily comprehensive set of requirements from the Lending Industry and used them to build a data model for electronic messaging throughout lending. We have coordinated a huge group of collaborators to contribute and discuss requirements, suggest solutions, test and validate those requirements and solutions and finally implement the changes in production systems. The standards cover a huge array of credit and deposit products, borrower types (personal, sole traders, partnerships, companies, trusts) and other complicating factors (guarantors, beneficiaries, financial positions, employment types etc.).

A number of members have used the LIXI domain model (covering all our standards) to implement an underlying data model that supports the comprehensive landscape of use-cases out of the box. It's trivially easy to switch off the complex cases on day one, and switch them back on at a later date. This can avoid the bulk of the complex refactoring work associated with evolving the data model at the core of an existing system.

Don't fall into the trap of over-simplification just to get a software product out the door. Simplify the front end (the user journey, the application forms etc.) but don't simplify your data model in a way that requires endless cycles of deep refactoring. If you want to discuss how LIXI2 might benefit your lending system, feel free to get in touch.

Related Pages


Written by:
Shane Rigby, LIXI Limited CEO
First Published: May 10, 2021