The Architect Role
In 2016 I had the privilege and pleasure of being part of the first cohort of Multi-Solution Architects at Adobe Consulting. We had to undergo super-intense training, but it was worth every second. I learned a lot and met with exceptional coworkers. I still remember those days as one of the best experiences I have had at Adobe. A lot has changed during these 8 years (already 8 years!?), which means that the role has also changed significantly. So I thought it was time to write a follow-up to the post I wrote on the role of the Multi-Solution Architect when I started this path.
What’s in a name?
I want to start by giving my point of view regarding the name of the role. It is obvious that we do not design buildings, we are not that type of architect. We build technological solutions to solve business problems, by combining software tools that already exist and new software where the required capability is not present in the tools. I am sure others will have a better description, but I like this one.
As a consequence of what we are supposed to do, various names have been used:
- Solution Architect. This is probably the most common name in the market. At the time of writing this post, a LinkedIn job search for this role returned 4500+ job offers in the US alone.
- Software Architect. In general, this role name is for developers who design complex tools. However, I have seen some people who do jobs similar to mine and have this title.
- Multi-Solution Architect. I believe that this is a job title that was coined at Adobe back in the day. It made a lot of sense then, as our role was to integrate disconnected tools from the Adobe Experience Cloud of that time to satisfy customer requirements: Adobe Analytics, Adobe Target, Adobe Audience Manager, Adobe Campaign, and Adobe Experience Manager. This is my favorite name.
- Enterprise Architect. IMHO, this is the most controversial title of all. In theory, this is a specific role in the market, very different from a solution architect. If you are TOGAF certified, you know what I am talking about. I would even argue that what the market typically refers to as an enterprise architect has very little connection with technical knowledge. However, this title looks and sounds very catchy and many have adopted it, even if their role is not that of what TOGAF defines as an enterprise architect.
From now onwards, I will refer to what the market calls solution architect, as this is what the market usually calls us.
Technical side
When we think about a solution architect, we tend to think of a person with a technical background, who designs solutions for developers or IT departments. A typical deliverable of the architect is a design like the one I have been using to describe AEP:
Another typical document is the solution design reference, which is a text document where the details of the solution are explained. Depending on the company, other deliverables are also produced. As with a brick-and-mortar architect, a solution architect is expected to be available by the implementation consultants or developers, to guide them and answer questions.
To be able to get to this role, you can probably see how experience and knowledge are needed. I have never heard of anybody who started his/her career directly as a solution architect. Understanding multiple tools, a development background, or knowledge of a technology domain, all require time to build. You will probably start in one of these areas and learn others as your career progresses. You do not have to do all of the previous steps, but the more you have under your belt, the better. In my case, I started my career as a C++ developer (I still remember what the vtable was for), then built websites in HTML, JavaScript, CSS, and PHP, to later become an expert in Adobe SiteCatalyst Analytics. All these steps helped me in becoming an architect.
One consequence of the previous paragraph is that you will end up specializing in one or two domains, or transition between domains but working only on one or two at a time. It is impossible to know all domains and all tools within a domain, there are just too many. As a funny example, many years ago a friend asked me about a particular accounting software, thinking that, because I am a techie, I would know about all software available in the market. I guess I do not have to explain that my knowledge and experience focus on MarTech and, more specifically, Adobe products. Remember that, as an architect, you need to be a comb, not a T.
Non-technical side
I would argue that the way to grow as an architect is not by learning new technology, but by expanding outside of technology. At least this is how we do it in my team.
The following list shows some non-technical skills that I believe an architect needs to learn:
- Business knowledge. You need to understand very well what the business wants to do, in order to build a technology solution for them. As I explained in my post on technology vs business, one of the keys to your success is to be the glue between the two sides of the equation. Not only this includes being able to gather requirements, but to challenge them.
- Technical leadership. A good architect does not stop when the deliverables are finished. You are part of a team, with developers, consultants, project managers… and you need to be seen as the technical leader of the project. Remember that, usually, these other team members do not have full visibility of the global solution. In my experience, if you instill confidence in the team, they will support and follow you.
- Executive presence and communication. I highly recommend the book The Software Architect Elevator. In it, Gregor Hohpe explains how an architect needs to be as comfortable with the developers as with the CEO, and all the levels in between. You need to learn how to behave and communicate with everybody.
- Trusted advisor. Another book I always recommend is The Trusted Advisor. I have received and delivered internal trainings based on this book. The summary of this book is how to make your clients trust you.
In general, we can group the last three examples above under the generic title of soft skills. You can immediately see how the number of soft skills becomes very quickly larger than technical skills, and are more difficult to master. My recommendation is that you find good in-person trainings to expand your soft skills.