Part 1: Rethinking Networking with Automation#

Most network automation projects do not fail because the technology is wrong. They fail because the people building them did not have a clear enough answer to three questions before they started: Why is automation necessary here, not just convenient? What design properties should the system have to remain trustworthy as it grows? And what does a complete automation architecture look like, so that the work being done today fits coherently into a larger system rather than accumulating as another layer of scripts?

Part 1 answers those three questions in order.

Chapter 1 makes the case for automation as a structural requirement, not an operational preference. Networks have grown more complex, more interconnected, and more critical faster than the manual processes built to manage them. The chapter traces how this gap opens, what happens when organizations try to close it with scripts alone, and what a system that genuinely scales looks like compared to one that only appears to until it fails under real conditions.

Chapter 2 establishes the design principles that separate automation systems that remain reliable and maintainable over time from those that do not. It introduces the quality properties, such as predictability, reliability, and understandability, that any production automation system must satisfy, and the principles that translate those properties into architectural decisions. These principles are not prescriptive rules; they are the reasoning framework that allows an architect to evaluate a design trade-off rather than guess at it.

Chapter 3 introduces the NAF Framework: a reference architecture that organizes the seven building blocks every production automation system requires into a coherent model. The chapter shows how existing frameworks and patterns from software architecture apply to network automation, where they apply directly, and where the physical and operational constraints of network infrastructure require adaptations. By the end of Chapter 3, the reader has a named, structured model for the complete system that Part 2 builds block by block.

The three chapters form a progression: the argument for change, the principles for designing well, and the framework for organizing the design. A reader who skips Part 1 and begins with Part 2 will find the building blocks described accurately but will lack the reasoning behind why they are structured the way they are, and why alternatives that may seem simpler are not used.

Part 2 takes the framework introduced in Chapter 3 and examines each of its seven building blocks in depth. The work of Part 1 is the conceptual foundation that makes that examination coherent rather than a catalog of independent components.

💬 Found something to improve? Send feedback for this chapter