EC-14.2 Architecture and Choosing Components

What this is and why it exists

Architecture is where the layering argument from the networking module reappears as a general engineering idea.

A boundary drawn well means two people can work on either side of it without talking every day. A boundary drawn badly means they cannot work at all.

Component selection is in this topic rather than treated as shopping. Availability and lifetime decide more designs than performance does, and almost no course says so.

The vocabulary

• Architecture — the division of a system into parts and the interfaces between them.
• Interface — the agreement across a boundary: signals, protocol, units, ranges and failure behaviour.
• Cohesion — how much one part's contents belong together.
• Coupling — how much two parts depend on each other's internals.
• Second source — an alternative part that can be used without redesign.
• Lifecycle notice — a manufacturer's statement about how long a part will be produced.
• Build or buy — the decision to design a subsystem or to purchase it as a module.

The mental model

A good boundary is one with a narrow, stable interface across it.

Narrow means few signals and few assumptions. Stable means it will not change every time either side is revised. When both hold, the two sides can be built and tested independently, which is the entire benefit.

The worst boundaries are drawn along the lines of who will build each part rather than what each part does. That produces interfaces that reflect the team's shape and change whenever the design does.

The interface has to be written down, and five things belong in it. Signals or messages, the protocol or timing, the units, the valid ranges, and what happens when the other side stops responding.

Two people can build either side independently only if all five are recorded. Most integration problems trace back to one of the five that was assumed rather than written. The failure-behaviour item is the one omitted most often.

Component selection starts by writing criteria before looking at any part. Performance, cost, package, supply voltage, tooling, and support.

If you look first, the first attractive datasheet becomes the specification. Every later comparison is then a search for reasons to keep the choice already made. Writing the columns first takes ten minutes and changes the outcome.

Availability is the criterion students never include and professionals check first. A part that is perfect and unavailable is not a choice.

Check current stock, look for the manufacturer's lifecycle notice, and find out whether a compatible alternative exists. All three take minutes, and discovering a sixteen-week lead time after the board is designed costs a redesign.

Build or buy is a design decision made per subsystem rather than once. A module you can buy costs money and saves time and risk. One you design costs time. It gives you control over cost at volume, over the details, and over what happens when the supplier stops making it.

Neither answer is generally right. Deciding it deliberately, subsystem by subsystem, with the reason recorded, is what makes it engineering rather than budgeting.

Finally the block diagram, which is the output of all of this. Every block named, every connection labelled with what it carries, and every external interface shown.

The test is whether somebody else could start building from it. A diagram only its author can read has not done the job a diagram exists for. The commonest failure is unlabelled arrows, which record that two things are connected and nothing more.

What you should now be able to explain or do

• Divide a system into parts and justify where you drew each boundary.
• Write an interface specification covering all five items.
• Write selection criteria before looking at any component.
• Check availability, lifecycle and second sources as part of selection.
• Make a build-or-buy decision per subsystem and record the reason.
• Produce a block diagram a second engineer could build from.

Check yourself