The Development Resource Perspective
A development resource may be a person, a piece of hardware or software, a building, a timescale, or money. (Note that runtime computing resources are a slightly different topic, which we discuss as part of the Performance and Scalability perspective.)
All software projects are primarily constrained by time and cost. IT budgets are never unlimited, and although technology capabilities improve from year to year, so do the costs of building, deployment, and support. Today’s rapidly changing business environments impose substantial pressures to deliver flexible systems ever more quickly. There may even be immovable timescale constraints, such as the arrival of new legislation, new regulations, or a new millennium. (At least that last one is unlikely to recur for another thousand years or so!)
You may think it odd or inappropriate that an architect should get involved in things like time and money. Certainly as an architect, none of these problems are directly yours to solve. However, they all impose constraints on your architectural choices. For example, if you have to wait a month before trained developers are available, you will have less time to build the system and less scope for incorporating complex features. If the budget will not stretch to a mainframe, there is little point in considering it as an architectural candidate. If the data center is full, a server farm is not an option unless space can be found elsewhere.
|Desired Quality||The ability of the system to be designed, built, deployed, and operated within known constraints related to people, budget, time, and materials|
|Applicability||Any system for which development time is limited, technical skills for development or operations are hard to find, or unusual or unfamiliar hardware or software is required|