Explanation of Software Architect Roles: Solution Architect, Enterprise Architect, Domain Architect, and Staff Engineer

I work as an Architect and Engineering Manager, and I've run interviews for Solution Architect, Application Architect, and Enterprise Architect roles. In those interviews, the same title usually meant a different role.

The industry uses the title loosely. At a cloud vendor, a Solution Architect is "a customer-facing role", in Microsoft's own words. At a product company, the same title can mean the person who designs one system end to end and never meets a customer. A third company gives that work to a Staff Engineer. I wanted one map of these roles, because the same title means a different job at every company.

Architect roles by decision scope

"Architect" isn't a seniority level. It's a family of roles, and the clearest way to tell them apart is the scope of the decisions each one owns. Place a role by the widest scope it decides for, not by the word in front of "Architect".

The table is a map of influence, not an org chart. A startup puts four layers on one CTO. A bank gives each layer its own team. So the title tells you the specialization, and the scope and the decisions the role approves tell you the job.

Enterprise Architect vs Solution Architect

These two titles look like junior and senior versions of one job. I don't see Enterprise Architect as a senior Solution Architect. It's a different job with a wider scope.

An Enterprise Architect shapes the constraints: target state, principles, standards, and which platforms the company keeps. A Solution Architect designs one solution inside those constraints. The SFIA framework, which many companies use to define IT roles, puts solution architecture at responsibility levels 4 to 6 and enterprise architecture at levels 5 to 7. The ranges overlap, so a senior Solution Architect can carry more authority than a new Enterprise Architect.

Enterprise Architect

The Enterprise Architect works across business, data, applications, and infrastructure and rarely designs a single system directly. The job is to keep hundreds of systems moving in one direction.

• Decides: target architecture, architecture principles, standards, portfolio rationalization, and exceptions to the standards.
• Produces: capability and technology roadmaps, a target-state architecture, principles, and transition plans.
• Code: low.
• Sits in: the CIO or CTO office, a transformation office, or a central architecture team.

Typical decision: Should the company consolidate on one platform, or keep domain autonomy?

Business Architect

The Business Architect models the business itself: which capabilities the company has, how value flows to the customer, and which capabilities must change to execute a strategy. Outputs are capability maps, value streams, and organization maps. There's almost no code. In many companies, this work lives within the enterprise architecture team rather than in a separate role.

Domain Architect

A Domain Architect owns the architecture of one bounded area. The domain can be a business one (payments, lending) or a technical one (identity, networking, integration).

• Decides: the target architecture, approved technologies, and patterns for the domain.
• Produces: a domain blueprint, reference architectures, and a lifecycle roadmap.
• Code: low to medium.
• Sits in: an architecture practice or a platform group.

The Domain Architect sits between the two roles above. Solution Architects use the domain's patterns, and the Enterprise Architect keeps the domains consistent with each other.

Solution Architect

The Solution Architect turns one business problem into an end-to-end design: services, data, integrations, security, deployment, and the migration order.

• Decides: build vs buy, system boundaries, the persistence and integration style, availability and disaster recovery, and the security model.
• Produces: context and container diagrams, NFRs, ADRs, a cost model, and a migration plan.
• Code: low to medium. Proofs of concept are common.
• Sits in: a product or program team, IT, or consulting. At cloud vendors, it's often a pre-sales role.

The ADR and system blueprint documentation is the main artifact here, because the job is trade-offs. I prefer ADR templates that record the considered options, as I wrote in 10 ADR Anti-Patterns. I also put an approximate cost on every element of the architecture diagram. Cost is a non-functional requirement too (more in The Frugal Architecture in Practice).

Note: "Solution Architect" has the widest range of meanings of all the titles here. Check whether the role designs the solution or sells it.

Specialist architects: Application, Data, Security, Cloud, Infrastructure, Integration

Specialist titles name one architectural concern. These architects work as peers, and their standards and designs feed the Solution Architect's end-to-end design. They aren't a level below it.

