Development Resource Perspective

In this context, 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

find out more about the Development Resource perspective ...