Application Shelf Life and Technology Expiry Dates

Most organizations use forms-based custom software applications that have hard-coded the business functionality. These applications are implemented on a set of specific technologies: source code in one (or more) languages, public and private software libraries, operating systems, databases, cloud services etc. All of these technologies have a shelf life and will expire. When they pass their expiry date, you can choose to continue to operate your application at some level of risk, or redevelop your application using a newer technology. As you can imagine, this is an ongoing process and given the increasing rate of change of technology, a more frequently occurring and expensive problem.

The root cause of this problem is that we hard code the business functionality into our software applications making them dependent upon the technology we use to implement them.

Most of the code (>90%) in our application simply moves data between the user’s screen and the underlying data storage. It is possible to virtualize these requirements from into a set of configuration data that can be used to render the desired user experience directly. This approach has many obvious benefits: cheaper, faster, and safer application development; reducing the need for applications; simplifying enterprise architecture; and reducing the sources of technical debt.

We have also broken the dependency between the application and the technology that implements it.

To render the user experience on a device from configuration data, we need to have an “interpreter” application. Each different device may need its own interpreter, but all can use the same configuration data source and display the equivalent user experience with the same business functionality.

Over time, as new devices become available its simply a matter of building a new interpreter.

The build up of technical debt and shadow IT causes additional business costs and risks

Over time, business requirements change and new ways of optimizing business operations arise. Frequently our applications can’t keep up with the rate of change required by the business. Simple application changes can take 3-6 months to implement and so we start to see multiple band-aid patches being applied and the build up of technical debt. As technical debt builds up it becomes ever more difficult and risky to make changes to the application.

This creates an increasingly wide gap between what the application does and what the business needs. The aging application anchors the business to the past, preventing the rollout of new products and services, enforcing older and less efficient ways of operating.

Business users respond by adopting shadow IT solutions that exist outside of the control of formal IT. Common examples include: spreadsheets, local databases, SaaS applications etc. This introduction a new set of challenges and risks for the business as well as increasing operational costs by creating manual workarounds and duplicate data entry.

At some point, the gap between application and business needs grows to the point where a re-write is required. Not only must the legacy application now be modernized but the associated shadow IT should also be refactored and absorbed.

How do we go removing the expiry date on our applications?

A good place to start is to adopt a requirements virtualization platform that enables us to go directly from requirements to application without all that tedious mucking about with large software development projects.

This approach works because the vast majority of the code in our business applications moves data from a database and renders it on a screen for a user. All of this can be replaced by a few framework services that use the requirements configuration data to render an application user experience.

1. Data Agnostic Storage Service (DASS) that can securely store any data at the platform level. Data is no longer stored in silos associated with applications – it can be directly accessed by any authenticated user through any application or service.

2. A set of Dynamic Page Builders that can render any custom user experience on any device in real-time depending upon the role and access rights of the user. All data is stored in the DASS, including a set of requirements configuration data that describes how each page should be rendered.

3. A UX Creator application that is hosted in the requirements virtualization platform that is used by business analysts, or citizen developers, to configure the business requirements.

Virtualizing the user experience and CRUD requirements decouples much of our application code from the technology that implements it. This breaks the rinse/repeat cycle of re-writing our applications every time technology evolves.

If new technology becomes available, it is possible to rewrite just the dynamic page builder component without having to re-implement the form definition data model. This enables your business to rapidly realize the benefits of innovative technology without incurring the cost of significant rewrites.

The fact that the user experience requirements are defined in data means that it is also easy to evolve your application over time as your business needs change. This eliminates a major source of technical debt as the requirements configuration changes immediately updates the application user experience. There is no band-aid code being added to your application, so no technical debt is being created.

Like to learn more?

If you would like to schedule a virtual meeting or learn more about trellispark, please contact us and provide a brief description of your interest. Or simply drop us an email at