What Software Architecture Is

Welcome to Chapter 1: What Software Architecture Is. Chapter zero gave you the building blocks. This chapter steps back and asks what it means to arrange those blocks deliberately, who does it, and why it is worth the effort. It gives you the vocabulary the rest of the course depends on, and a way of thinking you can apply to any system, from a small booking app to a national payments platform.

Every software system has an architecture, whether anyone designed it or not. It is the set of fundamental structures that make up the system, and the significant decisions that produced them. Those structures decide far more than most people realise: how fast and reliable the system is, how much it costs to run, and how many teams can work on it at once. Above all, they decide how expensive the system will be to change next year. Features are what a system does. Architecture largely decides how well it does them, and what it costs to do something different.

This chapter is written for developers who are moving towards architectural responsibility. It is also for anyone who works with architects and wants to understand what they do, and why. It builds on the building blocks from Chapter zero: components, data stores, networks and APIs. If you are comfortable with those, you are ready. And it leads into Chapter 2, which takes the goals of an architecture and makes them precise and measurable, as quality attributes.

The chapter has eight sections. Section one point one compares the definitions that matter, from the international standard and from the Software Engineering Institute, or SEI, to practitioners who stress shared understanding and decisions that are expensive to change. Section one point two tackles the most common confusion: where architecture ends and design begins. The answer is that there is no wall, only a continuum ordered by significance. Section one point three makes the case for caring, grounded in three real cases: the Knight Capital trading loss of twenty twelve, the troubled HealthCare dot gov launch of twenty thirteen, and a twenty twenty-three change at Amazon Prime Video.

This diagram from Section one point one shows the ideas the definitions share, using a food-delivery system. The dashed line is the system's boundary. The boxes inside it are elements: a mobile app, an order service, an orders database, a courier service and a payment module. The arrows are relations. The app calls the order service over HTTPS. The order service queries the database with SQL, and sends an event to the courier service. Small labels record properties. The order service, for example, is stateless, with three copies running. Outside the boundary is the environment: the customers, couriers and restaurants, and the card payment provider. And the environment is more than other systems. It also includes law, budget, the organisation and its teams, and the cloud platform. You cannot understand an architecture without them.

Section one point four looks at the people: what architects actually do, the different kinds of architect, why architecture is a role before it is a job title, and the long-running debate about whether architects should still write code. Section one point five widens the lens to stakeholders, everyone with an interest in the system, from users and developers to regulators. It shows how conflicting concerns are made explicit, rather than settled by whoever shouts loudest. Section one point six turns to decisions and trade-offs: what a good decision contains, which decisions can easily be reversed and which cannot, and the idea of deciding at the last responsible moment.

The last two sections are about time. Section one point seven explains technical debt as Ward Cunningham originally meant it, how it differs from mere mess, and how architectures erode and drift away from their intended shape. Section one point eight places architecture in the delivery lifecycle, between big design up front and purely emergent design, and shows a practical middle ground: just enough architecture, at the right time, checked continually.

This diagram from Section one point two shows how to tell architecture from design. Decisions towards the left are more architectural; towards the right, more a matter of design and code. The first test is the cost of reversing a decision: months of work for many teams at one end, minutes for one person at the other. The second is scope of impact: the whole system or organisation, or just one function or class. The third is the effect on key qualities. The dots place one real decision, the choice of message format, on each line, and on all three it leans towards the architectural end.

If you remember one thing from this chapter, make it this. Architecture is the set of decisions that are expensive to get wrong. The architect's job is to identify those decisions, make them deliberately with the right people, record why, and keep them under review, while making as many other decisions as possible cheap to change. The rest of the course applies that idea.

You can read the sections in order, which is best if the ideas are new, or dip into the ones you need. The whole chapter takes about two and a half hours to read. Each section ends with a few self-check questions. Try to answer them in your head before you look, so you can see what has stuck. When you are ready, there is an optional chapter test, with twenty multiple-choice questions and two written answers. Allow about forty five minutes. The pass mark is eighty per cent, the same as for every chapter test in the course.

That is the map of Chapter 1. Begin with Section one point one, where we compare the standard definitions of software architecture and find what they have in common. See you there.