Context
Existing systems describe the operation: measurements, asset relationships, work history, procedures and the other information a decision needs.
Software-Defined Operations
Change how operations work.
When an operating requirement changes, a team may have to revise a calculation, reconcile a procedure, update an approval route, and find every affected use. The governing logic is spread across systems and people. This book gives that logic an identifiable definition in software, with explicit connections to the systems it uses, and follows one pumping-plan decision to show what the architecture means, how a controlled change works, and what the organization must maintain.
For operations leaders, engineering and systems teams, and business sponsors.
By Pieter van Schalkwyk, CEO of XMPro. 44 pages, five chapters, two appendices and a glossary.
Get the book (PDF)A short form, then the full PDF downloads.
What Software-Defined Operations means
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 idea 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, and the interfaces it depends on. The pumps, measurements and maintenance systems remain necessary. What changes is how the organization decides and coordinates their use as conditions and requirements change.
Decision & Coordination
The maintained logic establishes how to use that information: what to achieve, which requirements apply, how to evaluate alternatives, and how to arrange a permitted response.
Response
People, workflows and control systems perform their assigned actions and supply evidence of what happened. Local control keeps interlocks and protective functions.
One decision, many dependencies
One of three pumps at a drinking-water transfer station shows signs of deteriorating condition. Maintenance wants an inspection window. Operations must keep supplying the service reservoir while the pump is out. The remaining pumps behave differently, and energy prices and expected demand affect when the station should pump. The alert identifies a problem; the response depends on a decision that involves several systems and people.
Follow that response today and the logic turns up in six places: a monitoring threshold, an integration rule, a planning spreadsheet, an operating procedure, a supervisor's judgment and a shift handover. The station already has a decision process, even if nobody maintains it as a coherent whole. When the reserve requirement is revised, the work starts with investigation: which expression of the rule governs each use, and whether every affected use reflects the approved interpretation.
Changing an input and changing the decision definition are different kinds of work. The first asks what the operation should do now; the second changes how it determines its response.
The station is an illustrative teaching example. Its plans and results establish no operating limit, hydraulic result or measured improvement.
The decision definition
A decision definition is the maintained description and software representation of what a decision seeks, requires, may request and must record. At the station its scope is revising the pumping plan when relevant conditions change. Seven parts, each with a software representation the team can point to.
- 01
Objective and ranking
Maintain supply; compare energy cost among eligible plans.
- 02
Constraints
Apply the approved reserve and equipment requirements.
- 03
Context requirements
Use the right reservoir measurement, forecast and availability records.
- 04
Coordination
Align the inspection window, pumping plan and maintenance request.
- 05
Approval policy
Route the proposal to the responsible operations reviewer.
- 06
Permitted actions
Prepare a recommendation; initially leave submission to a person.
- 07
Evidence requirements
Preserve inputs, alternatives, the active definition, approval and outcome.
Choose how people and agents participate
Three capability levels describe participation within the same architecture, and they can coexist. Using an agent and granting permission to act are separate decisions; each action remains subject to its defined limits and approvals. A person can retain every consequential approval while the organization gains a clearer, more maintainable definition of the response.
The book names the levels Monitor & Predict, Advise & Guide and Coordinate & Autonomize. On the platform pages the same three steps appear as Monitor & Predict, Advise & Coordinate and Operate Autonomously.
Run a decision, then change its definition
Chapter 3 follows the pumping-plan decision under its active definition: identify the definition in use, assemble the context, hold the recommendation while a stale forecast is refreshed, evaluate the candidate windows, and route the proposal to the responsible reviewer. Then it changes the approved reserve requirement while keeping the input case fixed, and shows which result and which dependencies changed with it.
Seeing both operations together makes the separation assessable. The team can show where the response is defined, what a revision affects, and why the revised behavior is fit to use, including the work that cannot be confined to software configuration.
Five questions to ask of any proposal
A proposal should make its architectural claims inspectable. The questions apply to an existing application as much as to a new one: a workflow or integration platform may already implement the pattern. What matters is the relationships it actually maintains and the changes it can demonstrate.
- Where is the decision defined?
- The maintained rules, configurations, calculations, models, coordination and permissions that govern the response.
- What does it depend on?
- Input meanings and quality, applicable requirements, evaluation methods, action interfaces and their owners.
- What can change separately?
- An approved revision whose effects can be shown while other suitable parts remain stable.
- What evidence connects definition and use?
- The input case, active revisions, evaluated alternatives, approval, requested action and subsequent status.
- Who maintains and accepts it?
- Accountable ownership of the intended response, technical dependencies and operational use.
One argument, five chapters, two appendices
Why operational change becomes a systems problem
One pump, one inspection window, and a pumping-plan decision whose logic lives in six places.
What becomes software-defined
The definition, the three responsibilities, the decision definition, and what can change independently.
Run a decision, then change its definition
Select an inspection window under the active definition, then revise the reserve requirement on the same input case.
What changes for the enterprise
Coordinate across responsibilities, change the response while keeping suitable systems, reuse the pattern at another site.
Recognize the pattern and choose where to start
Five questions to ask any proposal, how to pick a first decision, and what counts as evidence.
Map the architecture to XMPro
Which XMPro components carry observation, context, evaluation, review, authority and evidence.
Working aids for a first application
A first-decision canvas, context and authority worksheets, a change test, reuse and baseline aids.
Glossary
The terms the argument uses, from action authority to freshness requirement, each pointing back to its chapter.
Where XMPro fits
Chapters 1 to 5 are vendor-neutral. Appendix A maps the architecture to the XMPro Agentic Operations Platform, component by component, with sources and proposed acceptance checks rather than claimed results. It is the architecture for agentic operations, not a replacement for it.
- Data Streams acquire observations, calculate, route and dispatch requests
- XMForge frames the decision, its value and its authority before build
- AI Flow and MAGS contribute to evaluation within explicit limits
- Front-Running Simulation returns scenario evidence before dispatch
- Causal AI explains the condition driving a recommendation
- App Designer, Recommendations and Workflow support human review and approval
Related reading: Software-Defined Automation's optimization imperative and How do agents make decisions under uncertainty?
Pieter van Schalkwyk
This book was prepared with the assistance of artificial intelligence tools. Pieter van Schalkwyk is the author and accountable document owner.
Make the next operational change understandable.
Read the full argument, then use the recognition questions and working aids to choose a first application and establish what would count as useful evidence.
