Software-Defined Operations: Change How Operations Work

When an operating requirement changes, where does the change go? A revised minimum reservoir reserve at a pumping station has to reach a planning calculation, an operating procedure, an approval route and every pending recommendation that used the old value. The governing logic is spread across systems and people, and each revision starts with an investigation into which expression of the rule governs which use.

Pieter van Schalkwyk's new book, Software-Defined Operations: Change How Operations Work, gives that logic an identifiable definition in software. It is written for operations leaders, engineering and systems teams, and business sponsors, and it follows one decision from start to finish: how a three-pump transfer station should adjust its pumping plan when equipment condition, demand, energy prices or operating requirements change.

The definition

Software-Defined Operations is an architectural pattern that decouples operational decision and coordination logic from the underlying applications, automation systems and physical infrastructure, enabling that logic to be configured, changed and governed through software.

The pattern has precedents. Software-defined networking separates network control from packet forwarding; software-defined automation separates control software from hardware. Software-Defined Operations names a different responsibility: the definition of the operational response itself. The pumps, measurements and maintenance systems remain necessary. What changes is how the organization decides and coordinates their use as conditions and requirements change. In Pieter's framing, it is the architecture for agentic operations rather than a replacement for it.

What the book covers

• Chapter 1 shows why operational change becomes a systems problem: one decision, six places where its logic lives today.
• Chapter 2 defines what becomes software-defined: the three responsibilities, the seven parts of a decision definition, what can change independently, and how people and agents participate, from Monitor & Predict to Advise & Guide to Coordinate & Autonomize.
• Chapter 3 runs the decision under its active definition, then changes the reserve requirement on the same input case and shows exactly which results and dependencies change with it.
• Chapter 4 asks what changes for the enterprise: coordinating across responsibilities, changing the response while keeping suitable systems, and reusing the pattern at another site.
• Chapter 5 gives five questions to ask of any proposal, how to choose a first decision the team can own, and what should count as evidence.
• Appendix A maps the architecture to XMPro, component by component, with sources and proposed acceptance checks. Appendix B supplies working aids for a first application, and a glossary closes the book.

The station is an illustrative teaching example throughout. Its plans and results establish no operating limit, hydraulic result or measured improvement, and the book is explicit that any reduction in effort or improvement in performance needs evidence from the implementation.

Read the summary, then the book

The definition, the pumping-station example, the decision definition, the participation levels and the five recognition questions are laid out on the Software-Defined Operations page. The full 44-page PDF is available below. It pairs with two earlier XMPro papers: Software-Defined Automation's optimization imperative and How do agents make decisions under uncertainty?

This book was prepared with the assistance of artificial intelligence tools. Pieter van Schalkwyk is the author and accountable document owner.