Software Architecture is the high-level organisation of a software system, including its major components, their responsibilities, interactions, constraints and important quality attributes. Architecture concerns decisions that have broad and often long-lasting consequences, such as decomposition into components, communication mechanisms, data ownership, deployment boundaries, dependency direction, security boundaries and resilience strategies. Architecture is not simply a diagram or a list of technologies. It encompasses the significant structures and decisions that shape how a system behaves and evolves. Architectural concerns exist at different scales, from the organisation of an application to the interaction of multiple independently deployed systems.
Software Architecture addresses both functional and non-functional concerns. Functional concerns describe capabilities the system must provide, while non-functional concerns include performance, availability, scalability, security, maintainability, interoperability, observability and operational cost. Architectural decisions often involve trade-offs because improving one quality attribute can negatively affect another. For example, distributing components may enable independent scaling and deployment but introduce network latency, failure modes and operational complexity. Architecture therefore cannot be evaluated meaningfully without considering requirements, constraints, expected workload and organisational context. An architecture suitable for a small internal application may be inappropriate for a globally distributed platform, and the reverse can also be true.
Architectural styles and patterns provide recurring ways of organising software. Examples include layered architecture, client-server architecture, event-driven architecture, hexagonal architecture, pipe-and-filter structures, microservices and service-oriented approaches. These terms describe patterns of organisation rather than universal prescriptions. A layered design may separate presentation, application logic and persistence, while an event-driven design allows components to communicate through events rather than direct synchronous calls. Architectural patterns provide vocabulary and proven trade-offs, but applying them mechanically can create unnecessary complexity. The correct architectural structure depends on the problem being solved, the required qualities and the constraints of the environment.
Software Architecture includes explicit and implicit decisions. Explicit decisions may be documented in architecture decision records, diagrams, interface definitions or deployment specifications. Implicit decisions appear in code dependencies, data ownership, communication patterns and operational procedures even when nobody has formally documented them. Architecture can therefore drift as implementation changes gradually diverge from the intended structure. Architecture governance may use automated dependency checks, design reviews, ownership rules and documentation to limit undesirable drift. Architectural documentation is most useful when it records decisions, constraints and rationale rather than merely reproducing diagrams that can quickly become outdated.
Architectural boundaries determine how changes propagate through a system. Strong boundaries can isolate failures and allow components to evolve independently, while excessive fragmentation can introduce communication and coordination costs. Coupling describes the degree to which components depend on one another, while cohesion concerns whether responsibilities within a component naturally belong together. Good architecture often seeks appropriate cohesion and controlled coupling rather than absolute elimination of dependencies. Data ownership is another major architectural concern because shared mutable databases can create hidden coupling between otherwise separate components. Interface contracts can make dependencies explicit and manageable.
Software Architecture has a strong relationship with deployment and operations. An architecture involving independently deployed components requires mechanisms for service discovery, configuration, monitoring, logging, security and failure handling. Architectural choices also affect infrastructure costs and operational responsibilities. Cloud platforms have made infrastructure components more accessible, but they have not removed architectural trade-offs. A system can be technically distributed while still being operationally centralised or tightly coupled. Conversely, a modular application can provide strong boundaries without requiring separate deployment units. Architecture should therefore be evaluated by its actual properties rather than by labels alone.
Architectural change is often constrained by existing dependencies and migration requirements. A system may need to evolve incrementally because replacing its architecture in one operation is risky or impractical. Techniques such as strangler-style migration, anti-corruption boundaries, compatibility interfaces and incremental data migration can support gradual architectural change. Architecture also interacts with organisational structure because teams need clear ownership and communication paths for independently maintained components. Conway's Law is frequently discussed in this context, although it is an observation about relationships between organisational communication structures and system design rather than a deterministic engineering law.
Common misconceptions include treating architecture as something decided once at project inception or assuming that a particular style is inherently superior. In reality, architecture evolves as requirements, scale, threats, technology and organisational constraints change. Another misconception is that architecture is synonymous with infrastructure or technology selection. Technology choices matter, but architecture also encompasses responsibilities, boundaries, dependencies, contracts and quality attributes. Effective Software Architecture makes important trade-offs explicit, provides structures that support required behaviours and quality attributes, and leaves sufficient flexibility for foreseeable change without introducing unnecessary complexity.
