I've recently been given the role of Technical Architect in my organization (I will also be project managing some projects and developing if the 10-12 senior developers are all too busy).
I'm wondering whether a technical architect should have a strong role at the start in defining the project architecture and the right developers for the project - but then takes a back-seat during the actual project. Is that reasonable?
Technical architect is a specific role as expectations for person fulfilling it differ much depending on organization and even with the same organization depending on a project.
In short technical architect should take full responsibility for, well, software architecture. Not only does it mean designing it in a way which allows to fulfill all non-functional requirements, e.g. scaling, performance, but also making it reasonably easy for developers to build software. You don't get points for fancy top-notch architecture if development team struggles to build the application and maintain them.
When I think about responsibility I consider it throughout the whole project. Architect's job isn't done when development starts as architecture may be, and usually should be, evolving over time.
Also in many agile projects you may find architecture which is built incrementally - you set only general borders up front and then add and change it as you add new functionality. Again, if you plan to adjust to changing requirements when it comes to features you should plan the same for architecture so the work isn't done at the beginning of the project.
I would also say that it's technical architect who should care about technical debt in project. Whether it is incurred and when, if ever, it is payed back. Of course as long as anyone even cares about such thing.
Usually it isn't direct architect's responsibility but I'd add responsibility for project maintenance as we often see projects which are even finished on time but then maintenance costs skyrocket and sometimes the main reason is either bad architecture design or poor execution, i.e. not ensuring that development team is following guidelines.
Now the vague thing here is how we understand architecture. It can be anything from just some general high-level guidelines up to detailed rules what should and what should not be done, which tools, libraries, design patterns, coding standard, etc. are used and which are not. Anyway, however architecture is defined in the organization or the project all architecture-related issues should be addressed to technical architect.
If you're going to be working on multiple projects, I think you need to be sure that your focus is on the cross-project picture, and not too intensely on any one project. If you become the major decision maker/architectural owner for the core of each project, you will eventually become a chokepoint as you are deluged with questions from the team on what you've decided.
I'm a strong proponent that the people who make the final call on architecture should be the people who will be stuck with implementing it and bugfixing the final product.
Given that you're doing cross-project work, I would think your responsibilities should be:
If there isn't a person each project who has the primary responsibility for that project, then you have a problem. The minute your role becomes being the primary owner of a given project you will have to make the decision between focus on that project and a sweeping focus on all projects.
To me, it is a big red flag that you are being asked to be the organization's Technical Architect (responsible for the architecture of X number of projects), project managing Y number of projects, and being a developer on Z number of projects. I don't know how you will manage to be successful in all 3 roles, in X+Y+Z number of projects.
I have tried doing both development and project management at the same time, and it usually involved taking turns neglecting one role vs the other.
The fact that you are being asked to do all these things does say to me that the organization thinks very highly of your skills and knowledge, so that is a good thing! But just don't take on more than you can successfully manage.
In RUP Software Architect is responsible for Software Architecture Document (SAD), which is a bridge between Software Requirements Specification (SRS) and Software Design Document (SDD).
In practice it means that an Architect has to be responsible for information transfer between problem domain and solution domain, across the entire project lifecycle.
As a Technical Architect (TA), the following is your role and responsibility: Holding a Design, Build, Testing point of view along with providing high-level design-, low-level design-, and test-driven development- related documents updates as per the business requirements. Take major roles for decision making.
Of course, all of the actions above should, as a consequence, lead the team and the project to a successful end, bearing in mind that, for the customer, the most important thing is the successful delivery of the project. Therefore, it is crucial for the architect to know the release plan.
On the technical side, in addition to proper design, it is also important to take care of operational and infrastructure aspects; without consistently configured environments, a code repository, bug-tracking system, project-tailored continuous integration & deployment flow, the project delivery may be at risk. Obviously, as in previous cases, the TA does not have to do the work associated with the implementation of these aspects with his own hands; he rather collaborates with the Project Manager and Release Manager to ensure them that everything is fine and to deliver upon the team’s requests.
Technical Architects who work within development projects are ultimately responsible for the technical solution, ensuring that the technical architecture is suitable within the context of the client’s technology stack and that it is aligned with the skills and profile of the development team. The architect must ensure that the development infrastructure meets the needs of the team. This is the TA's responsibilities: for the technical quality, for successful delivery, and for a good relationship with the client.
In most of MNC , we had experienced a trend giving software architect role to project manager who have completed a good tenure ( 5 year ) with a company . This happened at that instance when tech architect switched company with providing appropriate KT to his reporting manager who will take his architect role in parallel to hiring a new architect . This goes to company management persuasion .
