Become an Architect for Your Team

On some teams, architect is an official team role. On other teams, there is no explicit role and teammates share the architect’s responsibilities. Some teams say they don’t have an architect, but if you look closely, someone is fulfilling the architect’s duties without realizing it.

Architects are leaders, but being a software architect also implies a person who thinks about software design in a certain way. No matter what the title on your business card reads (mine still reads software engineer, my choice), you can be a software architect. Every team has at least one architect. The best teams have several.

If your team doesn’t have an architect, congratulations, you’ve got the job! You don’t need permission to inject architectural thinking into your team’s design discussions. Start asking questions about quality attributes. Point out when the team makes trade-offs. Volunteer to write up design decisions and begin accepting more architecture design responsibilities.

If your team already has an architect, then ask that person how you can help. When possible, work closely with your architect and take advantage of every learning opportunity you can. Developing a software system is a big job. The more people who pay attention to the details, the greater your chance of success. Every team should be so lucky as to have many knowledgeable software architects!

Make the Move from Programmer to Software Architect

An average software architect has developed three to five software systems with increased technical responsibility on each software system. Depending on the software you build, as your architecture responsibilities grow you may find you have less time for programming. This is normal, though software architects should never stop programming altogether.

To measure your growth from programmer to software architect, create a project portfolio. For every software system you build, no matter your role, briefly describe the software system and what you learned during your time developing it. This kind of reflective practice is essential for all technical leaders but especially software architects.

Here are some questions you should answer about each project in your portfolio:

• Who were the stakeholders and what were the primary business goals?
• What did the high-level solution look like?
• What technologies were involved?
• What were the biggest risks and how did you overcome them?
• If you could do it all over again, how would you do it differently?

Whether your goal is promotion or simply professional growth, be patient. You might have the chance to design a software system of meaningful complexity only every three to five years. If you are lucky, you will see between 8 and 15 software systems throughout your entire career. Be prepared to take advantage of architecting opportunities as they arise. Work with your teammates to give everyone a chance to grow their skills. I promise there is more than enough interesting architecture work for everyone!

Always remember, software architect is a way of thinking, not just a role on the team. When you’re wearing your programmer hat, you’ll make dozens of design decisions daily. Some of these decisions have architectural significance. Anyone who makes a decision that influences the structures of the software system becomes the architect pro tempore. It’s up to you to make good decisions and uphold architectural integrity no matter what the title on your business card reads.