3 lessons for software developers pivoting into IT architecture

There are two common paths for a developer to advance in the IT industry: Become a manager or become an architect. While some developers choose to become managers and lead projects and people, there are code geeks who want to continue their technical career by becoming architects.

Read other articles in this series on transitioning from a developer to an IT architect:

• 3 soft skills aspiring IT architects need to develop
• 5 technical skills aspiring IT architects need to learn
• 4 people skills aspiring IT architects need to master

While this often feels like a natural process, it is a big change that requires some reframing and adjustment. In my experience, there are three important concepts you need to focus on when moving from development to architecture.

[ Here's one way to boost your career: Become a Red Hat Certified Architect. ]

1. Change your mindset

The first thing you need to do is to change your mindset: Stop thinking like a developer and start thinking like an architect. That means you must prepare yourself for a paradigm shift in how you look at things and solve problems.

Moving from a software developer to an architect is one of the most challenging transitions in the IT industry. A developer's role is almost always clearly defined, while an architect's role is not as well defined. This can make the transition from a developer to an architect difficult. Architecture is typically characterized by grey areas, uncharted territories, ambiguous situations, misplaced expectations, and confusing periods that can throw unprepared developers off track and demotivate them. This article series aims to address some of these concerns, clear confusion, and help developers become better architects.

2. Think big

A role of a developer typically involves designing, building, and maintaining software systems by writing code, then unit testing, documenting, and maintaining it. In contrast, an architect's role is comparatively broad and typically involves designing the high-level structure of software systems. It also includes detailed designs of the systems' individual components and how they interact with each other.

Some architects do not have a development or engineering background. However, architects with a development background can add more value to the project during the build phase by helping developers design the overall project and class structure and perform code reviews. While a developer's role is always hands-on, an architect's role may not be, depending on the project's needs and the architect's interests.

[ Cheat sheet: IT job interview tips ]

3. Resist the urge to start coding

When you come across a problem statement or a use case, your first instinct as a developer is to start writing code. As an architect, you must overcome that urge. Wanting to write code is natural to seasoned developers, and it is quite difficult to get rid of this habit.

The path to becoming a successful architect is to start visualizing the problem through a bird's eye. Think in terms of components and their interactions instead of classes and methods. Visualize systems instead of visualizing code. Think of databases and streams instead of tables and rows. It may take some time to get accustomed to this new way of thinking, sometimes even years. However, this is a very important milestone in the path to becoming a successful architect.

Types of architects

Once you have made your decision to become an architect, you should learn the different architecture paths before deciding which one(s) to pursue. (See What type of IT architect are you? for some descriptions.) Examples include:

• Solutions architect
• Technology architect
• Cloud architect
• Data/information architect
• Database architect
• Data platform architect
• Security architect
• Integration architect
• Enterprise architect
• Domain architect (insurance, banking, aerospace, and so on)

[ Check out Red Hat's Portfolio Architecture Center for a wide variety of domain-specific reference architectures you can use. ]

Each of these paths is different with some overlapping aspects. Some roles have another architect role as a prerequisite. For example, you cannot become an enterprise architect without having been a solutions architect for some time. The domain architect role requires you to be a subject matter expert in a particular area. Some of the roles are purely technical. But some are partially technical and partially business.

What next?

In the subsequent articles in the series, I'll discuss almost everything that you need to know or learn to become a successful architect. This includes understanding the business domain, stakeholder expectations, people skills, negotiation, visibility, career growth, social media presence, knowledge sharing, and more. My next article shares 3 soft skills aspiring IT architects need to develop. Stay tuned!

[ Get advice from experts to build a resilient IT culture ]