In short
Software architecture describes the fundamental structure of a software system: what building blocks it consists of, how they work together and according to which principles it is designed and further developed. It comprises the decisions that can only be changed later with great effort.
In its 2011 version, the standard ISO/IEC/IEEE 42010 defines architecture as the fundamental concepts or properties of a system in its environment, embodied in its elements, their relationships and the principles of its design and evolution.
The decisive point is that architecture is not a diagram but a collection of reasoned decisions. The diagram only makes them visible. Anyone who wants to have software developed should know these decisions, because they determine costs, pace and maintainability for years.
What software architecture is for
Features can be built in almost any structure. The architecture decides how well the system meets the quality requirements laid down in the requirements analysis: performance under load, security, availability, maintainability and extensibility. The standard ISO/IEC 25010 summarises these characteristics in a quality model.
- Managing complexity: clear building blocks with clear boundaries make it possible to understand a large system in parts.
- Decoupling teams: several teams can work in parallel if the interfaces between their areas are stable.
- Enabling change: good architecture keeps flexible the parts that are likely to change, such as payment providers or user interfaces.
- Making risks visible early: bottlenecks, single points of failure and dependencies on third-party systems are recognised before they become noticeable in operation.
Every architectural decision is a compromise. More distribution brings independent scaling, but also network errors and more complex operation. More abstraction brings interchangeability, but also more code. The task of architecture is to make these trade-offs consciously and traceably.
Well-known architecture patterns
Architecture patterns are proven solutions to recurring structural problems. Most real systems combine several of them.
| Pattern | Core idea | Fits well when | The price |
|---|---|---|---|
| Layered architecture | Presentation, business logic and data access are in separate layers; each uses only the ones below it | Classic business applications with manageable business logic | Business changes often run through all layers |
| Modular monolith | One deployable application, divided internally into business modules with clear interfaces | One team or a few teams, business boundaries still in flux | Module boundaries need discipline, otherwise an unstructured monolith emerges |
| Microservices | Many small services with clear business boundaries that are deployed separately | Several teams, very different load per business area | Distributed failures, data consistency and operation become much more complex |
| Event-driven | Building blocks react to events ("order created") instead of calling each other directly | Many systems have to react to the same processes, loose coupling is important | Processes are harder to trace and test |
| Hexagonal (ports and adapters) | The business logic is at the centre; database, APIs and user interfaces dock on via adapters | Long-lived business logic, infrastructure should remain interchangeable and testable | More interfaces and mapping code |
The microservices architecture is not a mark of quality in itself. For many mid-sized projects, a modular monolith is the better choice because it offers business separation without the operating effort of distributed systems. Where business boundaries run is clarified by domain-driven design with the concept of the bounded context. Hexagonal architecture goes back to Alistair Cockburn; related approaches are the onion architecture and clean architecture.
Software architecture vs system architecture
The terms overlap but have a different scope. System architecture looks at the overall system: software, hardware, networks, infrastructure and the connections to other systems. Software architecture looks at the internal structure of the software itself. Alongside them are the finer-grained software design and the overarching enterprise architecture.
| Level | Looks at | Typical questions |
|---|---|---|
| Enterprise architecture | Business processes, application landscape, data and IT of the whole company | Which system is the master for customer data? Where are there duplications? |
| System architecture | An overall system of software, hardware, network and operation | Which servers, cloud services and interfaces are there? How does data flow between shop, ERP and PIM? |
| Software architecture | Structure of an application | Which modules are there, how do they communicate, where is the business logic? |
| Software design | Classes, functions and data structures within a module | How is this building block structured internally? |
In practice, the levels are closely connected: whether a service can scale separately in the cloud is a question of system architecture, but it presupposes a software architecture that separates this service in the first place. How we plan both levels together is described in our service system architecture and design.
Example: architecture of a B2B ordering platform
A retailer wants to build a customer portal in which business customers order at their own prices. Prices, stock and customer accounts are in the ERP, product data in the PIM. A possible software architecture:
- Modular monolith as the core: modules for catalogue, prices, basket, orders and customer accounts with clear internal interfaces. One team can develop everything further in one code base.
- Hexagonal structure of the business logic: the pricing logic does not know the ERP directly, only a "price port". An adapter translates to the ERP interface. If the ERP is replaced later, the business logic remains unchanged.
- Events for integration: a confirmed order creates the event "order created". ERP export, confirmation email and statistics react to it independently. If the ERP is briefly unavailable, no orders are lost, because the events wait in a queue.
- Targeted separation: only the product search, which carries significantly more load than the rest, runs as a separate service. Everything else stays in the monolith.
The example shows the basic rule: patterns are chosen according to requirements, not fashion. A pure microservice landscape would have created more operating effort here without solving a concrete problem.
Documenting and deciding on architecture
ISO/IEC/IEEE 42010 describes how an architecture description is structured: it is addressed to stakeholders with particular concerns and shows the system in different views. Tools widely used in practice:
- arc42: a structure template for architecture documentation by Gernot Starke and Peter Hruschka, widely used in German-speaking countries.
- C4 model: four zoom levels from context through containers and components to code, developed by Simon Brown.
- Architecture decision records (ADR): short notes per decision with context, decision and consequences. Years later, they answer the question of why something was built the way it was.
Architecture is also never finished. Systems grow, requirements change, and without care the structure erodes. Regular refactoring keeps it healthy. If the structure has already been lost, the system quickly becomes legacy software, whose modernisation costs significantly more than ongoing care. Conway's law (Melvin Conway, 1968) is also a reminder that systems mirror the communication structures of the organisation that builds them. Architecture and team structure therefore belong together.
FAQ on software architecture
What is meant by software architecture?
Software architecture is the fundamental structure of a software system: its building blocks, their relationships and the principles according to which it is designed and further developed. Above all, it comprises the decisions that are hard to change later.
What architecture patterns are there?
Widely used are the layered architecture, the modular monolith, microservices, event-driven architecture, hexagonal architecture (ports and adapters), client-server and pipes and filters. Real systems usually combine several patterns.
What is the difference between software architecture and system architecture?
System architecture describes an overall system of software, hardware, network and operation as well as its connections to other systems. Software architecture describes the internal structure of the software itself, i.e. modules, interfaces and the distribution of the business logic.
What does a software architect do?
A software architect derives the structure of a system from requirements, weighs up alternatives, documents decisions and makes sure that the implementation does not undermine the structure. In smaller teams, experienced developers take on this role as well.
When should you decide on the architecture?
The fundamental decisions, such as monolith or distributed services, data storage and integration route, belong at the beginning, as soon as the most important quality requirements are known. Details can and should be decided later, when more knowledge is available. Agile projects need this framework too.
Further reading: which architecture has proven itself for back ends and APIs is shown in our article on enterprise back-end architecture and API design.