Skip to main content

Architect role

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.

Common misunderstanding is that an architect is an uber-developer that has the best coding skills int the room. In my opinion it is a mistake to define architects like that. Instead, architecture should be about broader perspective that typically comes at the cost of scarifying deeper understanding of codebase nuances and not knowing anymore hundreds of SDK functions from memory (apologies to all genius minds reding that, I am generalizing here). Architects focus on how bigger blocks of software interact. Focus area is not functions or classes, but modules, applications, bigger systems to whole enterprise IT ecosystem. Ability to do deep dive or contribute to code of course is useful, but it is not a typical daily task for architects, as it is for developers.

Throughout my career, I've held several 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.

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. 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" :-)