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
Concerns	time constraints cost constraints required skill sets available resources budgets external dependencies
Activities	cost estimation development time estimation development planning dependency management scoping prototyping expectation management
Tactics	incremental and iterative development expectation management descoping prototyping and piloting fitness for purpose
Pitfalls	Overly ambitious timescales failure to consider lead times failure to consider physical constraints underbudgeting failure to provide staff training and consider familiarization needs insufficient resource allocation for testing and rollout insufficient time for likely rework overallocation of staff difficulty getting access to knowledgeable business stakeholders