6.4Development processes and DevOps

The choice of development process and post-release maintenance operations shape the system's entire lifecycle. A systems architect is responsible for judging, from constraints such as how firm the requirements are and how fast they change, whether waterfall or agile fits better, and for routing post-release incidents, requests, and environmental changes to the appropriate response based on the four maintenance categories. Misclassifying this can lead to incidents such as an issue needing urgent attention getting buried among unplanned enhancement work and deprioritized.

6.4.1Waterfall, iterative, and agile

• The waterfall model proceeds through requirements definition, design, implementation, and testing in sequence from upstream to downstream, with the assumption of no going back. For large systems whose requirements are settled early and change little, it has the advantage of being easy to manage for progress and budget, but its weakness is that a requirement change late in the process incurs large rework cost.
• Iterative development repeats the whole sequence from requirements through implementation and testing in small units (iterations), incorporating feedback each time and building up functionality incrementally. Agile (a leading example being Scrum) is a practical form of this, producing working software every short period (a sprint) and flexibly following changes in priority or requirements. It suits projects where requirements change frequently and early value delivery matters.

6.4.2CI/CD and the four maintenance categories

• CI (continuous integration) automatically builds and runs tests every time a developer changes code, catching problems early. CD (continuous delivery/deployment) automates through to releasing (delivery) code that has passed CI to a production-equivalent environment, or through to actually deploying it to production. It reduces the variability and mistakes of manual release work and allows a higher release frequency.
• Corrective maintenance fixes defects (bugs) discovered after go-live. Adaptive maintenance adapts the system to changes in the external environment, such as an OS/middleware version upgrade or a regulatory change—the system itself has no defect.
• Preventive maintenance proactively addresses potential risk points ahead of time to prevent a future defect from occurring (e.g., catching early signs via log monitoring and acting before disk space runs out). Perfective maintenance is not about a defect at all; it actively improves functionality, such as performance or usability. The four categories are easiest to distinguish by sorting on "is it defect-related or not," "is the cause internal to the system or external," and "is it reactive or proactive."

Suppose a systems architect receives several requests concerning an already-released core system and must judge how to classify and respond to each. The first is a report that "under certain conditions, the order total is calculated incorrectly"—this is classified as corrective maintenance, fixing a defect discovered after go-live, and handled with top priority given the scope of impact. The second is a request that "the middleware in use reaches end of support in 2027, so a version upgrade is needed before then"—the system itself has no bug; this is adaptive maintenance, adapting to an external-environment change (end of support), handled by securing budget and schedule in a planned way. The third is that "monitoring the logs revealed a specific log file is projected to exceed the assumed disk capacity in about six months"—no actual harm has occurred yet, but this is preventive maintenance to head off a future failure, handled by planning a disk expansion or revisiting the log-rotation settings. The fourth is that "the current search feature works as required, but users keep asking for faster response"—not a defect, but a request to actively improve function/performance, classified as perfective maintenance, weighed against the priority of other work to decide whether to fold it into the next release. In parallel, to release these maintenance responses quickly and safely, the architect builds out a CI pipeline that automatically builds and tests on every code change, and a CD pipeline that automatically delivers tested code to a production-equivalent environment, strengthening the ability to get corrective fixes (bug fixes) into production quickly in particular. Discerning the nature of each request (bug, environmental change, future risk, or functional improvement), sorting it into the four categories, and judging priority and response accordingly, is what the practice looks like.

6.4.3Section summary

• Waterfall = suits settled requirements and large scale, high rework, agile (Scrum) = short iterations resilient to changing requirements
• CI = automated build/test, CD = automates through to release/deployment
• The four maintenance categories: corrective = bug fix / adaptive = follows external environment change / preventive = gets ahead of a future defect / perfective = actively improves function/performance