About
Practice and approach
What I do
I work on system architecture, data, integration, and operations. I connect a need to something people can use, observe, and evolve.
I aim to reduce the interventions needed for routine operation and make explicit the decisions for which someone must take responsibility.
How I work
I try to understand the reasons behind existing choices and the constraints faced by the people who made them before proposing a change.
I start with the capability we need and the actual constraints: usage, existing systems, cost, time, and available people. I look for a first useful implementation, then expand when the need justifies it.
I keep behavior, data, and operations close to their owner. I distinguish what the code intends, what a test exercised, and what was observed in operation.
I preserve the reasons that will let someone revisit a decision. A boundary should be explainable, then adjustable when conditions change.
Concrete choices
Giving a product responsibility for its data and resources so that it can evolve independently.
Separating update detection, a proposed change, and its application, so that observation alone does not trigger an action.
Keeping tools that fulfill their role and limiting an integration to the information a decision requires.
What I keep examining
The cost of rigor, the boundaries of automation, and how to pass on enough context to act. The Sphaera experiment shaped these questions and led me to reconsider some answers.