Services
Agentic AI for systems engineering
When something changes in a system, the conversation often jumps straight to software or technology. But the real question is usually one layer up: how does this connect to the rest of your organisation?
The larger whole
Who works with it, which other systems depend on it, and what does your customer notice when things go differently? That overview of the whole is called enterprise architecture. It sounds abstract, and for most people it is. Yet everyone deals with it sooner or later, usually when a small change suddenly has consequences everywhere.
Why me
Since 1999 I have worked in aviation, avionics, and infrastructure, exactly at that layer. I am used to understanding a problem in the round first, then translating it into language the people who must work with it can use. That is how you fix it where it really sits, not only where it becomes visible.
What agents do here
With agentic AI this work now goes much faster. Agents produce architecture views in a short time from different perspectives: the user’s, the system’s, and the technology underneath. You see what you are talking about and what a choice will trigger, before you spend money on it.
How I look at it
In three layers — from operations to technical agreements.
Operational picture
A system rarely stands alone. It is part of something larger: an organisation, a fleet, a network of other systems. That is why I start with what that larger whole actually does. Which tasks are carried out, who depends on whom, and what changes when you adjust one part? I call that the operational picture. It is not about technology yet, but about the work the technology must support.
The system in context
Once that picture is clear, I place the system at the centre in it. What does it change, where does it connect, and where does it stop? Most products are not greenfield builds, but changes to something that already exists. Most of the real work is mapping those relationships: what influences what.
Technical agreements
Underneath lie the technical agreements everything must meet: standards, interfaces, and constraints that let parts fit together. You only notice them when something goes wrong, but they decide whether a change stays cheap or becomes expensive. Whoever surfaces them early adapts smoothly. Whoever discovers them too late pays the bill.
In systems engineering terms
The three layers align with the classic DoD Architecture Framework (DoDAF — the versions before the services extensions): Operational Views (OV), Systems Views (SV), and Technical Standards Views (TV). For each layer I describe architecture views and viewpoints (as in ISO/IEC/IEEE 42010), modelled in MBSE with SysML or UML in tools such as Enterprise Architect or System Architect, with traceability from operational need through requirements to interfaces and standards. Agents generate these views and keep them consistent from one underlying model.
Examples (DoDAF)
OV-1 (high-level operational concept), OV-5 (operational activities), SV-1 (systems interfaces), TV-1 (standards profile).