Following the Software Architecture Career Path

I can recall a certain day in my career with remarkable clarity.

I say remarkable because this happened well over a decade ago, when I was a relatively fresh-faced software engineer.  My manager had called me in for a chat — quarterly review or some such. He said something that stopped me in my tracks.

“Do you want to follow the technical track or the management track in your career?”

Yikes!

I remember panicking.  On an otherwise unremarkable morning, I had unexpectedly come to a crossroads in my career.  Did I want the organizational clout and higher paychecks of management?  Or would I stick with the technical stuff that I so loved?

Of course, this turned out to be a comical overreaction on my part.  My answer didn’t, in any way, bind me for life.  And the whole thing was something of a false dichotomy anyway.

But it did get me thinking about what I would later regard as the software architecture career path.

And the software architecture career path is what we’ll talk about in this post.  This is an interesting and surprisingly complex topic, simply because you have so many flavors of software architect.  Let’s take a look at those flavors and their implications for your career.

The Software Architecture Career Path

I certainly wasn’t alone in my confusion over what becomes of programmers as they advance in their careers.  Some continue programming indefinitely, while others, eagerly or reluctantly, become managers and climb the corporate ladder.

But the software architecture career path splits the difference in a confusing variety of ways.

I challenge you to find a job title with as much variance as “software architect.”  The title itself has many different flavors:

• Software architect
• Application architect
• Technical architect
• Solutions architect
• Enterprise architect

You get the idea.

But beyond the title variance, you also see wide diversity in responsibilities.

• Some architects are literally just programmers with developmental job titles.
• Others are highly technical, mentoring developers and approving of solutions.
• Still others are more like project managers or business analysts.  It really varies.

And in this variance lies opportunity.  You can take the opportunity to find a role that suits you well in terms of responsibilities while also advancing your career.

For the rest of this post, I’m going to talk about how to take advantage of this opportunity.  What skills do you need, and how do you find success?

Bear in mind, I’m also going to describe the different flavors of architects in somewhat broad strokes.  The industry doesn’t have a great consensus on what each of these roles really means, so I’m basing this on my own experience.

Whatever you call the different flavors of architect is less important than what they do in their roles and whether the role might suit you.

1. Architect as Super Senior Developer

First up, let’s talk about perhaps the least specialized flavor of architect.  On the flip side, it’s the easiest to reason about and discuss.  In some shops, “architect” is just the next qualifying title jump after “senior software engineer/developer.”

In a shop like this, the architect has no specific responsibilities that differ from any software developers.  He just has more authority and influence.

Often, you see this dynamic in places with small or new software development teams.  The organization literally doesn’t know what to call the different roles/stages of software developer, so they mimic other org charts.

This is a good deal for you if you really love programming and want it to be your career.  With this style of architect position, you get a better title and better pay for doing what you like and continually improving at it.  (Though these shops can become breeding grounds for the “expert beginner” dynamic).

To prepare for this role, you mainly need to be a successful programmer.

So hone your technical chops, produce good working software, and develop a sense of patience and an affinity for mentoring software developers.  With that set of skills, you’ll have no trouble securing a tenured role on teams as your career advances.

2. The Application Architect

Let’s move on to a flavor of architect with more clearly defined responsibilities.  I’m talking here about what I think of as the application architect.

In teams/shops that grok software specialization a little better, you’ll have this as an actual, distinct role from programmer.

And it’s not simply a matter of experience or years with the company.

The application architect has responsibility for an application.  If you work for a software company, this may be a product line.  It might also be some kind of internal software.

The point is, you have a team of software developers that works on some application and then an application architect who works closely with them.

The application architect’s charter is implicitly or explicitly oriented around keeping the total cost of ownership for the application as low as possible.  She’ll concern herself with things like code reuse, maintainability, choices about the tech stack, and the general health of the application.

If you want this role in your career’s future, you need to learn a few key skills.  It’s more than just being good at programming.

You should also start to understand properties of codebases and code metrics.  Learn to visualize your codebase.  This is exactly the style of architect (or aspiring architect) that NDepend exists to help, which is why so many posts on this blog speak to this persona.

3. The Solution Architect

Where an application architect’s purview is (broadly speaking) a codebase, a solution architect generally has less granular responsibilities.  This can certainly span multiple codebases (notwithstanding the Visual Studio construct of “solution”).

One might think of an ecosystem of codebases as a “solution,” for instance.

The solution architect may also focus on a single codebase (considering the product to be a solution), but at a higher level.  This is where the line between product management, project management, and the technical can blur a bit.

If you want the software architecture career path to include this sort of role, you’ll prepare in a different way than the last two.

While it’s certainly good to be a highly skilled programmer, it’s not as essential for heading in this direction.  This style of architect needs a deep understanding of tech trends and capabilities (which will differentiate him from the aforementioned project managers and product managers) but also a fair bit of business savvy.

To pursue this sort of role, try to position yourself as someone on your team that works a lot with non-developer stakeholders.  Get used to dealing with:

• Discovery
• Requirements
• And strategic, business-facing decisions about the codebase.

4. The Enterprise Architect

The last flavor I’ll mention is the enterprise architect.

Not surprisingly, you tend to see this archetype in, well, the enterprise.  Meaning, you see enterprise architects at large companies with expansive app dev and IT operations.

Zoom out even a little further from solution architect to see what they do and the granularity at which they focus.  Where solution architects work with an ecosystem of products comprising a “solution,” enterprise architects work with the whole organization.

Typically, this involves helping the business standardize certain technologies, patterns, and approaches.

Enterprise architects are often completely separated from the software development teams they work with, sometimes being part of an enterprise architecture group.  Frequently, they have a consultative relationship with the organization’s software developers.

There are two ways that you can steer your career toward this role.

1. Enterprises generally have sophisticated career development operations, so you can make your goals clear and work with management to set yourself on the path to enterprise architect roles within that organization. This is, of course, assuming you already work there.
2. Otherwise, if you don’t work there or if you intend to move among companies, I’d suggest working first toward the application architect role.  Get a few different applications under your belt with this role, and learn to carry practices and patterns from one project to the next.  This will set you up nicely to deal with the larger scale expected for enterprise architects.

Putting One Foot in Front of the Next

I’ve enumerated some of the options you have for the software architecture career path.  But this is by no means an exhaustive list — it’s just a sampling of the sorts of architect roles that exist out there.

So first, fix in your mind what you might like to do as your career advances.

You can steer toward that, but don’t worry the way I did.  No decision you make today will lock you into anything.

Set a goal for yourself on the horizon and start to work on the skills I’ve mentioned that will help you get there.  This will not only help you, but it will also give you a nice preview of how much or how little you might like the role.

But in the shortest of terms, you have a simple set of tasks to execute.  Improving your programming chops, your understanding of codebases, and your ability to explain technical concepts to others is going to help no matter what you pick.  So start there, keep your eyes on the prize, and adapt as you go.