Cloud Architect has two meanings. A cloud solution architect designs a single workload or a single customer's solution. A cloud platform architect builds the landing zone, account structure, and guardrails every team uses. Ask which one the post means.

Integration Architect treats the connections between systems as the main design object: API and event contracts, schema versioning, retries, idempotency, and dead-letter handling. The role overlaps most with the Solution Architect. In a microservices estate with dozens of teams, it's usually a separate job.

Data Architect vs Data Engineer. The architect defines the target structures, ownership, and standards across systems. The engineer builds and runs the pipelines that implement them.

Architect vs Staff Engineer vs Principal Engineer

Application Architect, Staff Engineer, and Principal Engineer overlap the most, because the work is often the same. The difference: Staff and Principal are levels on the engineering ladder. Architect is a role. A Principal Engineer is often the architect of an engineering area and still writes production code.

In a product company, I'd expect Staff and Principal Engineers to do most of the system architecture, and I think that's fine. The people who design the system also build it, so the design meets the code early. Enterprise IT, finance, government, and other regulated industries keep formal architect roles because approval rights and the audit trail matter as much as the design.

Note: Staff and Principal levels don't exist in every company. Where the IC ladder stops at Senior, "Architect" is often the only title for the same scope.

Tech Lead vs Engineering Manager

Tech Lead is often an assignment, not a level. A Senior, Staff, or Principal Engineer takes the role for one project or one team, and owns the technical plan, task breakdown, design choices, and reviews. A Tech Lead has no direct reports.

An Engineering Manager owns the people: hiring, 1:1s, growth, performance, and delivery. The manager still joins architecture discussions, but the team's results measure the manager, not the code. That accountability for people is what separates the management track from every other role in this article.

As I wrote in 6 Tips for the New Engineering Managers, the IC track is a good path too. Not every strong engineer wants to manage people.

Architect career path: IC, architecture, and management tracks

There's no single "engineer, then architect, then manager" ladder. After Senior Engineer, most companies with a mature ladder offer three tracks:

• IC track: Staff Engineer, Principal Engineer, Distinguished Engineer, or Fellow.
• Architecture track: Tech Lead, Application or Technical Architect, Solution or Domain Architect, Enterprise or Chief Architect.
• Management track: Engineering Manager, Senior Engineering Manager, Director or VP of Engineering.

People cross between tracks often. A Principal Engineer becomes a Chief Architect, a Solution Architect goes back to Staff Engineering, and a manager moves into architecture. What carries across is the scope you've owned, not the title.

Company size decides which roles exist:

• Startup: the CTO, a founding engineer, or a Staff Engineer covers solution, application, cloud, and security architecture alone.
• Mid-size company: Solution, Cloud, Security, and Data Architect usually appear first, with light governance.
• Large enterprise: every specialty above gets its own role, because the portfolio, the regulations, and the integration surface are big enough to pay for them.

How to read an architect job title

When I read an architect job post, I look for the decisions the role approves before I look at the title. These seven questions get you there:

1. Which systems or which part of the organization does the role own?
2. Which decisions need this person's approval?
3. Does the role define standards, or only apply them?
4. Does the role own the delivery of what it designs?
5. How much production code or IaC does the role write?
6. Does the role have direct reports and do performance reviews?
7. What measures success: project delivery, technical leverage, governance, or transformation?

Conclusion

• Read the scope, not the title. The same title covers pre-sales engineering, end-to-end design, and enterprise governance. The scope of the decisions tells you which one you're looking at.
• Level and role are different axes. Staff and Principal describe how far your impact reaches. Architect describes what you own. One person can be both, and many Principal Engineers are.
• Authority comes from decision rights. The person whose approval a design needs is the architect for that design, whatever the org chart calls them.

Future reading

• 10 ADR Anti-Patterns and ADR Best Practices for Developers, Tech Leads and Architects
• Best Practices for Effective Software Architecture Documentation
• The Frugal Architecture: Cloud Cost Efficiency in Practice
• 6 Tips for the New Engineering Managers
• Reference Architecture Cheat Sheet