I work where strategy meets the systems that have to carry it: the landscape as it actually is, the decisions that shape it, and the organisation that has to live with the result. Thirty years in energy, aviation, maritime and public-sector environments have taught me that the hard part is rarely the target picture.
From enterprise and system architecture to process redesign, data governance and system integration.
Most of my work starts with a question that sounds technical and is not: why does this process take three weeks when everyone agrees it should take three days? The answer is usually spread across systems, contracts, budgets and habits. Making that visible is the first job.
I then translate the findings into a small number of decisions that someone must own: which system holds the truth, which capability is bought and which is built, what may run automatically and what must wait for a person. A target architecture is only useful if these decisions are explicit, dated and reversible when the facts change.
Over the last two years the same questions have reached AI. Agents can analyse, classify and propose, but they can also act on a system that was never designed for them. My focus is on where autonomy should stop, how each step is validated, and how every outcome can be traced back to the input and the rule behind it.
Enterprise and system architecture, process redesign, data governance and system integration.
A target picture makes a programme feel finished. It is not. The architecture is what happens when the picture meets budget cycles, contracts, legacy data and the people who were not in the workshop. If the diagram cannot survive those, it was a presentation, not a design. I ask early what will be different in six months, and who will notice.
A model that answers well in a demo can still fail in production for reasons that have nothing to do with the model: no clear input contract, no check on the output, no path for a person to override it, no record of what was decided. Putting an agent into a process forces the organisation to define those things. That is useful work, even if the agent turns out to be the smallest part.
Once a market product is selected, its shape is mostly fixed. Architecture therefore belongs in the tender, not after it. Requirements for integration, data ownership, exit options and observability should be written as conditions, not wishes. A product that cannot meet them as a black box should not be bought, however good the demo.
Map the current landscape, its entropy and its technical debt. Separate what the business needs from what IT can deliver today.
Define the target architecture, its principles and integration patterns. Validate them against sector reference models and the people who must own them.
Migrate in phases with the Strangler Fig pattern. Build the new around the old, with explicit go/no-go criteria per plateau.
Transfer capability into the organisation. Documented decisions, teams that run on their own, and a result that outlasts the engagement.
An AI step is only useful when it sits inside a process that the organisation understands, controls and can audit. I design AI as a step in a flow, with defined inputs, validated outputs and a clear point where a person decides.
One orchestration layer over systems of record, models and people. Flows and agents run inside governance and quality checks, and every step is observable and auditable.
Business and IT should be looking at the same picture. I model processes visually in BPMN, connect them to the architecture in ArchiMate, and make sure the diagram is the same thing that runs in production.
Gateways, approvals, escalation paths and failure routes, drawn so that business owners can validate them without reading code.
A process is only useful if the systems behind it are visible. I connect BPMN processes to application and data components in the architecture model.
Flows that call systems, run AI steps and wait for people. Designed for reuse, versioned, and deployable through a controlled release process.
New processes run next to the old ones and take over step by step. Each plateau has a definition of done before the next one starts.
Roles that sat between the boardroom and the systems that run the business, in energy, transport, aviation, maritime, manufacturing, education and media.
Architecture direction for a central network realisation platform.
Application landscape and HRM IT portfolio.
Blueprints and project start architectures for agile teams.
Business digitalisation and the move to S/4HANA.
Order-to-cash and financial SaaS landscape.
Solution architecture for production and shared services.
Leading and professionalising the IT organisation.
IT management and architecture at the corporate level.
Target architectures, architecture principles and project start architectures. Bounded contexts, and the reduction of system entropy and technical debt.
Architecture mandates, guardrails and gatekeeping for procurement and change. Advising design authorities, enterprise architecture and boards.
API-first and event-driven architecture, functional components and anti-corruption-layer patterns, and operational data stores as the single source of truth.
Agentic AI, GenAI and predictive AI in processes. Layered models with autonomy boundaries, human-in-the-loop decisions and auditability.
SAFe, ERP and SaaS transitions (SAP S/4HANA, Oracle Cloud), vertical-slice proofs of concept, phased migration and programme leadership.
BPMN, value streams, APQC and Lean Six Sigma. ERP selection and translating business needs into robust IT solutions.
Available for interim assignments, enterprise architecture, AI and automation design, and programme leadership.
A full CV is available on request.