Scenario
Currently, I am apart of a health care project whose main requirement is to capture data with unknown attributes using user generated forms by health care providers. The second requirement is that data integrity is key and that the application will be used for 40+ years. We are currently migrating the client's data from the past 40 years from various sources (Paper, Excel, Access, etc…) to the database. Future requirements are:
- Workflow management of forms
- Schedule management of forms
- Security/Role based management
- Reporting engine
- Mobile/Tablet support
Situation
Only 6 months in, the current (contracted) architect/senior programmer has taken the "fast" approach and has designed a poor system. The database is not normalized, the code is coupled, the tiers have no dedicated purpose and data is starting to go missing since he has designed some beans to perform "deletes" on the database. The code base is extremely bloated and there are jobs just to synchronize data since the database is not normalized. His approach has been to rely on backup jobs to restore missing data and doesn't seem to believe in re-factoring.
Having presented my findings to the PM, the architect will be removed when his contract ends. I have been given the task to re-architect this application. My team consists of me and one junior programmer. We have no other resources. We have been granted a 6-month requirement freeze in which we can focus on re-building this system.
I suggested using a CMS system like Drupal, but for policy reasons at the client's organization, the system must be built from scratch.
This is the first time that I will be designing a system with a 40+ lifespan. I have only worked on projects with 3-5 year lifespans, so this situation is very new, yet exciting.
Questions
- What design considerations will make the system more "future proof"?
- What questions should be asked to the client/PM to make the system more "future proof"?
Best Answer
Data is King
I think its a bit unreasonable to expect a web application circa 2013 to be still up and runnable in 2053. Technologies are going to change. Platforms are going to come and go. HTML may be a quaint memory by then. But your data will still be around.
So data is your primary focus. As long as your data is still there, people will be able to adapt to whatever new technologies come about. Make sure your data schemes are well thought out, and well suitable for expansion. Take your time spec'ing them out.
Regarding the actual applications, your company is probably correct here in having a 'build from scratch' directive. I maintain a couple 10+ year old web apps, and I'm very glad they are not locked into the prevailing CMS systems of 2003. They use home grown, very simple frameworks. I think for something like this you are better off with a very basic framework that you create specficially for the needs of the project.
But the reality is, over 40 years, the company will (hopefully) be making quite a few front-end and back end services to adapt to evolving platforms. So given that, I'd target a 5-10 year lifetime for individual user-facing applications.