{"id":31833,"date":"2026-10-26T13:21:39","date_gmt":"2026-10-26T13:21:39","guid":{"rendered":"https:\/\/www.tekrevol.com\/blogs\/?p=31833"},"modified":"2026-10-27T10:15:59","modified_gmt":"2026-10-27T10:15:59","slug":"software-architecture-guide","status":"publish","type":"post","link":"https:\/\/www.tekrevol.com\/blogs\/software-architecture-guide\/","title":{"rendered":"What Is Software Architecture: A Comprehensive Guide"},"content":{"rendered":"

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.<\/p>\n

Each section stands on its own, so you can jump to the part you need.<\/p>\n

What is software architecture?<\/strong><\/h2>\n

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.<\/p>\n

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.<\/p>\n\n\n\n\n\n\n\n
Source<\/strong><\/td>\nHow it frames architecture<\/strong><\/td>\nEmphasis<\/strong><\/td>\n<\/tr>\n
SEI (John Klein, 2016)<\/strong><\/td>\nThe structures needed to reason about a system: elements and the relations among them, plus their properties<\/td>\nStructure and analysis<\/td>\n<\/tr>\n
Martin Fowler, citing Ralph Johnson (IEEE Software, 2003)<\/strong><\/td>\nThe shared understanding expert developers have of the system’s design, or “the important stuff”<\/td>\nPeople and importance<\/td>\n<\/tr>\n
ISO\/IEC\/IEEE 42010<\/strong><\/td>\nThe standard’s definition, as quoted on the arc42 page, refers to fundamental concepts or properties of an entity<\/td>\nContext and stakeholders<\/td>\n<\/tr>\n
Perry and Wolf (1992)<\/strong><\/td>\nA blueprint for the system, analogous to building architecture<\/td>\nPlanning<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

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<\/a> covers separately.<\/p>\n

Why is software architecture important?<\/strong><\/h2>\n

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.<\/p>\n

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.<\/p>\n

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.<\/p>\n

A structure that ignores team boundaries tends to fight them, which is our judgment.<\/p>\n

What is the difference between software architecture and software design?<\/strong><\/h2>\n

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.<\/p>\n

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.<\/p>\n

Software design and architecture both happen inside every custom software development<\/a> project, and the choices made first cost the most to undo. For the lifecycle around them, see what software development involves<\/a>.<\/p>\n

What are the types of software architecture?<\/strong><\/h2>\n

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.<\/p>\n

Architectural styles in software engineering are families of architectures that share characteristics and constraints, according to the Azure Architecture Center<\/a>. 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.<\/p>\n\n\n\n\n\n\n\n\n\n
Style<\/strong><\/td>\nDefining feature<\/strong><\/td>\nChoose when<\/strong><\/td>\nMain cost<\/strong><\/td>\n<\/tr>\n
Monolith<\/strong><\/td>\nAll application code ships as one deployable unit. A modular monolith keeps clear boundaries inside it<\/td>\nA small team on a domain that is still changing (our judgment)<\/td>\nParts cannot deploy or scale on their own (our judgment)<\/td>\n<\/tr>\n
Layered (N-tier)<\/strong><\/td>\nCode is split into layers by responsibility, and a higher layer uses the layer below, not the reverse<\/td>\nRequirements are still evolving, or an existing application is migrating with minimal change<\/td>\nChanges ripple across layers, and a monolithic design blocks independent deployment<\/td>\n<\/tr>\n
Client-server<\/strong><\/td>\nA client requests services and a server provides them<\/td>\nMost web and mobile products, where thin front ends rely on shared back-end logic (our judgment)<\/td>\nThe server becomes a shared dependency (our judgment)<\/td>\n<\/tr>\n
Microservices<\/strong><\/td>\nSmall autonomous services, each built around one business capability, with its own codebase and data store<\/td>\nThe domain is complex and fast-changing, and development and DevOps practices are mature<\/td>\nData consistency across services and the operation of a distributed system add complexity<\/td>\n<\/tr>\n
Event-driven<\/strong><\/td>\nProducers emit events, channels carry them and consumers react in near real time<\/td>\nSeveral subsystems must react to the same events, or processing must be near real time<\/td>\nDelivery guarantees and event ordering need careful design, and data is only eventually consistent<\/td>\n<\/tr>\n
Serverless<\/strong><\/td>\nA provider runs the infrastructure, and code runs on demand and scales to zero<\/td>\nWorkloads are spiky or mostly idle, since billing covers only the compute used<\/td>\nCold starts add delay, and tracing one request across many functions is harder (our judgment)<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

 <\/p>\n

\"Diagram<\/p>\n

Sources for the table are the Azure Architecture Center (N-tier, microservices and event-driven pages) and AWS (serverless).<\/p>\n

Microservices and serverless designs usually run on cloud platforms, which is the territory of cloud-native development.<\/p>\n

What is a software architecture pattern?<\/strong><\/h2>\n

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.<\/p>\n

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.<\/p>\n\n\n\n\n\n\n\n\n\n
Pattern<\/strong><\/td>\nWhat it solves<\/strong><\/td>\n<\/tr>\n
Circuit breaker<\/strong><\/td>\nHandles faults that take a variable time to resolve when an application calls a remote service<\/td>\n<\/tr>\n
Saga<\/strong><\/td>\nKeeps data consistent across microservices during distributed transactions<\/td>\n<\/tr>\n
Strangler fig<\/strong><\/td>\nMigrates a legacy system gradually by replacing its functionality piece by piece<\/td>\n<\/tr>\n
CQRS<\/strong><\/td>\nUses separate interfaces for reading data and for updating it<\/td>\n<\/tr>\n
Event sourcing<\/strong><\/td>\nRecords every action on domain data as a sequence of events in an append-only store<\/td>\n<\/tr>\n
Sharding<\/strong><\/td>\nSplits a data store into horizontal partitions, called shards<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Our guide to software architecture patterns<\/a> 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.<\/p>\n

What are the layers of software architecture?<\/strong><\/h2>\n

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.<\/p>\n\n\n\n\n\n\n
Layer<\/strong><\/td>\nResponsibility<\/strong><\/td>\nExample concern<\/strong><\/td>\n<\/tr>\n
Presentation<\/strong><\/td>\nWhat users see and interact with<\/td>\nScreens and forms<\/td>\n<\/tr>\n
Business logic<\/strong><\/td>\nThe rules that make the product work<\/td>\nPricing and approvals<\/td>\n<\/tr>\n
Data access<\/strong><\/td>\nReading and writing stored data<\/td>\nQueries and storage<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

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.<\/p>\n

How do you choose a software architecture style?<\/strong><\/h2>\n

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.<\/p>\n

The TekRevol Style Fit Table below turns that rule into six common situations. The fit column is TekRevol’s judgment, not a standard.<\/p>\n\n\n\n\n\n\n\n\n\n
Situation<\/strong><\/td>\nLean toward<\/strong><\/td>\nWhy<\/strong><\/td>\n<\/tr>\n
Small team, domain still changing<\/strong><\/td>\nModular monolith<\/td>\nOne deployable unit keeps change cheap while boundaries are still being learned<\/td>\n<\/tr>\n
Several teams that must release independently, with mature DevOps<\/strong><\/td>\nMicroservices<\/td>\nMicrosoft lists agility among the benefits of microservices and ties it to independent deployment, and it needs operational maturity<\/td>\n<\/tr>\n
Near-real-time processing with many consumers<\/strong><\/td>\nEvent-driven<\/td>\nProducers and consumers stay decoupled, but delivery and ordering need design<\/td>\n<\/tr>\n
Spiky or mostly idle workloads<\/strong><\/td>\nServerless<\/td>\nYou pay only while code runs, per AWS, but watch cold starts<\/td>\n<\/tr>\n
Long-running, data-heavy work with tight latency<\/strong><\/td>\nFewer network hops, often one process<\/td>\nSee the Prime Video case below<\/td>\n<\/tr>\n
Existing layered application moving to the cloud<\/strong><\/td>\nN-tier first<\/td>\nIt needs minimal change to migrate, per Microsoft<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

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.<\/p>\n

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<\/a> shows how those products differ.<\/p>\n

How do you document software architecture?<\/strong><\/h2>\n

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.<\/p>\n

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.<\/p>\n\n\n\n\n\n\n\n\n\n
Field<\/strong><\/td>\nExample entry<\/strong><\/td>\n<\/tr>\n
Title<\/strong><\/td>\nADR-007: Keep order management in one deployable application<\/td>\n<\/tr>\n
Status<\/strong><\/td>\nAccepted<\/td>\n<\/tr>\n
Context<\/strong><\/td>\nA four-person team is still learning where the domain boundaries sit, and the order and billing logic change together every sprint<\/td>\n<\/tr>\n
Options considered<\/strong><\/td>\nSplit into separate services now, or keep one deployable application with enforced module boundaries<\/td>\n<\/tr>\n
Decision<\/strong><\/td>\nKeep one deployable application with enforced module boundaries<\/td>\n<\/tr>\n
Consequences<\/strong><\/td>\nChanges are faster today, parts cannot scale independently, and the team revisits the decision if a second team takes over billing<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

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.<\/p>\n

What are software architecture best practices?<\/strong><\/h2>\n

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.<\/p>\n