Architects come in different roles, responsibilities and areas of expertise. Coming from a software development background with an ambition toward higher-level component level thinking, you’re most likely heading for a solution architecture role. In the broader sense, we can define three layers of architects at the enterprise, solution and software levels. But then we also identify other roles such as business architects, cloud architects and security architects. What do all these different roles mean and do we really need all these titles?

What’s in the title

The specific architect’s title shouldn’t matter too much. What counts most are your responsibilities and how you fill these. However, for other people in the organization, the title does say something about the kind of subjects they can knock on your door with. If, for example, your colleague is classified as a cloud engineer and another colleague as a cloud architect, you would know who your first point of contact would be for a cloud migration.

Characteristics of an architect

But how do you know if you’re an architect or want to become one? One of the factors is how you think about components, how they work together and what technologies should be used. Some of the indicators are:

• If you’re concerned about components, how they interact and how they must be maintained
• If you have more interest in how components and services are used than in developing them
• If you care about functional and non-functional aspects of a solution

In practice, you’ll notice you’re picking up tasks related to these characteristics depending on the freedom you have within your current software developer role. But when is the time for taking the leap to start calling yourself a solution architect?

When moving your responsibility from software development to the world of solution architecture, you’ll also notice that you’re dealing more with the business architecture and want to better understand the whole vision, mission and strategy of the business case and the project. In your daily job you’re also considering which components should be built from scratch and which can be reused from somewhere else or can be bought. Then you need to work out the plan to get to your new target architecture and decide how all these things are governed.

Responsibility scope

Common sense will get you a long way in understanding what’s needed to reach your goal of realizing the target architecture, but it also feels like there are so many things to deal with before getting there. You might also find yourself in places and discussions where you start thinking if this is even part of your responsibility. Apart from the technical aspects you also get functional and non-functional requirements fired at you. And then you also have things like compliance, legal and risk aspects. And how do you even govern and document all this?

Fitting in the enterprise

Every company is different, and each project has its own characteristics and specific ways of working that work best. From a solution architect’s point of view, it helps to also understand the best practices on an enterprise level. This helps in understanding how the solution architecture fits into the enterprise, what requirements you must demand from the business architecture side and what the output must be to the enterprise organization. Besides delivering the solution you’ll also find yourself in a situation where you need to challenge or push back to the business because the solution architecture requirements are not met.

Guidance with architecture frameworks

Fortunately, there are enterprise architecture frameworks which reflect these enterprise architecture best practices. There are many enterprise architecture frameworks but the most well-known and used one is TOGAF. It provides an approach for designing, planning, implementing, and governing an enterprise information technology architecture.

You can get certified for TOGAF but as the study is highly theoretical and dry matter, I recommend arranging a course with a knowledgeable tutor. It will help you understand and manage your place in the bigger enterprise picture.

That’s all great to better understand the solution architect role and how that role fits into the enterprise organization but how do you get there as a software developer and what are the practical tasks you do on a daily basis?

the path

There are a lot of studies and courses on becoming a software developer but almost nobody teaches you how to become a solution architect. Many people currently filling in the solution architect role already picked up a lot of tasks in previous roles that fall within the role description of a solution architect. You may be working in a small company where many roles have a broad role description due to the size of the company. As a senior software developer in such an organization, you’ll find yourself responsible for infrastructure, integrations with third-party systems, migrations from legacy systems to modern applications and governing all these aspects. In larger organizations, the software developer and solution architect roles are more tightly defined. At some point, you want to change role description from software developer to solution architect in your email signature, but when is that moment? When having the option in your company to grow to a solution architect role it might be a gradual process, but when starting in a new company the jump may feel too big. You start questioning yourself if you are suitably equipped and can meet expectations. In all these cases it comes down to just taking that leap and calling yourself a solution architect. You’ll manage.

Considerations

A lot of developers with architectural ambitions are concerned about whether they will still be developing software. It depends. Most companies have a clear separation between software developers actually building the software and architects mainly working on the translation from business architecture to solution architecture. When considering a role as a solution architect you’ll have to take this into account. But in smaller organizations, you’ll also encounter there is an overlap with architecture, software development and operational work. You’ll have to ask yourself the question if you want to take that full leap to solution architecture and let go of the hands-on software development, or still want some hybrid role version. The latter will be a bit more difficult to sell to companies. Yet taking the full leap doesn’t have to mean you’re losing all touch with software development. Still, you need to go in-depth on the software architecture with the lead developers to understand and monitor the quality and how it affects the solution now and in the future.

Final thoughts

When you feel like you filled your backpack with quite some experience to fill the role of a solution architect, you’re ready for it. Find yourself an official solution architect role in a project to make sure you’re working on the right tasks and have the right responsibilities. Besides working with your team of developers and business stakeholders it’s really helpful to collaborate with other architects in the company. Often, it’s required for working on your project but also find architects who are working on similar tasks and share your experiences. You’ll see they face the same challenges, and it helps you grow in your role by learning from other architects.