Software architecture

Core elements and characteristics

An architecture typically describes components (modules, services, layers), interfaces, data flows, and deployment venues. It also addresses nonfunctional requirements — sometimes called quality attributes — that guide choices: for example, whether the system must prioritize low latency, easy evolution, high availability, or strict security. Good architecture communicates intent to developers, operations teams, and stakeholders and provides a basis for estimating risk and cost.

Common architectural styles

Architectural style names group recurring patterns of organization and interaction. Typical styles include:

• Layered (n-tier) — separation by responsibility such as presentation, business logic, and data storage.
• Client–server and distributed — components run on different machines with well-defined protocols.
• Service-oriented and microservices — systems built from small, independently deployable services.
• Event-driven and message-based — components communicate by events or messages, supporting loose coupling and asynchronous processing.
• Model–view–controller (MVC) — common in interactive applications to separate concerns.

Documentation, views, and evaluation

Architectures are documented with multiple views to address different stakeholder concerns: logical views for functional structure, development views for module organization, process views for runtime behavior, physical views for deployment, and scenario-based descriptions for key use cases. Structured evaluation methods examine whether an architecture meets requirements and where risks lie; architecture reviews aim to expose trade-offs and potential changes before implementation.

Importance, history, and practical effects

The notion of software architecture emerged as systems grew larger and more complex. Treating architecture as a first-class activity helps teams control complexity and manage long-term evolution. Because architecture decisions are broad and foundational, changing them late in a project can be costly. Conversely, a well-chosen architecture enables incremental development, clearer maintenance, and more predictable scaling.

Distinctions and notable facts

Software architecture differs from low-level design and implementation: it focuses on coarse-grained structure and critical decisions rather than code-level algorithms. Architects balance competing goals and communicate constraints to developers and managers. For practical guidance and further reading, see additional resources.