Values intent and outcome over method and precedent.
This site (the original one, the WordPress one) opens with a name and a posture. The name is “the process pragmatist.” The posture is that intent and outcome matter more than method and precedent. This piece exists to explain what that means before any of the rest of the writing assumes you already know.
What process pragmatism is.
Process pragmatism is the position that processes are tools, not commandments. A useful process is one that produces a better outcome than the alternative for the situation at hand. A useless process is one that survives because nobody has thought to question it — or, worse, because questioning it would be politically expensive.
The pragmatist asks two questions of every process:
- What is this process for — what outcome does it exist to produce?
- Is the situation at hand close enough to the situation the process was designed for that we should expect it to work?
If both answers are clear and positive, follow the process. If either is uncertain, adapt. If both are negative, the process is the wrong tool and a different one (or no formal process at all) is the right answer. None of this is a licence to improvise; it's a discipline of conscious application.
Why it matters for cloud.
Cloud services move fast, get procured strangely, and decay slowly. The processes that were calibrated for an on-premises world — the procurement chain, the architecture review, the change-advisory board — either trip up the new services or get bypassed entirely. Both outcomes are bad.
Process pragmatism is the response. Keep the processes that produce the right outcome; adapt the ones that don't; design new ones where the old ones don't apply. The discipline isn't “do less process” or “do more process.” It's do the right process.
Processes are tools, not commandments. Pick the right tool for the job; put it down when the job is done.
What this site is going to argue.
Most of the writing here applies process pragmatism to one operational topic at a time. The eight chapters of opsasto are the structural frame; each chapter is a place where the pragmatic question gets asked. What does the BIA need to look like for this service? What does the support model need to include for this kind of risk? What does cutover mean for this kind of cadence? The answers vary; the discipline is consistent.
And a caveat.
The risk of pragmatism is that it slides into expediency. The defence against the slide is the second question above: what outcome is this trying to produce? As long as that question is being asked, the discipline holds. The moment it isn't, you have an excuse rather than a method.
Welcome. Take what's useful. Argue with the rest.