DEV Community: Oliver Fries

The Digital Product Passport Is Moving From Concept to Execution

Oliver Fries — Wed, 25 Feb 2026 07:41:21 +0000

For a long time, the Digital Product Passport felt theoretical.

Standards discussions. Working groups. Position papers.

Now it’s different.

Budgets are allocated. Platforms are being selected. Pilot projects are turning into implementation roadmaps. The question is no longer if.

It’s:

How do we actually deliver this in a real system landscape?

The Standard Is Not the Hard Part

The Digital Product Passport builds on the Asset Administration Shell.

The specification is detailed.The semantic structure is defined.

Interoperability is a serious effort. But in industrial reality, the friction is rarely the standard itself.

It’s this:

Product master data in ERP
Technical attributes in legacy .NET systems
Bills of material in PLM
Units that differ between systems
Field names that evolved over fifteen years
“Digital” processes that still rely on Excel exports

You don’t “introduce AAS” into that environment.
You extract data from brownfield systems.

You map fields to semantics.

You normalize units.

You validate mandatory elements.

You automate the process.

That is the actual work.

Platforms Are Being Bought. The Integration Layer Is Missing.

Many companies are currently evaluating or purchasing DPP platforms.

That step makes sense.

But a platform does not create structured data where none exists.

The real gap is not on the visualization layer. It is on the delivery layer.

What the industry needs now are:

Mapping libraries
Validation mechanisms
Deterministic submodel builders
CI-integrated generation processes
Clear ownership of source fields

Not more slides.

Engineering-grade building blocks.

Why Open Source Matters at This Stage

DPP is becoming infrastructure. Infrastructure should not depend entirely on opaque vendor logic.

If regulatory compliance depends on generated submodels, then teams need to know:

Where each value comes from
How it is transformed
Which rules validate it
How it is versioned

Open source enables that transparency.

You can inspect it.

You can test it.

You can adapt it to your landscape.

When regulation meets software delivery, black boxes become risk factors.

I Built FluentAAS

FluentAAS was not created to “explain AAS.”

It was created to build it.

In real .NET environments. With legacy systems. Under delivery pressure.

I needed a way to:

Build submodels in a structured, typed manner
Encapsulate mapping logic in code
Validate mandatory fields early
Integrate generation into CI/CD
Version output alongside application releases

FluentAAS follows a simple idea:

If DPP becomes part of compliance, submodels must be reproducible artifacts. Not manual exports.

It is not a platform. It is not a full DPP solution. It is a building block.

Because the ecosystem needs composable components, not monolith tools.

Legacy Is Not the Problem

There is still a reflex in many discussions:

“DPP means we need a new architecture.”

In most industrial environments, that is not realistic.

Legacy systems often contain the most reliable production data in the company.

The real issue is uncontrolled integration.

Rewriting a production-critical .NET system to “enable DPP” introduces risk without solving the mapping problem.

You stabilize first. You define clear boundaries. You build a controlled extraction layer.

Then you map and validate into AAS.

Legacy is not replaced. It is integrated under control.

What a Serious AAS Pipeline Requires

If DPP becomes regulatory infrastructure, the pipeline must be:

Deterministic
Reproducible
Automated
Versioned
Validated

That means:

Clear source ownership per field
Explicit transformation logic
Unit normalization at a defined boundary
Mandatory field validation before export
CI-integrated generation
Traceable versioning tied to product state

If you cannot regenerate the same submodel for the same product version tomorrow, you do not have compliance-grade infrastructure.

You have a snapshot.

The Shift That Is Happening

The conversation is slowly changing.

From:

“How do we understand the standard?”

To:

“How do we build the integration layer?”

That shift is necessary.

It requires engineers.

It requires discipline.

It requires real tooling.

The DPP ecosystem will mature through libraries, SDKs, validation tools and working pipelines.

Not through architecture diagrams alone.

Closing Thought

Momentum is real.

Now the industry needs delivery capability.

The Digital Product Passport will not be implemented by strategy documents.

It will be implemented by engineers who take responsibility for the last mile:

From legacy data to validated, reproducible AAS submodels.

If you are building in this space, focus on the pipeline.

That is where success or failure will be decided.

The Core Knowledge Every Senior C#/.NET Developer Must Master in 2026

Oliver Fries — Thu, 19 Feb 2026 08:52:18 +0000

$20,000 per hour. That's what one misconfigured garbage collection setting cost a manufacturing client of mine — not because the code was wrong, but because nobody on the team understood what the runtime was doing beneath the surface.

