My full responses ended up being transformed into an article at Enable Architect (June 14, 2022), after working through several rounds of editing with the journalist who initiated the media query. Extent of verbatim quote highlighted in orange, paraphrased quote highlighted in gray. Above image from cited article.
The query responses I provided to a media outlet on April 7, 2022:
Media: Career path for systems architects
Media: Systems or technology architecture is a bridge between IT operations and the c-suite. However, everyones path is different. How many years did it take you to become a systems (enterprise, solutions, data, software, technical, domain, etc.) architect or engineer?
Gfesser: I've learned that the term "architect" can mean many different things depending on the audience. The situation has gotten to the point that a fair number of firms even refuse to use this term due to some of the audience assumptions that are often made when hearing references to it. And adding qualifiers to "architect" often doesn't help much.
While every company is arguably now a software company, many of the terms being used in industry simply aren't standardized. As such, job descriptions should be explicit as to what is expected of these roles, and the individuals writing these job descriptions should be close to the work being performed to help ensure accuracy.
Now, because of this situation, it's challenging to make broad statements to describe a path to become an architect. However, I've worked as the following types of architects in my career, in roughly the following order, and can explain the general process which lead to each role: software, data, enterprise, principal, and chief.
My technology background initially focused on being a "software engineer", 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 role "architect", and those who bore this title essentially put together artifacts describing the software to be built.
This was before the agile movement took off, so architecture was largely seen as a step that needed to take place before development could commence. The very few times I received handoffs from architects, I found myself eventually deviating from what they had initially outlined due to these being incomplete or impractical, or because requirements changed after these were put together.
As the open source movement also gained momentum, I also found myself in a situation in which libraries and frameworks started to heavily influence software architecture. And because the traditional architects with whom I had periodically worked were no longer hands-on, a disconnect took place. In essence, they were no longer able to design from a practical standpoint, and I took on this responsibility as a senior software engineer.
Essentially, I became both senior software engineer and architect (which additionally included DevOps tasks), because the need existed to do so: separating these roles would just result in a disconnect, and working in an agile manner required that the complete solution be understood.
All of this said, after working in this dual role for a few years I noticed that not only did the need to focus on data become more pronounced, but many traditional software engineers did not seem to value data because they either took it as a given as being available, thought of it as being "the easy part", did not understand it, or did not wish to work on it.
It was around this time when I started my path to become a data architect as well, because I saw the work software engineers were not willing to do, and used this situation as an opportunity to add these skills to my toolbox.
Alongside my software development and architecture efforts, I increasingly took on more and more data focused work. First by designing application databases and performance tuning existing databases, followed by designing and building data-intensive applications and designing and building analytical databases, leading up to my eventual decision several years ago to focus on building data-intensive products after being recruited to do so by a former manager of mine.
My turn in this direction came at the heels of my leading a portion of a digital transformation effort for a large client of mine, which advantageously came about after being brought on board by the CIO to work as an enterprise architect for their chief architect, who soon after asked me to take on the work of a recently departed director of architecture. For what it's worth, my team and I also built dozens of microservices while I served in this role.
Looking back in retrospect, it's clear that all of these roles are interrelated, speaking to my roles of enterprise architect, principal architect, and chief architect. My first experience as an enterprise architect was actually as "enterprise data architect", several years after I started working as a data architect. The distinction between data architect and enterprise data architect is the scope of the data, with enterprise involving multiple organizational units or departments, and as such, greater breadth of responsibilities, which in this case included my being asked to interview dozens of enterprise data architect candidates to build out my client's capabilities.
In contrast, the roles I've since served as principal architect and chief architect have been associated with the teams of architects I've lead. For example, as chief architect I currently lead a team of "solution architects", who in turn lead a team of software architects. As it so happens, I've also spent time managing vendors and building a data engineering team while serving in this role, while also directing efforts to re-architect and open up an existing data lake, to use code for data pipelines, and to scale execution of a data-intensive product to several hundred Spark jobs during peak hour load.
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, realizing in the end that technology work is all interrelated, and the more practical experience you get in each area the more valuable you will become - perhaps not by your current manager, but by your next one.
See all of my responses to media queries here.
© 2009-2024 Erik Gfesser (Erik on Software)