Architect role

Introduction

Engineering roles often come with creative titles like "JS Ninja" or "Cloud Guru," or more classic ones such as Engineer or Architect.

In this article I'd like to focus on Architect role that has different flavours, depending on the organization and responsibilities. Maintaining meaningful role descriptions helps to cooperate more efficiently as it helps to have proper focus and expectations towards others.

Throughout my career, I had several leadership and architecture positions, each with its unique responsibilities and focus areas. But how they could differ? Below, I'll attempt to define different types of architect roles.

My personal experiences will hopefully be useful for your career planning and broader understanding of how software companies work.

But before we study different flavors of architects, let's compare architects to other roles.

Architect vs Engineer

Typical software architects often start their careers as software engineers and excel in that role. However, transitioning to an architect's role involves a shift in focus and responsibilities.

Key Differences Between Architects and Engineers

1. Scope of Work: Engineers focus on implementing production-quality solutions, working on specific features, and writing code daily. Architects, on the other hand, concentrate on the broader perspective, such as how different software components interact, ensuring alignment with organizational goals.

2. Coding Responsibilities: While architects may still write code occasionally, it is not their primary responsibility. Architects are not defined by their coding skills, and over time, their hands-on coding expertise may become less sharp compared to full-time engineers. Instead of coding, architects focus on enabling long-term efficiency by addressing issues like lack of clarity, technical debt, or cognitive load.

3. Problem-Solving Approach: Engineers solve problems at the implementation level, while architects address challenges at a higher level, such as system design, integration, and scalability. Architects aim to solve for long-term efficiency rather than short-term velocity.

4. Perspective: Engineers work on functions, classes, and modules, while architects focus on modules, applications, and entire systems. Architects often sacrifice a deeper understanding of specific codebases to maintain a broader view of the system.

5. Decision-Making: Architects are responsible for making decisions that impact multiple teams or systems, such as selecting frameworks, defining patterns, or ensuring technical alignment across teams. Engineers typically make decisions within the scope of their immediate tasks or projects.

Collaboration Between Architects and Engineers

Architects and engineers must work closely together to ensure successful outcomes. Architects rely on engineers for detailed implementation and feedback, while engineers depend on architects for guidance, clarity, and strategic direction. By understanding and respecting these distinct roles, teams can achieve both technical excellence and organizational alignment.

Architect vs Manager

Architects typically do not have formal people management responsibilities. However, in my opinion, being a good architect requires a similar level of empathy and leadership skills as being a good manager.

Common Skills Between Architects and Managers

1. Communication: Even the most brilliant architecture is useless if it is not implemented because others do not understand it. Clear and effective communication is essential for both architects and managers to align teams and stakeholders.

2. Collaboration: Both roles require working closely with diverse groups, including engineers, product teams, and business stakeholders, to achieve shared goals.

3. Decision-Making: Architects and managers often need to make critical decisions under constraints, balancing technical feasibility, business needs, and team dynamics.

4. Conflict Resolution: Managing disagreements, whether technical or interpersonal, is a key skill for fostering a productive and harmonious work environment.

5. Vision and Strategy: Both roles involve setting a direction—architects for technical solutions and managers for team or project goals—and ensuring alignment with organizational objectives.

6. Mentorship and Coaching: While managers focus on career growth and performance, architects guide team members in technical areas, helping them improve their skills and understanding.

By developing these shared skills, architects can effectively lead technical initiatives and influence teams, even without formal managerial authority.

info

It is not a coincidence that I have pointed similarities to Managers and differences with Engineers. This is how I look at architects role: leadership responsibilities and enabling others should be more important than individual contributions.

This mindset is not obvious, as architects are on individual contributor path in organizations and individual goals may be not stated like that. But the point is that even making individual contribution to codebase, that contribution should rather be an enabler for others, not only a local win. This is how you can make a bigger impact.

Despite similar focus on wider long-term goals, architects use different tools to drive desired outcomes:

• Not 1-1s but code reviews, pair programming, diagrams and technical docs
• Not career frameworks, but technical frameworks
• Not organizational procedures, but standard CI/CD workflows and design governance
• Not business KPIs, but technical metrics.

The above artifacts may count as architects' individual contributions, but tha artifacts should be designed and created to enable better outcomes in wider organization.

It is also worth to note, that architects have much less formal responsibility compared to Managers. Managers often keep architects accountable for a number of things, and will depend on them as technical advisors, but formally it is very different. Managers typically carry much more formal responsibilities on their shoulders. Architects should aim to enable not only Engineers but also the management to deliver great outcomes.

Architects typically have more time to spend to get to the bottom of the things that need to be optimized. Such input is often invaluable to drive organizational changes together with people, product and project management.

OK, once we thought about how architects compare to other roles, now let's compare architects to architects.

Application Architect

Typical responsibilities and focus areas of an Application Architect include:

