top of page

Types of architects (software)

There comes a time in the project when the IT project manager or the delivery manager will scream and exclaim "I need an architect!". The manager is facing acute performance or security or practical issue that he feels only a technical expert can fix. And that expert has to be an architect!

Within a week, preceded by many escalations, the team finds an "architect". The architect comes and understands the problem. And the solution to the problem lies in the design. The design is not scalable and needs to be re-engineered, informs the architect.

Fine, says the delivery manager. Fix it is the expectation. But the architect says - "I am not hands-on with programming since some time but can guide a tech lead!"

Disappointed and agitated delivery manager is not happy with the architect's "attitude" to solve the problem, but he feels that the architect is trying to deflect responsibility. However, the architect stands his ground suggesting that he is a solution architect and cannot fix the issue by revamping the code.

A myth associated with the software architect is "he/she could & should any technical issue that the project team is facing".

This article tries to explore the myth or wrong expectation from software architects. Specialisation is paramount when the amount of knowledge in the given field exceeds a limit. And since the software architecture is a vast amount of experience, it is essential to reduce the duties of a person for better productivity and in-depth understanding of a given area.

There are different types of architects. The diagram below lists some of the most crucial types:

Every kind of architect has specific roles and responsibilities. The following listing will help in to understand the same at a high level.

System architect

  • Helps the team understand the given system from an engineering point of view.

  • Has in-depth technical knowledge.

  • Can play a cross-cutting role taking technical & management decisions.

Solution Architect

  • Provides technology backed solutions for the system or application.

  • Bridge the system architect and product management or business users.

  • Participates in the framework or POC / POT development.

Technical architect

  • He/she is more like a super engineering expert and works very closely with the engineering team.

  • Codes for key / complex features or stories as part of the scrum team.

  • Interacts with different team members, participates in deployments and triage calls.

Product architect

  • Participates in designing and architecting the technology aspects of the software product (one has to be mindful of the difference between custom developed application and a product.)

  • Participates in the framework or POC / POT development.

  • Interacts with different team members, participates in deployments and triage calls.

Enterprise architect

  • Plays a crucial role in defining the technology roadmap a