Planning Your First Automation Project

Before any code, a plan

Every module up to this point taught one piece at a time: Python syntax, data formats, the concepts behind automation itself. This module is different — it's where all of that comes together into one real, complete tool, built the way an engineer would actually build it: starting with a plan, not a blank file.

That's not a formality. A clear plan is what turns "write some Python" into something you can actually finish and trust — the same discipline "Network Automation Fundamentals" argued for back when this curriculum hadn't written a line of code yet.

The project

Across this module, you'll build a small network health check — the kind of tool a real team might run before a maintenance window, or on a schedule, to catch problems early:

Read a list of switches from an inventory file. For each one, check whether it's reachable, whether its NTP is synced, and whether it's VLAN-compliant. Produce a report showing exactly which devices are fine and which need attention.

That's the whole project, in one sentence. Everything else this module does is building toward exactly that.

Familiar, on purpose

If an NTP and VLAN check sounds like something you've seen before in this curriculum, that's intentional — this project is the same kind of task "Start Here" and "Network Automation Fundamentals" described in plain language, and the Python module built smaller versions of, now assembled into one complete, well-organized tool.

Scoping it: input, process, output

Any automation task can be scoped with the same three questions this curriculum has used since "Automation Building Blocks":

Input — what does the tool need before it can run? Here: a device inventory (hostname, IP, platform — the same structured shape from every lesson so far).
Process — what does it actually do with that input? Here: connect to each device (or, for now, simulate connecting), check NTP sync and VLAN compliance, and decide a status for each one.
Output — what does it produce? Here: a saved report a person can read afterward, and a short summary printed to the terminal.

Quick checkConcept check

In this module's project, what counts as the 'input'?

The compliance report the script producesThe device inventory the script reads at the startThe terminal summary printed at the endThe Python interpreter itself

Defining 'done' without a real device

Here's the part that trips people up: you don't need a real switch to build and fully trust this tool's logic. The Python module's capstone already proved this — mock data, run through real code, is enough to know a script works correctly before it ever touches production hardware.

This project takes that one step further: instead of hardcoding mock results directly into a list of dictionaries (like the Python capstone did), this module builds a proper simulated connection layer — a function that stands in for a real device connection, cleanly separated from the rest of the tool. "Done" for this module means: the tool runs end to end against that simulation, produces a correct report, and is structured so that swapping the simulation for a real connection later — which is exactly what "Netmiko Fundamentals" does — doesn't require rewriting anything else.

Quick checkMyth check

Does building and testing this project's logic require a real network device?

Yes — there's no way to verify automation logic without real hardwareNo — a simulated connection layer, tested with realistic mock outcomes, is enough to fully trust the logic before any real device is involvedYes, but only for the reporting partNo, but only for very simple scripts

How this module is organized

1. Plan the projectthis lesson — scope, input/process/output
2. Build the inventory layerload and validate the device list
3. Simulate device connectionsa function that stands in for real SSH
4. Validate results & build the reportturn raw state into a saved report
5. Assemble the complete projecteverything, wired together, running end to end

Each lesson from here adds exactly one real piece. By the end of Lesson 5, you'll have a complete, runnable tool — and you'll understand every line of it, because you built it one stage at a time.

Quick checkScenario

A device inventory file is missing an IP address for one switch. Which stage of this project's plan is responsible for catching that, before it causes a confusing failure later?

The report-writing stageThe inventory layer — validating that each record has what it needs before anything tries to use itThe terminal summaryNothing needs to catch it — Python would handle it automatically

Quick checkConcept check

Why does this project use a dedicated 'simulated connection' function, rather than just hardcoding mock results into a list of dictionaries like the Python module's capstone did?

Hardcoded mock data is actually not allowed in PythonSo the rest of the tool doesn't need to change when the simulation is later replaced with a real device connectionBecause dictionaries can't hold connection resultsThere's no real difference — it's just a stylistic preference

Key takeaways

This module's project: a network health check that reads an inventory, checks NTP sync and VLAN compliance, and produces a report.
Input, process, output is a reliable way to scope any automation task — and maps directly onto this project's inventory, connection/validation, and reporting stages.
'Done' means the tool's logic runs correctly against realistic simulated results — not that it's been tested against a real device.
A dedicated simulated connection function, kept separate from the rest of the logic, is what makes swapping in a real connection later a small, contained change.
This module builds the project incrementally: inventory, then simulated connection, then validation and reporting, then full assembly.

What you'll learn

Before any code, a plan

The project

Scoping it: input, process, output

Defining 'done' without a real device

How this module is organized