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 and ecosystem across the enterprise. (He/she focuses on all the software in the enterprise landscape)
Provides strategic (technology) guidance to the organisation and handshakes with business users and CxO.
Provides high-level abstracted reference roadmaps to the solution architects.
Domain architect
He/she is responsible for a particular technology domain. E.g. he/she could be a:
Database Architect is responsible for designing, engineering and guiding the data store technology.
Cloud Architect is responsible for designing, engineering and guiding the cloud (platform) deployment, engineering and creation aspects.
Integration architect is responsible for designing, engineering and guiding the integration technology.
Infrastructure architect is responsible for designing, engineering and guiding the infrastructure required for the organisation (VM, Containers, Network and so on).
Mobile architect is responsible for designing, engineering and guiding mobile development (Native or MAPD).
Security architect is responsible for designing, engineering and guiding the security (AAA & Vulnerability) of the system and enterprise.
Performance architect is responsible for making sure that enterprise at large performs as per SLA expectations and guides the engineering team if need be.
Of course, the above definition will vary from one organisation to another. Each organisation will have their way of defining the roles. Sometimes, the functions are clubbed, and sometimes the roles are given different names/titles. But in general, above grouping should hold its ground.
I am sure, the delivery managers are smart folks, but during a difficult situation, expectations and roles are not always seen within the ambit of defined boundaries.
Also, I am hopeful that an aspiring architect gets help from the above information and can pick the path with better clarity and with right expectations from the role.
Conclusion: One architect ain't fits all!