Before the Title: What Makes Someone an Architect?

I’m not actually sure when I became an architect.

I know when I earned my first architect certification. I know when Architect officially appeared in my job title. But I was doing the work before either of those things happened.

In fact, some of the companies I worked for didn’t even have an architect position. They had to create one, or at least start calling me one, because that was already the role I had grown into.

During the Dreamforce Architect Keynote, Salesforce announced an updated Well-Architected Framework. When I started exploring it, one section in particular caught my attention: Who should use this framework?

The list includes Salesforce Architects, of course. But it also includes Salesforce Admins, Development Leads, Consultants and Partners, and AI and Agentic Specialists.

This is an architectural decision framework, but Salesforce isn’t suggesting that only people with Architect in their titles should use it. It’s intended for anyone responsible for the architectural quality of a Salesforce solution.

Admins make decisions about security, automation, data models, and how the platform will be maintained. Developers establish patterns that can support future growth or make it harder. Consultants help customers decide what to build, what not to build, and how Salesforce should fit into the rest of their business. AI specialists are making decisions about data access, governance, autonomy, and oversight.

There are far more people making architecture decisions than there are people with Architect in their job titles.

That idea connected with another conversation I’d had recently.

A friend of mine hesitated when I referred her for an architect role. She didn’t think of herself as an architect. And I was honestly surprised.

She’s been designing solutions, creating roadmaps, integrating third-party tools, and helping companies make decisions about what to build and when for years. She understands how the pieces fit together and how a decision in one part of the business will affect another.

Maybe Architect wasn’t her title, but it was absolutely the work.

I told her, “You’ve been an architect for years.” She just hadn’t been calling herself one.

Those two moments left me thinking about the same question from different directions.

What actually makes someone an architect?

Is it a certification? A job title? The work you’re doing? The kinds of questions people trust you to answer?

And how many people are already making architectural decisions without recognizing that architecture has become part of their role?

Is It the Certification or the Title?

I’m certainly not going to argue that certifications don’t matter. I have 31 of them, and I’ve learned something valuable from every certification path I’ve completed.

Certifications can give us structure. They introduce concepts we may not encounter in our current roles, help us identify gaps in our knowledge, and give us a shared language for discussing our work. They can validate what we know and give us the confidence to pursue something new.

But passing an exam doesn’t automatically make someone an architect.

An exam can test whether you understand a particular platform, pattern, or concept. It can’t fully test how you respond when the requirements are incomplete, three teams have competing priorities, or the solution someone requested isn’t really going to solve the problem.

It can’t show whether you’ll ask the uncomfortable question, recognize a risk no one else has noticed, or explain a complicated tradeoff in a way that helps people make a responsible decision.

A title can’t tell us all of that either.

Titles do matter. They affect our opportunities, our authority, our compensation, and whether we’re invited into the conversations where important decisions get made. People doing architectural work deserve to have that work recognized.

But titles vary wildly between organizations. One company’s Senior Salesforce Administrator may be doing the same work as another company’s Solution Architect. A developer may be making decisions about integrations, security, data, and scalability without anyone using the word architect. A CRM leader may be defining a multiyear platform strategy while still being described primarily as the person who manages Salesforce.

A certification can validate part of what you know. A title can recognize the responsibility you carry. Neither one tells the whole story.

Maybe It’s the Work and the Questions

If it isn’t only the certification or the title, maybe architecture is better understood through the work itself.

I think it shows up in the scope of the decisions someone is making.

An architect doesn’t just think about whether a solution will work. They think about how it fits with everything around it. They consider the people who will use it, the systems that depend on it, the data moving through it, and the team that will have to support it when the original project is over.

They don’t just ask whether we can build something. They ask whether we should.

What business problem are we really trying to solve?

Who owns this process and its data?

What other systems or teams will this decision affect?

What happens when the volume increases?

What happens when the business process changes?

Who should have access?

How will we maintain and support this?

Are we solving one request, or are we creating a capability the organization will need again?

What are we making easier or harder for the people who come next?

You don’t need Architect in your title to ask those questions.

You might be the admin who receives a request for another field and stops to ask why the information is needed, whether it already exists somewhere else, and how it will be used.

You might be the developer who thinks beyond making an integration work and considers what should happen when the other system is unavailable.

You might be the business analyst who realizes that five separate requests are really symptoms of the same broken process.

That’s architectural thinking.

Architecture often starts before anyone opens Salesforce Setup or writes a line of code. It starts with understanding what we’re actually trying to accomplish and making intentional decisions about how we’ll get there.

There Isn’t Just One Kind of Architect