• Expertise in a specific technology stack, such as .NET, Node.js, Python, or PHP.
• Responsibility for the application's structure, frameworks, libraries, and application-level patterns.
• Contributions to key application areas, especially in bootstrapping projects and adopting new patterns.
• Active participation in code reviews.
• Defining and implementing testing strategies and code quality standards.
• Making decisions about infrastructure, CI/CD, and observability, considering overall organizational standards like chosen vendors or technology radar.
• Acting as an advisor to team members and stakeholders, including product teams, designers, managers, QAs, and, in smaller companies, even customers directly.

These responsibilities are often expected also from a team leader or a senior engineer. Many companies do not formally introduce the role of an Application Architect.

In my opinion, every engineer who wants to grow on a technical career path should aspire to act as an Application Architect. In this role, you should be able to build an application from scratch, run it in production, maintain it, and help your team members grow by demonstrating efficient practices.

System Architect

SAFe (Scaled Agile Framework) formally defines System Architect role as an architect responsible for architecture on the ART (Agile Release Train) level. Single ART contains 5-12 Agile Teams. System architect is responsible for technical enablers backlog for the whole ART. Technical enablers should contribute to build so called architecture runway - set of capabilities that facilities the delivery fo value by whole ART. Enablers may contain things like common infrastructure, frameworks, patterns, pipelines, integration patterns etc.

If company is not using SAFe, System Architect can be still applicable as a geneal role name for positions that are responsible for architecture of bigger systems that are typically built by multiple teams. Architects facilitate technical alignment across teams, provide architecture clarity, coordinate designs and drive technical decisions that impact multiple teams.

Solution Architect

As for Application or System architect, there is also no standard definition of a Solution Architect, and the lines between different types of architects can be blurry. However, the focus areas of a Solution Architect typically include:

• Integration of Multiple Systems: Software solutions often involve multiple software systems or applications working together.
• Leveraging Existing Systems: Building a solution may not always require creating a new application. Instead, it might involve integrating and modifying existing systems or adopting new third-party software. A good example is public clouds like AWS, where experts proficient in using cloud services to achieve specific outcomes are often called AWS Solution Architects.
• API and Integration Knowledge: Solution Architects do not necessarily need to know the implementation details of the software they use. Instead, they need to work with available APIs, data formats, and integration patterns.

In practice, when acting as an Application Architect, you also need to operate as a Solution Architect since no software is built in isolation. A typical application would integrate with various APIs, third-party tools, hosting environments, etc.

In larger organizations, Solution Architects typically do not contribute to application-level code. Instead, they focus on integrating multiple systems. Their key responsibilities include:

• Aligning software changes with business value.
• Providing high-level input such as diagrams or API contracts to engineering teams.

Having experience with application-level design across multiple technologies is beneficial. It allows Solution Architects to quickly understand the capabilities and limitations of the systems involved without needing deep knowledge of each one.

In SAFe, Solution Architects work across ARTs.

Enterprise Architect

Enterprise architecture can seem less exciting if you prefer hands-on technical work, but it plays a crucial role in managing an organization's IT landscape, especially in large companies with hundreds of IT systems.

Enterprise Architects need a very good understanding of the business side of the organization. They assess the IT capabilities required for the organization to operate efficiently. This involves developing long-term technical strategies and making decisions about technology partnerships, operational cost efficiency, build vs. buy considerations, decommissioning legacy software, and IT budgeting.

Enterprise Architects often advise directors, C-level executives, finance, and business teams. They maintain a software inventory, drive software lifecycle decisions, and identify gaps that need to be filled by introducing new IT capabilities.

Achieving enterprise-level goals might involve driving implementation of organization-wide integration platforms, cloud transformation, data & AI capabilities, DevOps tools, or things like common API management. This role isn't just about creating Excel sheets and PowerPoint presentations; it also involves technical assessments of various platforms, solutions, internal IT competences and 3rd party vendors.

Summary

Having personally experienced all these roles, I believe that not every engineer who avoids the managerial path should aim to become an Enterprise Architect. These roles are distinct, and many may not enjoy being distanced from hands-on implementation or design tasks.

You can have a successful IT career either by remaining at the engineer level or by pursuing a more "big picture" position as an architect or manager. While architects often earn more, there are fewer job openings for them. Top engineers at leading companies can surpass a statistical architect in both compensation and impact. Ultimately, success is about discipline, collaboration, and dedication, which are easier to achieve in a role that suits you well.

One thing is certain: it's challenging to shortcut your way to a higher-level architecture role. Detailed technical experience is crucial for effectiveness in broader architectural responsibilities. And once you are working on a broad context, it becomes crucial to stay relevant with modern technology. Otherwise, it wil be difficult to drive modern organizations with outdated experiences. No matter where you are now in your journey - "stay foolish, stay hungry" :-)