News.cx
BREAKING NEWS Software architecture, explained through the decisions that last
Technology

Software architecture, explained through the decisions that last

Software architecture sets a system’s structure and quality trade-offs, giving teams a way to assess and revise consequential choices.

Maya Lindqvist

By Maya Lindqvist · Senior Technology Correspondent

3 min read

Software architecture is the set of design decisions about a system’s overall structure and behavior. According to Carnegie Mellon University’s Software Engineering Institute, it lets teams assess whether a system can achieve qualities such as modifiability, availability and security before implementation, integration or deployment.

Architecture is not limited to a one-time blueprint. The SEI describes practices of documenting the architecture, evaluating it against business or mission goals, and checking whether the deployed system conforms as it evolves.

What software architecture covers

An architecture can be described through a system’s elements, the relationships among them, and the properties of both, according to Wikipedia’s software-architecture overview. It also includes consequential design decisions and their rationale.

The term does not have a single settled definition. Martin Fowler describes it as the important aspects of a system’s internal design and presents shared understanding among expert developers as one way to view it.

Architecture is a trade-off process

The SEI says teams must identify, prioritize and manage trade-offs among architecturally significant qualities; failing to do so can lead to delays and costly rework. Architecture gives stakeholders a way to analyze those qualities while choices can still be changed.

Teams can document the elements and interrelationships intended to achieve key qualities, then evaluate the proposed architecture against their goals. The SEI recommends repeating that evaluation as the system changes.

Two common structural patterns

A layered architecture organizes an application into functional categories. In a vFunction example, a common three-layer arrangement includes presentation, application or business, and data or persistence layers; the vendor describes components as sending requests to components in the same or lower layers.

Microservices organize a single application as a suite of small services, each running in its own process and communicating through lightweight mechanisms, often an HTTP resource API, Fowler writes. The services are built around business capabilities and can be independently deployed.

Fowler also identifies costs: microservices increase distribution, can weaken consistency and require maturity in operational management. That makes them one architectural option with trade-offs, rather than a universal answer.

How teams keep architecture useful

  1. Identify the quality attributes and constraints that matter for the system.
  2. Choose a structure and behavior, and state the trade-offs involved.
  3. Document the architectural elements, their interrelationships and the rationale for consequential decisions.
  4. Evaluate the architecture against business or mission goals before implementation, integration or deployment.
  5. Reassess its fitness and check whether the deployed system conforms as the system evolves.

Frequently asked questions

When do microservices add complexity?

Martin Fowler writes that microservices increase distribution, can weaken consistency and require maturity in operational management. Those are trade-offs of the pattern.

How can a team tell whether its architecture still fits its goals?

The Software Engineering Institute recommends repeatedly evaluating an architecture’s fitness against business and mission goals and analyzing whether the deployed system conforms to the intended architecture.

Sources