The authors order the trade into generation, storage, ingestion, transformation and serving, then add what they call undercurrents: security, data management, operations, architecture, orchestration and software engineering. The interesting part is that those six are not stages. They run through everything, which is why nobody puts them in the schedule.
What I took from it
Orchestration treated as a permanent concern rather than a task. A data project without orchestration is not a half-finished project: it is a report somebody runs by hand on the third of every month, until that person changes role and nobody knows which file they used to open. That ending is common enough that I now put it in writing in proposals.
The three questions about the source system, which I ask before anything else: who generates the data, how often its structure changes, and who tells you when it changes. The third almost never has an answer, and that is where the project's risk is concentrated.
And the insistence on non-functional requirements up front. How long it may take, what it may cost, who may see what. They get left for the end because they are uncomfortable, and they are the ones that force rework.
What I left out
The tooling survey, which aged quickly, and the modern data stack framing, sold in 2022 as the future and now a catalogue label with several of its pieces absorbed or shut down. The book is deliberately vendor-neutral and that makes it long: some chapters spend twenty pages on what fits in a ten-point list.