When starting my Computer Science career at a big consulting firm, I quickly identified some common roles within the company. We had the backend developers hunched over their keyboards churning out fail-safe code for our clients, the frontend developers reading up on the latest JavaScript frameworks, the management consultants striding across the office talking loudly about their latest gym session.
And then we had the architects. Somewhat of a crossbreed between the backend developers and the management consultants. Some wore suits and only attended meetings, and some were busy drawing complex diagrams of systems talking to each other.
After working for multiple different clients as both a backend developer and a frontend developer, I quickly realized the need for the architect role. The architect was there to make sure that what we developed fit into the long term goals of our client and that we crafted new features in a scalable and secure way. It was clear to me that to be able to set these guidelines and high-level decisions, a certain level of experience and knowledge was needed.
When my last assignment as a backend developer ended, my manager approached me with an assignment. A large telecom company was building an app, and their architect had just resigned from the company. They needed someone quick. I was concerned about my lack of experience in the architect role, but the challenge was tempting. In the end, I said yes.
I was instantly thrown into a pile of pressing issues. The client had requested a high-level design of a video chat implementation. The backend team did not have a development environment running. The frontend team had not yet started to integrate with the backend, since no environment was up.
To say the least, I was off to a challenging start. Using the skills I had picked up during my years as a backend developer and a few long nights of conference calls, I was able to get the most pressing issues fixed and the project delivered in time.
During that first assignment as an architect, I picked up a lot of skills and experience. Here are the key lessons that I think you should know before transitioning from developer to architect.
What Does an Architect Do?
Earlier, I described the architects as attending a lot of meetings and drawing diagrams. But what do they actually do in the meetings, and what diagrams are they drawing? While those are of course not the only activities an architect does, let’s use them as a starting point to dive deeper into the day-to-day of an architect.
The main job of an architect is to set the high-level technical roadmap of the application that they are involved in developing. To be able to do that, the architect needs to interact with a number of stakeholders to understand their needs and translate them into technical requirements. The stakeholders can be customers, development team members, or product managers. This is where the meetings usually come in.
So what about these diagrams? The technical requirements that the architects decide on need to be documented and understood by the developers who will implement them.
While text might be a good starting point, diagrams and other visual tools are a very good way of expressing how something should work. You often see diagrams such as maps over how systems interact with each other or different types of flow charts depicting a use case in an application.
As you may understand by now, communication skills are very important for an architect. In the next section, we will dive a little bit deeper into the skills you need as an architect.
What Do You Need To Know as an Architect?
While there are a lot of things that you need to know about software development to take on the architect role with confidence, there are a few areas that I think you should focus on.
Communication
The most important skill that you need as an architect is communication. You need to be able to communicate around deep technical issues with the development team as well as explain technical concepts on a higher level to clients or other stakeholders.
To communicate effectively, I make sure to adapt the language that I use for the target audience. The development team probably knows what an API is, while that might not be completely clear when you talk to a client. Therefore, I always make sure to prepare material such as documentation or code samples for meetings or walkthroughs based on the participants. When speaking to developers, it can be easier to show them a piece of code, while high-level documentation might suffice for non-technical staff.
Another tool that you need to master is diagrams. Some developers frown upon architects and say that they only draw boxes with a couple of lines in between them and expect the developers to solve the rest. While that might be true in some cases, the ability to visualize a solution is very important to get your point across to both developers and others.
Some diagrams that are particularly useful are database relationship diagrams, sequence diagrams, and system architecture diagrams. To get better at drawing these, I recommend starting out with creating diagrams for an existing part of an application and using it to explain how it works to a developer. This can also spread knowledge and work as documentation in the future.
Best Practices
Sometimes, people will ask you how to do something in the best possible way and expect you to come up with the best possible solution. Designing a solution from scratch is not easy, since any given problem usually has many different solutions. In situations like this, best practices come to the rescue.
Since software developers are problem solvers by nature, they will tend to accept widely accepted standards as best practices. If someone comes to you with a problem, make sure that you look up the best practices for that domain, and use them to your fullest advantage. There is no point in inventing solutions to problems that have already been solved reliably for many years.
A story from my first assignment as an architect comes to mind: A project stakeholder called me and claimed that there had been a security breach in the application we were building. The details were very unclear, but he still wanted to know if a security breach could have been possible. To calm the client down, I went through the OWASP collection of top security risks for web applications and how we had mitigated each risk with a best-practice.
The security domain is always a top priority, and thankfully, there are a lot of documented best practices regarding security that you can lean back on when it is discussed. To start out learning more about security from a developer’s perspective, I recommend memorizing the OWASP Top Ten as well as reading “5 Security Concepts Every Developer Should Understand” by Justin Boyer.
To find best practices in other domains of software engineering, there are tons of resources accessible online. If you prefer a book to get a more thorough overview of software engineering best practices, you can pick up Software Engineering Best Practices by Capers Jones.
APIs
When talking about system architecture, you often talk about how different systems communicate with each other. Usually, system-to-system communication is done through the use of APIs.
That means that it is very important for you as an architect to know how to design APIs and how to integrate different APIs with each other. Working with APIs means coming up with solutions for parsing data, storing data from different sources, finding the correct APIs to integrate toward, etc.
My experiences working a lot with APIs later led me to create a mock API tool startup where I could apply all my knowledge to build my own product.
Basic Networking
When talking about how systems communicate with each other, it is important to know how to do that securely. That is when networking comes into play. How do we access System A behind Firewall Z? Which ports do we need to open? These are typical questions that you need to deal with when integrating toward enterprise systems.
Usually, you only need to grasp the concepts of IP addresses, firewalls, and subnets to be able to discuss network-related matters on an architecture level. It can, however, depend on which type of infrastructure the application you are building is running on. Before an assignment, I always try to take some time to make myself familiar with the infrastructure that is used.
To get started learning basic networking, I recommend taking a class such as networking for web developers. Furthermore, it is advantageous to understand architectures with a public subnet for the public-facing application and a private subnet for the database server. This is described quite well by Amazon Web Services in their networking documentation.
So You’re an Architect! Now What?
Your career journey is of course not over just because you are an architect. There are multiple paths that you can take after a few years as an architect. One way to go is to move closer to management and become an enterprise architect. This role usually involves creating IT strategies within a company at a higher level such as deciding which technology to invest in.
You can also move more toward a product-centric role where you decide which features to prioritize and create solution designs for them. After my first assignment as an architect, I moved into a similar role at a telecom company.
Product-centric roles usually require experience with the product that you are working on. In my case, I had been involved with the product for about a year before I was confident enough to take on a more product-focused architecture role.
Enterprise architecture, on the other hand, provides many opportunities to take a certification to prove your skills. One of the most renowned enterprise architecture certificates is The Open Group Architecture Framework (TOGAF), which I have yet to take on.
You’re on Your Way
Being an architect is challenging and takes a lot of knowledge and experience. At the same time, you don’t need to be an expert in any particular area of software development to become one. It is better to have a broad understanding of software development and be able to communicate that understanding effectively backed up by best practices.
Communication is best done by tailoring the message to the receivers and using visual tools.
Best practices should be used whenever possible to avoid reinventing the wheel when designing new solutions.
APIs are needed when you need to make systems talk to each other.
Networking is something you need to understand to integrate with systems in a secure way.
Using this guide to point you in the right direction, you are well on your way to becoming an architect. I wish you the best of luck in your future endeavors!