Architecture and Design Objectives

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.

The Architect

The ideal architect should be a person of letters, a mathematician, familiar with historical studies, a diligent student of philosophy, acquainted with music, not ignorant of medicine, learned in the responses of jurisconsults, familiar with astronomy and astronomical calculations.

From Vitruvius, circa 25 BC

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:

Performance.

For a given load, will the application meet the performance levels detailed by the system's technical requirements? For example, will the system provide a two-second response time for a specific user action under maximum load?

Scalability.

Can the capacity of the system to undertake higher loads be increased without the need to change the code?

Robustness.

Is the system fault-tolerant and able to comply with the levels of availability defined in the customer's technical requirements?

Maintainability.

Is it easy for developers to correct any defects that surface or to add new functionality?

Manageability.

How easy is it for IT operators to manage the operational needs of the system in a production environment?

Security.

Given the nature of the information maintained by the system, is the level of security sufficient?

Customer standards.

Does the system conform to the customer's own architectural standards and principles?

Timeliness.

Can the solution be delivered in the timeframe available?

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.

Warning

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.