The Straf Model

If you work in the area of designing an enterprise class application, use the following model before to document the characteristics of the system. The model can be remembered as the STRAF model.

Before you put a disk in a machine, consider the following:
Security - How will the security of the application be considered. Analyze all of the audit requirements ahead of time to make sure you capture them in the system. Make sure on day 1, the system meets these requirements. Too often systems are audited later on to discover that they do not meet the security requirements and whole changes are necessary. Make sure their are no shared accounts and the system uses complex passwords for the logons.

Transactions - Before you buy the hardware, analyze how many transactions you expect the system to process at the peak load. Purchase hardware that you will grow into, this includes the CPU characteristics along with the storage

Reporting / Remote Management - Consider how the system will report it's availability and other metrics, including capacity planning. Will it feed to something as simple as Hobbitt or more advanced like HP Open View? The reporting should include every measurable component including the power consumption on the circuit.
The system should also have the capability to be remotely managed. This includes use of the devices such as the Dell Remote Access Card, IBM Remote Supervisor or HP ILO. Don't scrimp and fail to get remote manageability. For other devices such as routers, consider a console server.

Automated - The system you design should take into consideration how the components will continue to work automatically if they fail. For example, if you are designing a VMWare system, then buy the VMotion component so the images automatically fail to another node if need be. In designing storage, make sure a hot swap disk is automatically inserted into the Raid group if necessary.

Failover - Design systems so that they will failover within themselves and remotely. Make sure redundant power is in the server along with other components, such as generator availability. Furthermore, the entire system and/or application should automatically fail over to another site in case of a disaster. Use DoubleTake for Exchange replication and Data Guard for Oracle situations.
One of the key characterisics of fail over is to get the phone system to automatically fail over as well. Consider the VOIP alternative open source solutions such as Asterisk and repoint your 800# to it.

Following the STRAF model would help people design systems that keep their business operational during periods of maintenance and prepare for disaster.

If you can take it a step further, design the system so that both sites can take transaction volume and avoid the cost of 50% of your assets sitting there doing nothing.