Maintainability is the effort required to keep an automation working as a whole and to change its individual building blocks when requirements evolve. It belongs beside the automation’s goal, triggers, and actions when designing the work. section 1.2
Plan for likely change rather than assuming today’s workflow will remain fixed. A useful question at every stage is: how difficult will this part be to maintain if operational requirements change? Reusable building blocks and phased automation work make later automation easier to extend. section 1.2 section 1.2.4
Design choices that support maintainability include:
- Keep changeable values configurable. In log cleanup, storing the retention period as a variable makes a shift from 30 days to 14 days straightforward. section 1.2.4
- Avoid repeating hardcoded values across scripts, because a changed requirement can otherwise require multiple edits. section 1.2.4
- Consider who can understand and alter the automation after its original creator leaves. section 1.2.4
User provisioning workflow
An automation that initially saved 30–60 minutes each week created users in one directory, waited an hour, and moved them for synchronization with an in-house application. Later directory policies changed, the creator had left, and others could not understand the automation; manual workarounds made it cost more than it saved. The failure was not anticipating change and leaving an understandable, adaptable process. section 1.2.4
Log cleanup retention
A web server’s audit logs must be compressed and moved to long-term storage rather than deleted. If storage begins filling faster, the retention threshold may need to change. A single variable for the number of days localizes that change. section 1.2 section 1.2.4
