ContentsApplication DesignDesign parametersLife

Previous: Operational | Next: Thin pipes

We've all made mistakes. Most of us want to stop making them. The pain of our technological mistakes often come back to haunt us when we are in the middle of something. Lifecycle design parameters are usually not considered until too late.

Most of us know of certain mainframe applications that just keep on living. From a business perspective, that's a really good thing. Our applications should be built with that kind of resiliency and dependability. Using fat-client technology, this ideal is almost impossible; but it is very achievable for web clients.

By avoiding the deployment requirements of fat client applications, we can replace nearly any component in our system with a better implementation at any time. This is the primary advantage of the architecture we've chosen.

Still, there are some lifecycle design parameters that must be considered:

• how will the application be tested and released?
• is any documentation or training required?
• how will end users find the application (e.g. a link from a site page)?
• will the URL need to change as the result of maintenance?
• when will new features be incorporated?
• what are the maintenance procedures?
• how will this application be decommissioned or replaced?

A general (but seldom acknowledged) lifecycle rule is: if the need for the application is great enough, users will work around any shortcoming. As is often the case, if your application doesn't show promise quickly, users will often abandon your help and do the work with a spreadsheet.

An old adage that helps here is "don't walk over dollars while looking for pennies" - don't delay getting something into the users hands while you are trying to resolve these issues. Get something working, but don't forget to address these (and other) nonfunctional parameters before moving on to other projects.

ContentsApplication DesignDesign parametersLife

Previous: Operational | Next: Thin pipes