The application worked fine in dev. It passed all tests. It even survived staging. But under real production load — 4,000 requests per second hitting a high-throughput API — GC pauses started cascading, response times spiked, and the production line ground to a halt.

The fix took 45 minutes. Finding someone who understood the problem took three weeks.

This is the gap I keep seeing when companies ask me to assess their senior .NET developers. They can write clean code. They know dependency injection. They use async/await correctly. But when things break at scale — when the runtime, the network, or the database pushes back — they're out of their depth.

So here's what actually separates a senior C#/.NET developer from a mid-level one in 2026. Not more syntax. Not more frameworks. The deep, structural knowledge that makes the difference between code that works and systems that survive.

Runtime and Memory — Stop Fighting the CLR, Start Mastering It

Junior developers write code. Senior developers understand how that code behaves inside the runtime. That distinction sounds abstract until your API starts dropping requests because Gen 2 collections are pausing your threads for 200 milliseconds.

A senior .NET developer in 2026 needs to understand generational garbage collection — not as a textbook concept, but as an operational reality. Gen 0, Gen 1, Gen 2, ephemeral segment promotion, Large Object Heap fragmentation, Server GC vs Workstation GC trade-offs. These aren't academic exercises. They directly impact your p99 latency under load.

The developer who can read a GC trace and explain why throughput dropped at 3 AM is worth more than ten developers who can implement a clean repository pattern.

And it doesn't stop at garbage collection. Allocation-aware async programming is now essential. Knowing the difference between ValueTask<T> and Task<T> isn't trivia — it's a performance architecture decision in async-heavy endpoints. Most mid-level developers use async. Seniors measure allocation pressure and optimize for it. They know about hidden allocations in async state machines. They use pooling patterns where it matters.
Then there's zero-copy processing. Span<T>, Memory<T>, ArrayPool<T> — these aren't niche tools for framework authors anymore. If your service parses JSON, processes streams, or handles binary protocols, zero-copy patterns are the difference between writing parsing code and writing infrastructure that scales.

Here's the thing: none of this shows up in a typical coding interview. And that's exactly why so many teams discover these gaps in production.

Advanced C# Mastery — Beyond Syntax to Architectural Leverage

Modern C# (12+) isn't about syntactic sugar. Every feature worth mastering is an architectural lever.

Take source generators. Reflection is expensive — at runtime, it's slow; at scale, it's a bottleneck. Senior developers don't just avoid reflection. They replace it. They write source generators for validation, generate serializers at compile time, and eliminate entire categories of runtime overhead. In 2026, compile-time code generation is a performance architecture decision, not a nice-to-have.

Default interface methods are another area where the gap shows. For teams maintaining SDKs or public APIs, understanding API evolution without breaking changes — including conflict resolution in interface hierarchies and the difference between virtual and static dispatch — is essential. Mid-level developers see it as a language feature. Seniors see it as a versioning strategy.

Immutability isn't aesthetic — it prevents concurrency bugs in distributed systems before they ever reach production. Required members, init properties, primary constructors, records with domain semantics — these aren't about writing prettier code. In a distributed system where multiple services touch the same data, immutable objects are your cheapest concurrency safeguard. I've watched teams spend weeks debugging race conditions that simply couldn't exist with properly designed immutable aggregates.

Architecture — Designing for Change, Not Just Compilation

This is where the mid-to-senior gap becomes a canyon.

Senior engineers don't "add services." They design consistency boundaries. They think about where transactions end, where eventual consistency begins, and what happens when a message gets delivered twice.

Clean Architecture with vertical slices has largely replaced the old layered monolith approach — feature folders, MediatR pipelines with behaviors, avoiding anemic domain models. The goal isn't architectural purity. It's enabling change without ripple effects.
DDD aggregates matter here, but not as an abstract pattern.

Aggregates define transactional limits. Domain events flow inside the boundary. Invariants are enforced through construction. If your "aggregate" is just a fancy name for an entity, you've missed the point.

And then there's the pattern that separates production-grade systems from demo-grade ones: Inbox/Outbox with idempotency. Reliable message publishing, deduplication tokens, handling at-least-once delivery semantics. This is where many mid-level designs collapse in production. They work perfectly until the network hiccups, a message gets delivered twice, and suddenly your customer has been charged three times.

