My career journey from software engineer to architect

The term "architect" can be interpreted in a variety of ways. Your company, industry, and job duties play a part, but so do the backgrounds of the individuals working around you.

For this reason, architect job descriptions should be explicit about what is expected, and those involved in writing these should be close to the duties of these roles to help ensure accuracy.

While it is challenging to make broad statements about the path to becoming an architect, I have worked as a software, data, enterprise, principal, and chief architect and will share the general process that led me to each role.

Your title might not reflect what you actually do

I began my technology career as a software engineer, which is now often called software developer. After a few years, I grew into senior software engineer roles. 

At the time, I ran across very few individuals with the title "architect," and the work of those with it was typically constrained to putting together artifacts describing the software to be built by engineers.

Before the agile movement took off, this initial architecture step needed to be completed prior to any subsequent development.

The few times I received handoffs from architects, I typically deviated from what was outlined by them because the artifacts they created were either incomplete or impractical, or because requirements changed.

As the open source movement gained momentum, libraries and frameworks started to heavily influence software architecture, and hands-on development was needed in order to fully understand these.

But because the traditional architects I periodically worked with were no longer hands-on, there was a disconnect. They could no longer design from a practical standpoint, so I took on this responsibility as a senior software engineer.

As such, I took on the roles of both senior software engineer and architect, additionally building DevOps deployment pipelines, because there was a need to do so.

Working in an agile manner required that complete solutions were understood, so separating these areas of work would only add development time for a result that might be less than optimal.

[ Learn five best practices for success when transitioning into a new role. ]

One of the key takeaways here is that my formal titles and job descriptions didn't stipulate what I actually did in these roles. The work that needed to be done is what influenced the work I actually performed.

Build your skillset, and your career will follow

After working in these roles for a few years, I saw that there was a greater need to focus on data, but many traditional software engineers did not seem to value data work for a variety of reasons.

One common reason for this outlook was the assumption that appropriate data would simply be made available by someone else. Other reasons included the prevailing view that data was the "easy part," or that software engineers just did not understand it or wish to work on it.

As a result, I used this situation as an opportunity to add these skills to my toolbox, increasingly taking on more data work alongside software engineering and architecture, eventually taking on data architect roles.

And data architecture was my entrance to enterprise roles. The difference between a data architect and an enterprise data architect, for example, is mainly the scope of the data, with the latter involving multiple systems or organizational departments. 

I started by designing application databases and tuning the performance of existing databases, which naturally led to designing and building data-intensive applications due to my software development background.

I then began designing and building analytical databases, eventually leading to my focus on building data-intensive products after being recruited by a former manager to do so.

As principal architect for a consulting firm, my turn in this direction came at the heels of leading a portion of a digital transformation effort for a large client who asked me to take on the work of a recently departed director of architecture.

[ Learn what's needed for maintaining momentum on digital transformation today. ]

We had been building a relatively early event-driven architecture, and alongside my work as an enterprise-scale architect, my team and I built dozens of microservices to stream data.

The "enterprise-scale" qualifier here essentially means that I began working with both development teams and executives on a regular basis, communicating with different groups as needed to gain support and build solutions.

Following that effort is when I pivoted into what was once called "big data" to build and deploy data solutions with data lakes and distributed data processing.

My roles as principal architect and chief architect in recent years have been relative to either my relationship to other more junior architects with respect to seniority or leading teams of architects, although as principal architect I was still hands-on with respect to development.

Just be aware that the variation you will likely experience in these types of roles will be even greater than what you experience in your earlier roles, due to organizational cultures or the nature of the work itself.

All technology work is interrelated

Looking back, it's clear that my past roles have all been interrelated. When starting out as a software engineer, you might have a vague notion that this is the case, but everyone's journey to put the pieces together is unique.

One of the many considerations to take on your journey, for example, is whether you will work in industry or consulting. My career has largely taken the consulting path. 

Unless you choose to work at a startup, consulting generally tends to be more entrepreneurial, encouraging the wearing of multiple hats as you design and build solutions.

My advice for senior software engineers looking to get into architecture is simple: be flexible with the type of work you're willing to do, and look for opportunities to branch out into new directions.

The more practical experience you get in each area, the more valuable you will become—if not by your current manager, certainly by your next one.