Start Here: How Software Works

Welcome to Be Software Architecture Wise, and to Chapter zero: Start Here, How Software Works. This chapter is the on-ramp to the whole course. It assumes you have used apps and websites, but have never written a program. By the end of it, you will have the vocabulary that every later chapter builds on.

Software architecture is about the big decisions in a software system: what its main parts are, how they talk to each other, where data lives, and which qualities, such as speed, reliability and security, the design must achieve. Those decisions are made in a vocabulary: processes and threads, indexes and caches, interfaces and dependencies, transactions, APIs and containers. Architects use these words precisely, so you need to know what each one really means, and what it costs. This chapter is written for someone who has never programmed. Every section opens with an everyday analogy before explaining the real mechanism. If you are already an engineer, you can skim it as a shared vocabulary.

This chapter builds on nothing at all. It assumes no technical background, which makes it the right place to begin. It leads straight into Chapter 1, which uses these building blocks to explain what software architecture is, and why the big decisions matter so much. Where a topic here deserves more depth, the chapter links forward to the later section that treats it properly.

The chapter has eight sections, in three groups. The first three stay inside a single machine. Section zero point one explains how code written by people becomes instructions a processor can run, and why data in memory disappears on a restart. Section zero point two introduces the everyday data structures, such as lists, dictionaries and queues. Using Big O notation, it explains why one way of finding a customer stays fast at a million customers, while another collapses. Section zero point three climbs from functions to modules, objects and interfaces. It explains the difference between a library and a framework, warns about the hidden cost of dependencies, and gives a first look at coupling and cohesion.

The next three sections leave the single machine. Section zero point four explains how DNS turns names into addresses, and how HTTP requests and responses work. It also shows that network delay has a floor set by the speed of light. Section zero point five covers files and databases: tables, SQL queries, indexes, and transactions, illustrated with a bank transfer that must never half happen. It also introduces the main non-relational databases, and when each one fits. Section zero point six explains how separate systems cooperate through APIs. An API is a contract. You will see the difference between waiting for an answer and sending a message through a queue, and why breaking an API hurts everyone who depends on it.

The last two sections cover where software runs and how it is built. Section zero point seven shows what a server really is, how virtual machines and containers let many workloads share one physical machine, and what cloud providers sell. Section zero point eight turns from technology to practice: requirements, version control, testing, continuous integration and delivery, and ways of working. It closes by following one tap on Place order in a food-delivery app through every part of the chapter.

That journey is worth a first look now, because it shows where the whole chapter is heading. A customer has filled a basket and taps Place order. Follow the numbers. First, the phone asks DNS for the company's address. Then it sends the order over HTTPS to a load balancer inside the company's cloud region, where the secure connection ends. The load balancer passes the request to the order service. That service calls an outside payment provider through its API, then writes the order to its database in a transaction. Next, it puts an Order Placed message on a queue. A notification service picks it up and asks the push service run by Apple or Google to send a notification to the customer's phone. Notice the dashed arrows: that last part is asynchronous. If the notification service is down, orders are still taken, and the messages simply wait in the queue. Someone had to decide that, and making decisions like that is architecture.

Here is the idea to take away from the whole chapter. Every system in it is built from parts that hide their details behind an agreed boundary: a module behind its interface, a database behind SQL, a payment provider behind its API. Boundaries are where the important trade-offs sit. A function call is fast and reliable, while a call across a network is slower and can fail. A dependency saves effort but brings risk. A cache saves time but can serve stale data. Deciding where those boundaries go, what crosses them, and which trade-offs to accept, is software architecture. Each section ends with a short note on why its subject matters for architecture, so look out for those.

How should you study it? If you are new to the subject, read the sections in order, because each one builds on the last. If you already know some of it, dip into the sections you need. The whole chapter takes about three hours to read. Each section ends with a few self-check questions. Answer them in your head before you look at the answers. They show you quickly what has stuck, and what is worth reading again. When you are ready, you can take the optional chapter test: twenty multiple-choice questions and two written answers. Allow about forty five minutes. The pass mark is eighty per cent. Before you start the test, check that you can answer the self-check questions for every section, and reread the summary of any section that still feels unclear.

That is the map of Chapter zero. Start with Section zero point one, where we look at what software is, and what really happens when a computer runs a program. See you there.