Before delving into the details of architectures that can help with rapid development, let's establish exactly what is meant by the terms architecture and design.
Asking this question often stirs up considerable debate among IT professionals, especially architects. Many working hours have been lost as software engineers split hairs over the differences between the roles of the architect and designer. In the interests of productivity, and for the purposes of this discussion, architecture can thought of as the big picture.
It's helpful to think of architecture as the blueprint for building the system. In this way, architecture forms an overarching set of principles, standards, protocols, frameworks, and directives that orchestrate the various design elements of the overall application.
Architecture differs from design in terms of scope. Architecture takes the wider view; design has a much narrower focus. Put simply, architecture has breadth and design has depth. The architect paints with a wide brush; the designer is more focused and concentrates on adding detail to the picture.
Architecture is important for rapid development because it forms the basis for large-scale software reuse. Considering the wider picture enables the identification of readily reusable components for quickly assembling a system. System architectures are themselves a reusable commodity, as architectures tailored to specific problem domains can form part of a company's adaptive foundation.
The following list is not exhaustive but identifies those system traits the architecture would typically include:
The timeframe available in which to deliver the system is an important factor when defining the system's architecture and warrants equal consideration with other architectural concerns, such as system performance, scalability, robustness, security, and maintainability.
The priority timeliness is given should be set by the customers, and that priority must be respected by architect and designer alike. A common failing in the IT industry is to overengineer solutions, thereby risking missed delivery dates. The time to develop a solution can be of paramount importance to the customer. A drop-dead date for a system could be just thatany later and the customer might be out of business.
Though the architect must consider all customer requirements, the architect also has a responsibility to advise the customer on the potential implications for the system if architectural compromises prove necessary to achieve a short-term delivery date.