If you have completed or are nearing the end of a software project, you may be wondering how to ensure that your application that will provide value for years to come.
When scoping a project it’s important to understand that the world is changing, and is changing in ways that we can neither predict nor control. For instance, the level of market penetration and ubiquity of touch interfaces is amazing today, but it would not have been intelligent to build for touch technology 5 years ago, because too many aspects were uncertain still. However, what you can do is build applications that are built to last so you don’t accrue technology debt as you are already paying it down. Below are a few of Entrance’s thoughts on ensuring a good application lifetime.
Quality of the Application
When we say that quality matters, we don’t just mean the stylistics of the code itself, like variable names, and spacing, etc. (though any good firm should have standards). The actual design of the application is what really matters to longevity. How loosely or tightly coupled the system is can have a big impact. Loosely coupled applications are usually more pliable and resilient to change, because they are componentized (ie broken down into interchangeable pieces) and isolated for separation of concerns. The aspect that draws the user interface isn’t the same as what drives the business logic, which isn’t the same piece that queries the database, emails the error reports etc. All of those activities are separated. Separation in this manner is done with a forward thought to the architecture needed to expand functionality in bits and pieces over time, and represents a strategic choice toward quality of application design.
Application Governance
If you see your application as an asset, you know that it needs regular evaluation as to whether its maintenance is up to speed and following best practices. Where it’s not, you need to consider whether it makes sense to update the component that is lagging. This should happen regularly. Of all the components of this application, look at your third party pieces, individual components, platforms, interfaces, loosely coupled services and workflows – these should all provide one seamless user experience. If it’s not then reconsider the moving pieces. It makes the most sense to assess and update the application to match the latest on a quarterly basis. Any good vendor should list 3rd party components in order to make those updates easy.
Recognize Technology Debt as a Deferred Cost
If you look back and realize that if you haven’t been updating your system or taking care of other maintenance items, then you’re accruing debt. So you should know that you are slowly building up an off-balance sheet liability that will have to be paid at some point. From a cost perspective it’s better to buy early than late, but if you look at risk analysis it gets a little more complicated. If you’re a large multi-National company, and you have to train 16,000 people, that training can cost more than software itself. So it takes a lot of investment to update. Make sure to consider both the short term factors of user impact and the long-term factors of scalability when determining the level of maintenance and continued investment you’re putting into your application.
In the end the best is to slowly keep the application young over time. Continually evaluate what’s coming next and watch for flags that a changing environment will require a big update.
If your software application is old and clunky, or just lacking basic maintenance, read more about software modernization here!