What is software architecture?

What architecture is

Software architecture is the set of fundamental choices about a system. These choices cover its parts, how the parts relate, and the reasons behind them. Definitions differ in detail. Most stress three things: structure, important decisions, and the cost of changing those decisions later. See Software Architecture and Software Architecture Definition.

Two ideas help here:

• A system has a boundary. Everything inside is the system. Everything outside is its environment. Inside, the parts are organized in levels, from a coarse overview down to finer detail. See Software Architecture Basic Concepts and Architecture Level.
• Every system has an architecture, even if nobody planned or wrote it down. See Implicit Architecture.

Why it matters

An architecture that nobody chose is called accidental architecture. Quick fixes and piecemeal growth erode it. In the end it can become a Big Ball of Mud: a system whose structure comes from patches, not design.

This slow drift away from the intended design is architecture decay. Teams counter it with refactoring, which means changing the inside of software in small steps without changing what it does. They also use conformance checks, which compare the built system with the intended design.

Requirements shape architecture too. Constraints limit what the architect may choose. Good architects learn early which decisions are free and which are bound. See Requirements and Means Influence Architecture and Software Architecture in Its Context.

What an architect does

An architect links business goals and technical work. The architect decides what matters, weighs trade-offs, and talks with people at every level of the organization. The architect also stays close to the building of the system. See Software Architect and Role of the Software Architect.

In practice, the work looks like this:

• Make the big design decisions and write down the reasons for them.
• Work in a cycle of designing, checking and refining. See Architectural Thinking.
• Do just enough architecture, guided by the biggest risks, and revisit it as the product changes. See Agile Architecture.
• Produce a vision, a context view, an architecture overview and an operational model. See Architect’s Four Key Work Products.
• Choose from a toolbox of styles, patterns and tactics. More concrete tools give more structure, but they also limit the architect’s freedom. See Architecture Means.

Example: ClinicBook

ClinicBook is a fictional online booking system for 40 small medical practices. Patients book, move and cancel appointments on the web and in a mobile app. Practice staff manage calendars. The system must also work with each practice’s existing software, send reminders by SMS and e-mail, and protect health data.

The forces on this system are privacy and security, availability during morning peaks, integration with legacy systems, a small team, and a fixed launch date. Each force points to an architectural question.

Constraints and risks. The launch date and the small team are constraints. They argue against a big upfront design. A broad starting architecture fits better. The team then spends its effort on the biggest risks first, such as integration and privacy. It revisits the design as it learns more.

Context view. Treat ClinicBook as a black box. Show who talks to it and what data they exchange. The partners are patients, practice staff, the practice-management software of different vendors, and the SMS and e-mail services. This picture shows the boundary and makes the integration work visible.

Quality goals. Privacy and security, and availability in the morning peak, are the likely top goals. Stating them explicitly keeps later decisions honest. If a design choice helps availability but hurts privacy, the team can see the conflict and ask the stakeholders to resolve it.

Security. The common architect mistakes include building security yourself when established solutions exist. For health data, ClinicBook should favor an established solution.

Integration. Calling another system is not the same as calling a function inside your own. When a system is split into separate processes, a call to another process may be slow or may fail while the rest keeps running. A practice’s software may be slow in the morning peak. ClinicBook’s design must say what happens then, for example by using timeouts. See Connectors and Distribution.

Keeping the structure. The team writes down its key decisions and the reasons. It plans refactoring as ongoing work, not as a task for later. See Iterative and Incremental Development. Without this, the pressure of a fixed launch date can push ClinicBook toward accidental architecture.

Where to go next

Start with Software Architecture and Software Architect. Then read Architect’s Four Key Work Products to see what an architect produces.