One more thing I see senior developers get right: modular monoliths as a strategic scaling step. Before microservices, before Kubernetes, before the complexity explosion — deployable modules, internal ABI contracts, gradual extraction strategy. Premature distribution is a senior anti-pattern. The best architects I've worked with over 17 years know when not to distribute.

Performance Engineering — Measurement Over Guessing

Performance in 2026 is no longer optional. It's expected. And "it feels fast" is not a measurement.

With .NET 10, Native AOT and IL trimming are production-ready tools. Startup time reductions of 50%+ are achievable. But seniors understand the trade-offs: reflection limitations under AOT, ILLink trimming behavior, and when AOT is appropriate versus when it breaks dynamic systems. Not every service should be AOT-compiled. Knowing when to use it is the skill.

Profiling the runtime is a core senior competency. dotnet-trace, tiered compilation analysis, JIT inline decision insights, GC pause diagnostics — not just "it's slow," but why it's slow. I've seen teams spend days adding caching to "fix" performance issues that were actually caused by oversized Gen 2 collections. They were optimizing the wrong layer entirely.
Most mid-level developers know EF Core works. Seniors know how EF Core fails under load. Split queries vs single queries, ILazyLoader pitfalls, N+1 detection, owned types, projections, keyless entities, second-level caching strategies — this is where database performance lives or dies. The gap between "it works in dev" and "it scales in production" is filled entirely with this kind of knowledge.

Distributed Systems — Because That's the Default Now

Microservices, event-driven architectures, cloud-native deployments — distributed systems aren't a specialization anymore. They're the default.

Message-driven architecture with MassTransit sagas, long-running workflow orchestration, correlation IDs, idempotent consumers — this is production infrastructure. Not simplistic background job queues. The difference matters when your order processing pipeline handles 50,000 events per hour and one consumer crashes mid-saga.
Ordered and reliable messaging adds another layer. Azure Service Bus sessions, optimistic concurrency with RowVersion, saga state persistence strategies. These patterns aren't optional when business logic depends on message order.

And then there's the REST vs gRPC question. REST is convenient. gRPC is intentional. Protobuf-net.Grpc performance benefits, bidirectional streaming patterns, Envoy proxy integration, service mesh resilience — seniors choose the right protocol for the problem, not the one they're most comfortable with.
The Security and Testing Gap Nobody Talks About
Two areas that consistently separate true seniors from experienced mid-levels: security and testing maturity.

Security in 2026 is protocol-level and supply-chain aware. OAuth 2.1 with PKCE, DPoP, JAR, PAR — these aren't buzzwords. They're requirements for SPA + microservice hybrid architectures. Policy-based authorization internals, claims transformation, dynamic policies — not just slapping [Authorize] on a controller and calling it done.
Supply chain security has become non-negotiable: SBOM generation, dotnet list package --vulnerable, dependency lifecycle governance. If you don't know what's in your dependency tree, you don't control your attack surface.

Testing maturity reflects architectural maturity. Contract testing with Pact, property-based testing with FsCheck, chaos and resilience testing with fault injection — these go far beyond "green tests." And observability as a test strategy — OpenTelemetry instrumentation, trace correlation across gRPC calls, debugging distributed latency chains — that's not DevOps. That's architecture validation.

What You Can Do Tomorrow

If you're hiring or evaluating senior .NET developers, three concrete steps help.
First: **Ask about runtime behavior, not just code quality. "What happens during a Gen 2 collection?" tells you more than any LeetCode problem.
**Second: Present a distributed systems failure scenario. How does the candidate reason about message delivery, idempotency, and consistency boundaries? This reveals system thinking — or the lack of it.
Third: Look at the testing approach. Does the candidate write tests that prove the system works, or tests that prove the system survives failure? That distinction is everything.

After 17 years in the software industry, most of them spent in production-critical environments where downtime means real money, I've learned that the title "Senior Developer" means very little. What matters is the depth beneath the title.

In 2026, being a senior .NET developer isn't about knowing more syntax. It's about understanding the runtime, the network, the database, and the failure modes in between. Mid-level developers write clean code. Seniors design resilient systems. Mid-level developers use async. Seniors understand async internals. Mid-level developers deploy microservices. Seniors understand distributed failure modes.

The difference isn't code quality — it's system thinking.
The developers who invest in understanding what happens beneath the abstractions — the CLR, the GC, the network, the message broker — are the ones who build systems that survive contact with reality.
And in my experience, those developers are painfully rare. Which is exactly why knowing what to look for matters.