A commonly known rule of thumb in software engineering, which seems to hold well for systems of record (SOR), is that maintaining software comprises between 60 to 80 percent of the total cost of ownership. [This same rule might well apply for the systems of engagement (SOE) that persist more than a few years before they are cast aside for the next shiny user experience.] Developers bemoan, “old systems never die.” Rather, they become systems that need to be maintained – hence the ever-increasing cost to maintain them.
While software can run for a long time without ever needing to be modified, as it gets older it can become less useful because the context for which it’s used changes. It’s easy to mistake maintenance for bug fixing when the bulk of maintenance cost is actually made up of additions or enhancements to the application’s functionality.
So, what makes up software maintenance?
- Fixing software problems (bugs) discovered once the software is put into production.
- Modifying software to keep it working in a changing business and IT environment.
- Perfecting software to improve overall performance.
- Enhancing software to add new features and new innovation.
If the aforementioned rule of thumb holds true, then streamlining any and all of these four items can yield substantial benefits. Trying to build a “perfect” app that requires less (or no) maintenance is just not practical.
Much as we may try, version one of any application will never be the final version and we should plan for that to be so. As we delve into the business processes represented in our SORs and the SOEs used to drive them, new ideas for app functionality will surface. In addition, encouraging user feedback always provides ideas for new and improved functionality and has the added benefit of significantly helping user adoption. Building version 1 while at the same time, drafting ideas for versions 1.1, 1.2 and 2.0 etc. is the best approach.
In LANSA, we set great store by our Business Rules Engine. The Rules Engine’s repository stores definitions, rules and visualisations in a central location, externalising them from being hard-coded into apps themselves and providing a single place to maintain them. As a result, every application and new version benefits from the Rules Engine because it eliminates duplication and eases testing. The Rules Engine is so easy to setup and maintain that even non-developers (business analysts) can define a rule once, knowing it will be enforced everywhere.
The Rules Engine makes it considerably easier to:
- Implement change requests.
- Stay in sync with the changing business environment.
- Simplify the addition of new application functionality.
- Onboard new developers to take on the maintenance task.
Taken together, this dramatically shrinks the maintenance burden of an app as you move from one version of an app to the next. LANSA customers report between 50-80% reduction in their application maintenance effort and costs as a result. Inherent in this savings is the speed at which changes can be applied, have them ripple through all relevant apps and the reduction of effort to test everything. Cheaper, faster and better – it’s a compelling combination.
The Rules Engine is just another example of how the LANSA low-code development platform lowers the cost, time-to-market and maintenance of not just version one of a new piece of software, but every subsequent version too.
