Eight months after selecting their EA tool, a medical device company asked us to help them add compliance features. They'd chosen a popular platform, implemented it, trained their team, and started building out their architecture — and only then did someone ask the question that should have come first:

"Does this actually support 21 CFR Part 11?"

The answer was no. Not really. The tool had some audit trail capabilities, but not the specific controls that FDA expects from electronic records systems. They had two options: spend six months validating the gaps and implementing workarounds, or switch tools and lose eight months of work.

They switched. I don't blame them.

How This Happens

Compliance gets added late because it's not the thing that wins tool selection demos. Nobody demonstrates audit trail configuration at a software evaluation. Nobody gets excited about electronic signature workflows. They demo capability mapping, integration diagrams,漂亮的仪表板.

So compliance features get deferred. "We'll handle that during implementation." Except implementation teams optimize for getting to go-live, not for regulatory requirements. The compliance gap gets discovered six months after launch, when someone's first audit preparation reveals it.

⚠️ What a compliance gap actually costs

• 6-12 months of rework to add missing controls
• Vendor contracts renegotiated or terminated
• External validation consultant ($150K+)
• Audit delays and findings
• In some cases: product launch delays

The Questions That Should Come First

If you're evaluating EA tools for a regulated environment, these should be your first questions — before demos, before pricing discussions, before anything else:

1. Does the tool have a documented audit trail for all changes?

Not just "we log changes" — but timestamp, user attribution, and change description.

2. Can you prove who made each change and when?

21 CFR Part 11 requires this for any record that could be considered part of a regulatory submission.

3. Are electronic signatures supported?

If EA documentation is used in compliance workflows, your tool needs this.

4. Can you prove your data hasn't been altered?

Immutable audit trail, not just "access controls."

5. Has the tool been validated in a regulated environment before?

Ask for case studies. Not vendor claims — actual customer validation evidence.

What Compliance-First Actually Looks Like

Some tools claim compliance capabilities as checkbox features. You turn them on, they exist, everyone's happy. That's not what compliance-first means.

Compliance-first means every design decision traces back to regulatory requirements. Audit trails aren't added — they're the foundation. Electronic signatures aren't optional — they're part of the standard workflow. Data integrity isn't configurable — it's enforced.

When compliance is an afterthought:

• You get a tool with compliance features bolted on
• Those features may not work together smoothly
• Integration with other validated systems gets complicated
• Your validation documentation becomes much longer and harder to write

When compliance is the foundation:

• Every feature was designed to support compliance requirements
• Documentation for validation already exists
• Integration with other systems respects regulatory constraints from day one
• You can actually demonstrate compliance during audits, not just claim it

The Price of Late Discovery

That medical device company I mentioned at the start? They made the right choice switching tools, but it cost them:

• Eight months of repository work they couldn't use
• The original tool license they couldn't recover
• A three-month implementation delay while they started over
• A validation consultant they hadn't budgeted for

The original tool selection had saved what seemed like significant money. The compliance gap cost them more than the difference.

If you're in a regulated industry and evaluating EA tools, ask about compliance first. Not because regulatory requirements are the most exciting part of the tool — but because the cost of getting it wrong is higher than almost anything else in your implementation.

The question that should come first: when does compliance become a first-class concern in your architecture practice? Is it something you think about from day one when selecting tools, or does it surface later — sometimes much later?

I'm genuinely curious how others are handling this. Not to tell anyone what to do — just trying to understand what actually works in different regulated environments. What approaches have made compliance feel less like a scramble and more like something that's just part of how the architecture practice works?