Part of the confusion may be that we talk about “an architect” as though it’s one specific job. It isn’t.

There are several kinds of architects, and there’s often quite a bit of overlap between them.

Architect lens	What they’re primarily thinking about
Business architect	How strategy, business capabilities, processes, and organizational needs connect before a technology solution is chosen
Solution architect	How people, processes, data, and technology come together to solve a particular business problem
Technical architect	How the solution will work across systems, integrations, security, performance, and scale
Data architect	How data is modeled, governed, moved, understood, and used
Enterprise architect	How business capabilities, platforms, standards, and technology investments align across the organization
Domain architect	How decisions are made within a specialty such as analytics, integration, security, commerce, or a particular platform

These aren’t rigid boxes.

A solution architect needs to understand technical constraints. A technical architect makes choices that affect the data. A data architect needs to understand how the business uses that information. A business architect connects organizational strategy to the capabilities needed to deliver it. An enterprise architect relies on the expertise of people working more deeply within each platform and domain.

In smaller organizations, one person may wear several of these hats. In larger organizations, the responsibilities may be divided across multiple teams. Someone may also move between these lenses depending on the problem they’re trying to solve.

The point isn’t to decide which kind of architect is more important. It’s to recognize that architectural work can take different forms.

Someone may have the title Analytics Developer because dashboards are what everyone sees. But if they’re also defining semantic models, reconciling sources, establishing shared business definitions, tracing data lineage, and determining how information should be governed, they may be functioning as a data architect.

Someone else may be called a Salesforce Administrator while setting platform standards, evaluating technical debt, connecting business requests to a broader roadmap, and helping leaders understand the consequences of their decisions.

The title often describes the most visible output. Architecture lives in the decisions underneath it.

You Might Be Closer Than You Think

None of this means that making one significant design decision automatically qualifies someone for every architect role. Different roles require different kinds of experience, and there’s always more for all of us to learn.

But I also don’t want people to dismiss years of relevant experience simply because no one used the word architect while they were doing it.

If more than one of those sounds familiar, architecture may already be part of how you work.

The shift often starts when the question changes from “How do I build this?” to “What should we build, why should we build it this way, and what will this decision mean?”

You don’t need to have every answer before you can contribute as an architect. Architects aren’t expected to be the deepest expert in every technology or the smartest person in every room.

A big part of the job is knowing which questions need to be answered, who needs to be involved, and how to bring those perspectives together. It takes enough breadth to see the bigger picture, enough depth to recognize risk, and enough humility to know when you need someone else’s expertise.

Architecture isn’t about knowing everything. It’s about helping people make thoughtful, connected decisions.

What Does This Mean When You’re Looking for Your Next Role?

This question matters beyond deciding what to call yourself.

It matters when you’re reading a job description, updating your résumé, or trying to explain your experience in an interview.

Don’t compare only the title in the job posting to the title you currently hold. Look at the responsibilities.

Have you solved problems of a similar scope?

Have you made decisions with similar consequences?

Have you worked across teams or systems?

Have you created a roadmap or helped define what should come next?

Can you explain the options you considered, the tradeoffs you made, and what changed because of your recommendation?

Which parts of the role have you already performed, even if you were doing them under a different title? Which parts would be a reasonable next stretch?

You don’t need to have held the exact title before. You need to be able to show how your experience has prepared you for the work.

Architecture is best demonstrated through stories, not declarations. Instead of simply saying, “I was the architect,” talk about what the organization believed the problem was, the questions you asked, the constraints you uncovered, and the choices you helped people make.

Explain how you looked beyond the immediate request and what became possible because of the direction you established.

Sometimes the biggest career gap isn’t between the experience you have and the role you want. It’s between the work you’ve done and the language you use to describe it.

Recognizing the Work

So what actually makes someone an architect?

To me, an architect is someone trusted to look beyond the individual piece, understand how the parts connect, and help people make decisions that will hold up over time. A certification can strengthen that ability, and a title can recognize it, but the work usually begins before either one arrives.

I don’t think my friend became an architect when I referred her for the role.

She didn’t become one when someone agreed to interview her, and she won’t suddenly become one if Architect appears in her next job title.

She had already spent years designing solutions, integrating systems, setting roadmaps, and helping organizations make decisions about what came next.

She was already doing the work. She just needed to recognize it.

Maybe you aren’t ready for every architect role. None of us are. But if you’re looking beyond the immediate request, asking how the pieces fit together, making tradeoffs visible, and creating direction that other people can build from, you may be closer than you think.

Sometimes becoming an architect isn’t about earning permission to use the word.

Sometimes it’s about recognizing the work you’ve already been trusted to do.