So You Want to Be an Architect, Huh? Really?

So You Want to Be an Architect, Huh? Really?

Everybody wants to be an architect… until it’s time to actually be one.

I know this because I spent most of my career doing exactly what a lot of engineers do: hanging on to the keyboard for dear life. Code is safe. Code is portable. Code gets you staffed. Especially as a consultant, the moment you stop coding, someone eventually says, “Drop the pretension—you’re a developer. Get in the repo.”

And honestly? For a long time, that survival instinct made sense.

But somewhere between yet another POC, yet another demo, and yet another “this almost works” architecture review, something finally clicked for me.

Architecture isn’t about diagrams.

It’s not about frameworks.

And it sure as hell isn’t about titles.

It’s about intent.

The Lie We Tell Ourselves

Most teams think they’re doing architecture when they’re really just doing implementation with opinions.

We write user stories.

We define acceptance criteria.

We argue about tools.

We debate logging libraries like it’s religion.

And then, when the system doesn’t behave the way we thought it would, we shrug and say, “Well… software is hard.”

That’s the lie.

The truth is: we often never made our intent explicit.

What I Mean by “Intent” (No, It’s Not Just Acceptance Criteria)

Acceptance criteria are fine. Useful, even. But they live too low in the stack.

Intent is higher-order.

Intent answers questions like:

• What must be true when this system is working?

• What evidence proves it works?

• What failure modes must we be able to explain?

• What questions should an operator be able to answer at 2 a.m.?

For example:

“If someone sends us a valid request and it never reaches Kafka or the database, we must be able to explain exactly where it failed and why.”

That’s intent.

Notice what’s missing:

• No tools

• No libraries

• No implementation details

Just an outcome that must hold true.

The Accidental Discovery: Intent Files

Here’s the part I didn’t plan.

I didn’t start my last project saying, “I’m going to build an intent framework.”

I was just trying to survive demos, POCs, and platform conversations without losing my mind.

So I started writing things down:

• What I expected to see in demos

• What “end-to-end” actually meant

• What questions I needed to be able to answer

Over time, those notes became intent files.

Not documentation.

Not governance.

Not process.

A thinking artifact.

And something interesting happened.

When a POC came in, I stopped asking:

• “What stack did you use?”

• “Did you follow the standard?”

Instead, I asked:

• “Does this satisfy the intent?”

• “Can it prove what it claims?”

• “Can I trace a real request through the system?”

That changed everything.

Why This Is Harder Than It Looks

I won’t sugarcoat it.

Capturing intent is work—especially for one person.

It requires:

• Owning ambiguity

• Admitting when your original thinking was wrong

• Iterating your intent as you learn more

• Staying hands-on long enough to know what matters

That’s why so many architectures quietly fail: the intent lives only in someone’s head. When that person leaves, clarity leaves with them.

Intent files externalize judgment.

They let the system outlive the architect.

Why This Matters for Younger Architects

Here’s the part I wish someone had told me earlier:

Your job as an architect is not to be right.

It’s to make the system falsifiable.

Intent files do that.

They give younger architects:

• A way to evaluate systems without tool bias

• A clear definition of success

• Permission to challenge implementations that “look good” but miss the point

• A repeatable way to think, not just copy patterns

This is how architecture becomes teachable, not mythical.

The Punchline

So yeah—maybe I’m pumping my chest a little.

But if there’s one thing I’ve learned the hard way, it’s this:

If you don’t write down your intent,

someone else will define it for you—

usually after the system is already broken.

So if you really want to be an architect…

not a diagrammer,

not a framework evangelist,

not a professional reviewer…

Start here:

State your intent.

Evaluate against it.

Iterate honestly.

Everything else is just noise.