Software architecture is the set of structures and decisions that define how a system’s parts fit together, and it matters because those are the decisions hardest to change later. This software architecture guide defines the term and compares six architectural styles and common patterns, then shows how to choose and document an architecture.
Each section stands on its own, so you can jump to the part you need.
What is software architecture?
Software architecture is the fundamental structure of a software system, meaning its components and the relations between them, plus the rules that guide how it evolves. In a 2016 post, John Klein of the Software Engineering Institute (SEI) at Carnegie Mellon describes architecture as the structures needed to reason about a system, where each structure consists of elements and the relations among them, plus properties of both.
Definitions differ in emphasis, so no single software architecture definition satisfies everyone. The table compares four widely cited framings. The SEI and Fowler rows come from Klein’s 2016 post and Fowler’s 2003 article; the Perry and Wolf row comes from Wikipedia, and the ISO row comes from the arc42 page.
| Source | How it frames architecture | Emphasis |
| SEI (John Klein, 2016) | The structures needed to reason about a system: elements and the relations among them, plus their properties | Structure and analysis |
| Martin Fowler, citing Ralph Johnson (IEEE Software, 2003) | The shared understanding expert developers have of the system’s design, or “the important stuff” | People and importance |
| ISO/IEC/IEEE 42010 | The standard’s definition, as quoted on the arc42 page, refers to fundamental concepts or properties of an entity | Context and stakeholders |
| Perry and Wolf (1992) | A blueprint for the system, analogous to building architecture | Planning |
Two ideas run through all four framings: architecture is about structure, and it is about choices that are costly to reverse. Enterprise software architecture applies the same thinking across many systems and teams, which Martin Fowler’s software architecture guide covers separately.
Why is software architecture important?
Software architecture is important because it fixes the decisions that are most expensive to reverse and sets the limits for qualities such as availability and maintainability. Wikipedia’s summary of the field lists analysis before construction and communication among stakeholders among the benefits.
Fowler’s guide adds that poor internal design produces cruft that slows feature delivery, and that the payoff from good design shows up in weeks, not months.
Architecture also shapes teams. Conway’s Law says a group that designs a system produces a design that mirrors how its members communicate. Melvin Conway introduced the idea in 1967, and Wikipedia cites his paper “How Do Committees Invent?” as published in Datamation in April 1968.
A structure that ignores team boundaries tends to fight them, which is our judgment.
What is the difference between software architecture and software design?
Software architecture is the part of software design that is costly to change, and software design covers everything else. Wikipedia says architecture is design, but not all design is architectural.
Application design focuses on the processes and data that deliver functionality, while software architecture design focuses on the infrastructure those processes run in so that non-functional requirements such as scalability are met. Fowler adds that what counts as architectural depends on what the developers consider important, and that an architect’s key task is to reduce irreversibility.
Software design and architecture both happen inside every custom software development project, and the choices made first cost the most to undo. For the lifecycle around them, see what software development involves.
What are the types of software architecture?
No single standard defines three types of software architecture, which is our reading of the sources. Wikipedia groups architectures into monolithic and distributed, and this guide compares six styles within them.
Architectural styles in software engineering are families of architectures that share characteristics and constraints, according to the Azure Architecture Center. Styles do not require particular technologies, although some technologies suit certain styles better. The table compares six styles, and entries marked “our judgment” are not from a source.
| Style | Defining feature | Choose when | Main cost |
| Monolith | All application code ships as one deployable unit. A modular monolith keeps clear boundaries inside it | A small team on a domain that is still changing (our judgment) | Parts cannot deploy or scale on their own (our judgment) |
| Layered (N-tier) | Code is split into layers by responsibility, and a higher layer uses the layer below, not the reverse | Requirements are still evolving, or an existing application is migrating with minimal change | Changes ripple across layers, and a monolithic design blocks independent deployment |
| Client-server | A client requests services and a server provides them | Most web and mobile products, where thin front ends rely on shared back-end logic (our judgment) | The server becomes a shared dependency (our judgment) |
| Microservices | Small autonomous services, each built around one business capability, with its own codebase and data store | The domain is complex and fast-changing, and development and DevOps practices are mature | Data consistency across services and the operation of a distributed system add complexity |
| Event-driven | Producers emit events, channels carry them and consumers react in near real time | Several subsystems must react to the same events, or processing must be near real time | Delivery guarantees and event ordering need careful design, and data is only eventually consistent |
| Serverless | A provider runs the infrastructure, and code runs on demand and scales to zero | Workloads are spiky or mostly idle, since billing covers only the compute used | Cold starts add delay, and tracing one request across many functions is harder (our judgment) |
Sources for the table are the Azure Architecture Center (N-tier, microservices and event-driven pages) and AWS (serverless).
Microservices and serverless designs usually run on cloud platforms, which is the territory of cloud-native development.
What is a software architecture pattern?
A software architecture pattern is a reusable solution to a recurring system-level problem, and it is narrower than an architectural style. Wikipedia says architecture patterns work at a higher level of abstraction than design patterns.
The Azure Architecture Center’s pattern catalog, updated June 3, 2026, describes cloud design patterns as solutions to common distributed-system challenges. The table summarizes six of them.
| Pattern | What it solves |
| Circuit breaker | Handles faults that take a variable time to resolve when an application calls a remote service |
| Saga | Keeps data consistent across microservices during distributed transactions |
| Strangler fig | Migrates a legacy system gradually by replacing its functionality piece by piece |
| CQRS | Uses separate interfaces for reading data and for updating it |
| Event sourcing | Records every action on domain data as a sequence of events in an append-only store |
| Sharding | Splits a data store into horizontal partitions, called shards |
Our guide to software architecture patterns covers each in detail. Hexagonal architecture, which Alistair Cockburn published in 2005, is a pattern for the inside of one application. Business logic sits at the center and reaches the outside world, including databases and user interfaces, through ports and adapters.
What are the layers of software architecture?
The layers of software architecture depend on the style, and in a layered (N-tier) application, they organize code by responsibility. The Azure Architecture Center says a higher layer can use services from a layer below it, but not the reverse.
| Layer | Responsibility | Example concern |
| Presentation | What users see and interact with | Screens and forms |
| Business logic | The rules that make the product work | Pricing and approvals |
| Data access | Reading and writing stored data | Queries and storage |
A layer is a logical grouping of code, while a tier is a separate physical machine or hosting unit. A closed layer may call only the layer directly below it, while an open layer may call any layer below, avoiding pass-through hops but allowing more dependencies.
How do you choose a software architecture style?
Choose a software architecture style by matching it to how often the domain changes and how mature your operations are, not to what is fashionable. That is our judgment, and it agrees with Microsoft’s guidance that microservices suit complex, fast-changing domains and teams with mature DevOps practices.
The TekRevol Style Fit Table below turns that rule into six common situations. The fit column is TekRevol’s judgment, not a standard.
| Situation | Lean toward | Why |
| Small team, domain still changing | Modular monolith | One deployable unit keeps change cheap while boundaries are still being learned |
| Several teams that must release independently, with mature DevOps | Microservices | Microsoft lists agility among the benefits of microservices and ties it to independent deployment, and it needs operational maturity |
| Near-real-time processing with many consumers | Event-driven | Producers and consumers stay decoupled, but delivery and ordering need design |
| Spiky or mostly idle workloads | Serverless | You pay only while code runs, per AWS, but watch cold starts |
| Long-running, data-heavy work with tight latency | Fewer network hops, often one process | See the Prime Video case below |
| Existing layered application moving to the cloud | N-tier first | It needs minimal change to migrate, per Microsoft |
A style label doesn’t decide the outcome; the workload does. In 2023, the Prime Video team merged a distributed, serverless audio and video quality monitoring tool into a single process and reported a cost reduction of about 90% for that tool, according to InfoQ (May 3, 2023). The original design had supported only about 5% of the expected load, and InfoQ gives no baseline for the cost figure.
Adrian Cockcroft argued that the team had refactored a serverless prototype into a continuously running container service, not returned to a true monolith, as Network World reported on May 31, 2023. Treat the result as specific to one data-heavy workload. Different kinds of products pull toward different styles, and our guide to the types of software development shows how those products differ.
How do you document software architecture?
Document software architecture by recording each significant decision in an architecture decision record (ADR) and drawing the structure from more than one view. Microsoft’s Azure Well-Architected guidance, updated April 13, 2026, describes an ADR as a log of a workload’s key decisions that shows how and why the system took its shape.
Each record holds the problem and its context, the options considered, the decision with its trade-offs and a status such as Proposed or Accepted. Write one only for architecturally significant decisions, and append a new record when a decision changes. The record below is an illustrative example, not a client record.
| Field | Example entry |
| Title | ADR-007: Keep order management in one deployable application |
| Status | Accepted |
| Context | A four-person team is still learning where the domain boundaries sit, and the order and billing logic change together every sprint |
| Options considered | Split into separate services now, or keep one deployable application with enforced module boundaries |
| Decision | Keep one deployable application with enforced module boundaries |
| Consequences | Changes are faster today, parts cannot scale independently, and the team revisits the decision if a second team takes over billing |
Views complete the picture, because no single diagram serves every reader, which is our judgment. Wikipedia notes that Philippe Kruchten’s 4+1 view model (1995) separates concerns across views, and that the C4 model helps teams model “just enough.” The international standard for architecture description is ISO/IEC/IEEE 42010, and Wikipedia dates the first formal standard in this area to IEEE 1471 in 2000.
What are software architecture best practices?
Software architecture best practices come down to deciding at the last responsible moment, recording each decision, checking the structure over time, and keeping the design as simple as the problem allows. Each practice below names its source.
- Decide at the last responsible moment. Wikipedia lists delaying decisions out of fear of being wrong as an anti-pattern, and names deciding at the last responsible moment as the remedy.
- Record decisions where the team can find them. Microsoft’s Azure Well-Architected guidance says undocumented decisions tend to be forgotten, which leads to repeated debates.
- Check the structure with fitness functions. Wikipedia says architects should use fitness functions, which are tests of a quality goal such as response time, to keep the architecture in check as the system changes.
- Design for quality attributes, not only features. Wikipedia notes that architecture is shaped by attributes such as fault tolerance and maintainability.
- Prefer practicality over purity. The Azure Architecture Center warns against chasing architectural purity at the expense of practicality.
- Align module boundaries with team boundaries. This follows from Conway’s Law, and it is our judgment that the boundaries should be drawn on purpose.
These practices share one idea: decisions that are costly to reverse deserve the most care. Our separate guide on software architecture principles covers this in depth.
What are the challenges in software architecture?
The main challenges in software architecture are matching complexity to the problem, running distributed systems, preventing erosion, keeping decisions recorded, and fitting the architect’s skills to the project’s phase. The table pairs each with what helps.
| Challenge | What goes wrong | What helps |
| Complexity beyond the domain | The system becomes a “big ball of mud,” per the Azure Architecture Center | Choose the simplest style that fits, and favor practicality over purity |
| Distributed-system overhead | Asynchronous messaging brings eventual consistency and duplicate messages, and interservice calls add latency (Azure Architecture Center) | Weigh each style’s challenges for the specific subdomain before adopting it |
| Architecture erosion | The implemented system drifts from the intended architecture, a problem Perry and Wolf described in 1992 (per Wikipedia) | Fitness functions that test the intended structure, and recovery by reconstructing the architecture from code and documentation |
| Forgotten decisions | Teams repeat debates or contradict earlier intent (Microsoft) | Architecture decision records |
| Skills that do not match the phase | A developer who succeeds at extending a system is promoted to initial designer without design and analysis training (SEI’s John Klein) | Match the architect to the phase of the system’s life |
Staffing is a challenge of its own. Klein describes three roles an architect plays as a system ages, and our guide to software architect roles and responsibilities covers them.
What are the future trends in software architecture?
The strongest influence on future software architecture is AI workloads, which add new components to design and put pressure on security and fundamentals. In the CNCF’s 2025 annual survey, released January 20, 2026, 82% of container users ran Kubernetes in production, and 66% of organizations hosting generative AI models used Kubernetes for some or all inference.
Agent orchestration is becoming its own pattern family. The Azure Architecture Center describes five multiagent patterns: sequential, concurrent, group chat, handoff, and magnetic, and advises using the lowest level of complexity that reliably meets the requirement, which often means a single agent with tools.
Thoughtworks’ Technology Radar Vol. 34, published April 15, 2026, argues that AI-assisted development pushes teams back toward established practices such as zero trust architecture and testability. It also warns of cognitive debt, which builds as AI produces more code and widens the separation between people and the software they build.
In our judgment, the architecture questions stay familiar, namely where the boundaries sit and what happens when a part fails, with agents as new components to place within them.
How does TekRevol approach software architecture?
TekRevol builds architecture planning into the design stage of its custom software development process, alongside workflow mapping and database schema work. TekRevol is a software development company that puts this planning ahead of the build, when a structural choice costs least to change.
If you are weighing a monolith against services, or choosing how a new product should be structured, talk to the team before the first sprint. Start with a Free Consultation.
