Services
I am a systems architect with experience across IT and OT environments, from engineering and security to architecture and consulting, including adversarial and industrial systems. That breadth allows me to approach systems from multiple angles: not just how they should work, but how they actually behave under load, failure, and adversarial conditions.
I design for systems that hold up in practice. That means accounting for the gap between models and reality, understanding where organisations resist their own architecture, and recognising that people have valid reasons not to follow the path the design assumes.
The aim is straightforward: systems that continue to function under real-world conditions. Especially when those conditions include people.
Systems architecture
I help organisations design and maintain their systems architectures. The design work is the visible part: understanding what the organisation needs, translating that into structures and responsibilities, making the technical and process trade-offs explicit. The maintenance work is less often named but just as important. An architecture encodes assumptions, and those assumptions drift as the system changes, the organisation changes, and conditions change. The gap between what the architecture says and what the system actually does is a normal consequence of time, not a sign that something went wrong. Managing that gap honestly is part of the work.
I start from what is already there, ask a lot of questions, and pay attention to three things that tend not to appear in job descriptions for this role: where the model no longer matches reality, where the organisation is resisting the architecture for reasons worth understanding rather than overriding, and where the people involved have stakes in the current system that a technically correct redesign usually does not account for. The result is an architecture that is not only sound on paper but sustainable in practice.
Security consulting and advisory
I help organisations work through security problems where the answer is not obvious and the trade offs are real. That can mean architecture reviews, risk assessments, incident retrospectives, or advising stakeholders who all want different things from the same system. Security, operational continuity, cost, usability, and delivery pressure all have to be balanced, usually by people operating with incomplete information and limited time.
I start with real security rather than checklist theatre. When the underlying controls genuinely work, compliance often follows naturally. What frameworks cannot tell you is whether those controls survive operational pressure, who maintains them once they become inconvenient, or how much risk the organisation is actually willing to carry when circumstances turn awkward.
Training and coaching
I work with security professionals, architects, and team leads through group training and one-on-one coaching. Group sessions are built around realistic exercises: participants work through problems based on real attack patterns and incidents, encounter genuine obstacles, and figure out together what to do when standard approaches do not work. The sessions can be deeply technical or more about process, but the method is the same. I prepare the environment, set the problem, and step back. My job in the room is to ask the questions that help people articulate what they are learning, not to explain what the right answer was.
One-on-one coaching goes deeper into specific technical challenges, architecture decisions, or the organisational side of the job: the politics, the pressure, the situations where the technically correct answer is not the one you can actually implement. Each session is shaped by what you are trying to get better at.
Simulations and exercises
I build simulation environments and run realistic security exercises. The environments model real system architectures, protocols, and adversarial behaviour, currently focused on OT/ICS, smart grid, and healthcare infrastructure. A simulation creates a space where participants can make decisions that fail, observe what breaks, and understand why, without the consequences being real. That is not a soft version of the work. It is the condition under which the honest questions get asked: what did we not anticipate, what assumptions turned out to be wrong, and what would we do differently.
The debrief is where the value accumulates. A simulation without a debrief is an experience that stays in the room. I design the debrief to turn what happened in the simulation into something the group can use the next day.
For a change
I teach mathematics and biology from time to time. On the surface it looks different, but the underlying question is the same: how do you set up an environment where someone can learn something that seems difficult, at the right level of challenge, without unnecessary obstacles or unnecessary hand-holding? Whether that is in a classroom or a coaching session, the answer involves paying close attention to the individual, stepping back from the instinct to explain, and trusting that productive struggle is how learning happens.
