Breaking Into Architecture: What Engineers Need to Know

You’ve been a developer or an engineer for a while now, and you know each module of your codebase inside out. You’ve solved every kind of pesky bug. But lately, you’ve been feeling that something is missing: the bigger picture that lies beyond the world of your module.

In this article, we explore exactly those next steps: how an engineer grows into an architect, the different types of architect roles and their areas of focus, and finally, the skills or certifications that could propel you forward in that direction, with intent. 

This article also serves to trigger thoughts around all those questions that folks have asked me so often:

 "What certifications did you do to become an architect?"

And maybe also prompt you to think that certifications alone may not help, or they may not help at all. If they do, then how? 

The Transition

Before we start thinking about the fancy title or the increased pay (maybe), let us explore the mindset aspect of this transition first. The real change begins as you move from thinking about individual functions to thinking about systems. 

• What does this system interact with?
•  What happens if one part or one module changes?
•  Who gets affected if this bit stops working?
•  How would this code pan out three years from now?

These questions start pulling you into the broader landscapes, all of the dependencies, the trade-offs, and the overall design. 

Sometimes, it begins even smaller. You start asking:

• How reliable is your function when called from another module?
•  Does it scale with more traffic or data? 
•  Is there added latency when it’s invoked from elsewhere in the system?

These thoughts push you past the correctness of just the module, into understanding the impact.

You begin thinking about who consumes your function, how long you envision it to work as is, what decisions you could make in the module so it can form a pattern that is reusable in other areas of the system, the constraints and caveats, and so on. 

You are also starting to see pain points that tend to repeat, and how you could address them smartly. This would mean you are digging deeper to rectify those hurried shortcuts and quick fixes. 

You also find yourself documenting better, explaining decisions more clearly, and communicating more often. (Note that last one! It’s a critical trait.) The business context, and more importantly, “the why,” starts becoming your north star.

The Faces of Architecture (Oh, and Phases too)

Let’s say you’ve been a Java Developer. The natural progression might be to grow into a Java Architect. What this means is that you are not just using your Java skills to write up some code of a module, but also thinking about how Java’s capabilities could speed up your application, where you can harden it for security, and which design elements could hold up when the application scales, and so on. This same logic applies to any programming language.

Similarly, maybe you’ve spent years on a specific product, for example, SAP, and built a deep understanding of its nuances. That experience could steer you toward becoming a Product Architect, where you design entire systems around that product’s strengths and limitations. I’ve seen people mislabel this role sometimes as “product solution architect,” for example, RPA Solution Architect. That is not quite right. You are either a product architect for a specific product in the market or a solution architect who works across multiple products. They are distinct paths, not a hybrid title.

If you’ve worked across multiple stacks without tying yourself to a single language or platform, your first step might be toward becoming an Application Architect, System Architect, or simply a Software Architect, who may be defined as someone who sees the full picture of how components come together to form a cohesive system.

One who specializes in the nuances of the cloud — entailing applications, security, storage on the cloud, and all the bells and whistles — is known as a Cloud Architect. Focusing on all the corners of data makes a Data Architect. A particular depth of how to secure large, complex systems is what defines a Security Architect. Along the same lines, we have DevOps Architect, Infrastructure Architect, and other specialized tracks that grow out of hands-on expertise in those areas.

A Business Architect sits closer to the business side, designing solutions around the organization’s core business processes rather than its tech stack.

Finally, we have the most misunderstood role of all, the Enterprise Architect. This is someone who works very closely with the CTO of the organization, helping translate the CTO’s technology vision into an organization-wide roadmap. They look at the enterprise as a whole and aim for long-term strategic alignment, not just local optimizations.

Skill Up Level Up

We now come to upskilling. Hopefully, you’ve noticed that I’ve consciously used the word upskilling instead of certifications.

And this comes from the situation I’ve seen where engineers rush to do something like TOGAF ® without gaining the experience required for it first, just because it is in vogue. Here are a few suggestions on how you could upskill yourself, consciously, rather than get “certified” for better pay or prospects.

First, think of what you are doing currently. 

• Do you know in and out of the technology, product, or domain that you are working with? 
•  What if you dig into it a bit more, and learnt more about it, formally, and in the process got certified?

 In fact, the word certified means an expert, although not in practice that may not always be the case. The certification would have the most value to the individual when they are adequately informed and trained on the practical elements.

Product specialists can go deeper, for example, through an SAP certification, or a Red Hat certification if you are a Linux specialist. How about delving deeper into a domain if that has been your specialization? If cloud is the platform you are working on, consider the multi-step cloud certifications and the pathway programs. Many of the popular cloud providers, in fact, have a free course on their site, with practice sandboxes. After you are well prepared, you may simply pay the exam fees and put your knowledge and experience to the test.

I would also recommend deep-dive reading or hands-on experimentation in specific areas of interest in your field, if you are not really a big “certificate” person. Maybe delve into security aspects, picking up small courses along the way, and gaining knowledge that you use in securing your applications. And if you do feel inclined at a later point, look at getting certified from bodies like ISACA.

If you are into tools on the enterprise side, then you may consider ArchiMate®. After you’ve built a few years of experience leading architecture projects across domains and departments, and if you feel the inclination for Enterprise Architecture, that would be a good point to attempt the TOGAF®, where you would really do justice to the credential.

On the other hand, if you are a part of an organization that scales across large teams and value streams, you could consider getting familiar with the Scaled Agile Framework and exploring certifications in that space. Open Group has several pathways and tracks for different specializations and interests.

Before I start sounding like a sales pitch for certifications, let me highlight a critical element. It is not a certification that can get you that awesome project, but your experience and knowledge that you have built, the mistakes you have learnt from, and the patterns you are exceptional at.

The most important skill that an architect needs is:

• seeing the bigger picture, 
• bridging the gap between tech and business, and
• being able to ensure that what is built actually meets the customer's requirements. 

This would automatically mean communication, presentation, mentorship, and deep technical know-how are integral common denominators.

This article is not a one-stop rule book, but rather is intended to trigger your thoughts around how you want to deepen or widen your skills, when software architecture is a path that you feel drawn to. The list here is not exhaustive, and is definitely not conclusive. It is just the tip of the iceberg, what with opportunities to learn being unlimited. 

All that is required is an open mind and the curiosity to keep learning.