Why this blog

I turn information systems into drivers of business performance. My path, which runs from software development to architecture governance, has led me to one conviction: the success of a transformation depends as much on how teams organize themselves and collaborate as on the technology choices that are made.

This blog exists to make technology understandable. The subject has a reputation for being difficult, and part of that difficulty is manufactured: specialized vocabulary, unexplained acronyms and reasoning left implicit end up reserving understanding for a circle of insiders. That closing-off, usually called gatekeeping, is not a technical inevitability. Undoing it is what I set out to do here, by explaining each notion rather than assuming it is already known.

I also write because I enjoy learning and passing on what I learn. Writing an article forces me to understand a subject better than practicing it does, and publishing it lets others save the time I spent untangling it.

What drives me, ultimately, is opening the black box of technology, so that executives and technical teams speak the same language and turn their IT challenges into lasting advantages.

What you will find here

Articles are sorted into three sections.

Agentic AI and LLMs. Artificial intelligence systems that can act autonomously, and large language models: architectures, integration protocols, tools, field feedback and observed limitations.

Enterprise Architecture and IT. Designing and evolving information systems: capability mapping, application architecture, API governance, and alignment between strategy and its execution.

Consulting & Transformation. Consulting practice and change management: methods, team organization, adoption and steering.

My background

I have been practicing for twenty-four years, on a path that starts with writing code and moves toward architecture governance.

I started in 2002 as a Java software engineer. I then spent ten years as a tech lead, with technical responsibility for a team of fifteen people and for an entire internet application portfolio. Since 2016 I have been a solution architect and enterprise architect at onepoint, where I run technology consulting engagements for large organizations.

My work falls into three areas.

Strategy. Structuring an organization’s architecture function and defining its reference frameworks: founding principles, standards, patterns and governance. Two approaches anchor this practice. The first is Domain Driven Design, or DDD, which models a system from the language and the boundaries of the business it serves: it keeps architecture connected to the business, establishes a shared language across teams, and leads to treating architecture as a socio-technical object, that is, inseparable from the human organization that designs it. The second is EDGY, an enterprise design framework that articulates identity, architecture and experience: it comes into play mainly in a transformation context, where it provides a holistic view and locates the place of architecture within it.

Delivery. Auditing and modernizing complex systems, including aging monolithic applications, and designing target architectures along with the paths to reach them.

Enablement. Training teams and building their fluency in modern approaches: DDD, API-driven design, distributed architectures and, since 2025, agentic architectures.

One thread runs through all three: showing that architecture creates value where it is suspected of destroying it. In agile organizations it is readily seen as a top-down constraint that slows teams down. In fast flow approaches, meaning approaches that aim to shorten the delay between an idea and its release to production, architecture has to serve team autonomy rather than restrict it. And today, in agentic roadmaps, it becomes the condition for autonomous agents to fit into the information system without making it fragile. My work is to make architecture hold in these contexts, as an accelerator rather than a control gate.

I have a particular taste for the subjects the market leaves aside because they are judged too complex, too specific or too unprofitable to take on. They are often the ones whose resolution unlocks the most value, precisely because no one has tackled them.

Finally, I keep from my years as a developer a taste for the concrete: I test the tools I write about, I read the code, and I build working demonstrators rather than stopping at diagrams.

Get in touch

The simplest way is to reach me on LinkedIn, where I post regularly and answer messages. You can also read my profile on the onepoint website.

Disclaimer

The views published on this site are my own. They represent neither the position of onepoint, my employer, nor that of its clients.