From product intent to production: where the Enterprise Architect fits in AI-Native SDD pipeline

Over the last few weeks, I have been working on several pieces of the same engineering problem:

• OKF as an enterprise architecture knowledge foundation;

• architecture as Code;

• architecture validation through AI Skills and agents;

• Specification-Driven Development (SDD);

• AI-assisted development through CLI tools;

• and the integration of these mechanisms into PDLC.

Initially, I treated them as separate things. Actually, all these parts are not any individual tool. The interesting part is what happens when a Product Owner has an idea and that idea travels all the way to production? There are a lot of questions occurs:

• Who provides the architectural context?

• Where is the architecture decision made?

• Which artifacts become machine-readable?

• Where are they stored?

• When does the AI start writing code?

• Who decides whether the solution is acceptable?

• And the question I originally wanted to answer: where does the Enterprise Architect actually participate?

From my point of view, the answer is not to put the architect in front of every AI operation. The answer is to make architecture part of the development pipeline.

Start from the Product Owner, not an AI agent

A Product Owner has a new requirement.

For example:

“We need to add a new capability to the Digital currency application.”

The first temptation in an AI-assisted environment is to give this sentence directly to the coding agent. That is exactly what I don’t want. The first artifact should belong to the product side.

The Product Owner describes:

• what problem needs to be solved;

• why it is needed;

• expected business outcome;

• scope;

• constraints known at the product level;

• acceptance criteria.

At this point, there is no implementation. There should not be one. The output is an explicit intent.

The AI development loop starts with a proposal

The SDD (Specs driven development) process turns the product intent into a structured proposal.

Press enter or click to view image in full size

This is the first important boundary. The Product Owner owns the business intent. The development team does not invent the business goal while generating code.

The AI does not invent it either. The intent becomes an input to the engineering process. But we still don’t have enough information to design the solution.

We need architecture context.

This is where enterprise architect enters the process

The next question is:

What already exists in the enterprise that constrains this solution?

Here, the Enterprise Architect uses the artifacts and knowledge from the repository to frame the solution. The repository could be an OKF knowledge base containing the architecture context.

This is where OKF becomes more than a document repository. The agent needs to retrieve the relevant solution architecture context. Not the entire enterprise architecture. Only what matters for the specific change or feature the Product Owner requested.

The important word here is framing. The Enterprise Architect does not hand the developer a list of documents. The architect defines the architectural frame within which the solution should be designed.

For a regulated system, that frame includes:

• which systems are involved;

• which system owns which capability;

• which integration patterns are allowed;

• where components may be deployed;

• which security zones apply;

• which NFRs are mandatory;

• which enterprise standards apply;

• which previous architecture decisions constrain the design.

This is where Enterprise Architecture enters the development process.

The complete flow

At this point I can describe the whole process.

Press enter or click to view image in full size

This is the picture I was missing.

It is not:

SDD: Product Owner → AI → Code.

And it is not:

SDD: Product Owner → Architect → Developer → Code.

It is:

Product Intent → SDD → Architecture Framing → Machine-readable Architecture → AI-assisted Implementation → Verification → Architecture Control → Production → Architecture Feedback.

Architecture Framing is not the same as Solution Design

This distinction matters. The Enterprise Architect should not design every component of the solution. The architect establishes the architectural frame.

The Solution Architect works inside this frame. The Tech Lead decomposes the solution into implementation tasks. The AI helps both of them.

This prevents the Enterprise Architect from becoming the person who designs every REST endpoint and database table.

Architecture artifacts becomes machine-readable

This is where Architecture as Code becomes operational. The architecture framing produces something like:

system:
  name: digital-currency-service

boundaries:
  external:
    - cbr-platform
    - compliance-system

security:
  zone: ayz

constraints:
  - id: ARCH-API-001
  - id: ARCH-SEC-004
  - id: ARCH-RES-002

dependencies:
  - accounting-platform
  - aml-platform

The exact format is not the important part. The important part is that architecture is no longer only a document for a human to read. It becomes an artifact that tools can consume.

Now an AI Skill can ask:

Is this service allowed to call that system?

Is this component deployed in the correct zone?

Does this API follow the enterprise standard?

Does this design violate an existing ADR?

Does this change introduce a new dependency?

Does the proposed architecture contradict the current architecture model?

This is where architecture becomes executable. Of course, you can also visualize the architecture in diagrams such as drawio which you can edit later.

Store the architecture in Git

Generated machine-readable architecture should not disappear inside an AI session. It needs a durable home. For me, that means Git.

Now an architecture change has the same properties we already expect from software changes:

• version;

• author;

• history;

• diff;

• review;

• rollback;

• traceability.

This is the practical difference between “Architecture as Code” and writing another architecture document.

Architecture Decision

Not every decision needs the Enterprise Architect. This is where architecture impact assessment becomes important. A small local change should not stop the enterprise architecture team. A change that affects an enterprise boundary should. This gives us governance without turning architecture into a queue. The workflow might be as follows:

Human approval for architectural decisions

Some decisions must remain human-owned.

For example:

• introducing a new enterprise integration pattern;

• changing a critical security boundary;

• replacing a shared platform;

• accepting significant NFR degradation;

• introducing an architectural exception;

• changing a strategic technology decision.

The AI can prepare the analysis. It can compare alternatives. It can generate an ADR draft. It can also identify consequences. But the decision right remains explicit.

AI
 ├── analyse
 ├── compare
 ├── validate
 └── recommend
          │
          ▼
Corporate Architect
          │
          ▼
Architecture Decision

This boundary I want to preserve.

Architecture Drift Control

After implementation, another question appears:

Did the implementation remain consistent with the approved architecture?

The AI can check this continuously

If there is no architectural impact Vs If there is an architectural impact:

Press enter or click to view image in full size

This is where the enterprise architect participates again. Not because every change needs manual approval, because the architecture itself has changed.

A waiver is not a shortcut

This also changes how I think about architectural exceptions. An AI validator might find:

ARCH-SEC-004 = violated

The solution should not become:

warning → ignore → continue

The exception should have an explicit lifecycle:

Press enter or click to view image in full size

This is another place where the enterprise architect has a real responsibility. The architect owns the decision to accept the architectural risk. The AI can identify and document it.

The complete responsibility model

After looking at the entire flow, I would describe the roles like this:

Press enter or click to view image in full size

This table is more important than saying:

“The architect is involved in Gate 1 and Gate 2.”

It shows decision ownership.

Finally, the architect becomes an architecture control plane

This leads me to a different mental model. The Enterprise Architect is not another worker inside the AI coding loop. The architect is closer to an architecture control plane.

The architect establishes the boundaries. The engineering organization operates inside those boundaries. AI continuously checks the boundaries. Humans intervene when the boundaries themselves need to change.

This is what “AI-native architecture governance” means to me. AI-native architecture does not mean:

“Let the AI design the architecture.”

It also does not mean:

“Put an architect into every AI approval step.”

It means:

Press enter or click to view image in full size

The Enterprise Architect in an AI-assisted organization:

• owns the architectural frame;

• owns the important decisions;

• owns the constraints;

• owns the exceptions;

• owns the evolution of the enterprise architecture.

The machine handle the checking. The development teams handle implementation. The AI connects the two.

The important thing is that the architecture does not disappear when the specification becomes code. It remains explicit, versioned, machine-readable, traceable and continuously verifiable.

That is the direction I currently see for Architecture as Code and AI-native PDLC/ЫВВ methodology.