How to become a Technology Architect

Almost every developer wants to be a technical architect one day but most are not aware of various responsibilities of an architect & the road-map to become an architect. Fact is the the role & responsibility of a Technology Architect changes and evolve in response to the specific business context, project size, complexity & phase, technical constraints & technology landscape of a particular project. Despite the great variation, that there are certain responsibilities that are common to the role of Technical Architect in a delivery project

• Technology Vision,
• Delivery Focus,
• Technology Skill,
• Customer Relationship.
• Organization & Management 

Technology Vision

There are some important differences between the architect and developer. An architect must take responsibility for the overall technical direction of the project and the product whereas the developer will be given responsibility only at component-level. He or she needs to assure that it will stay open for changes and that these changes can be implemented in a technically excellent and cost-effective way.
This requires a rather different skill, in predicting and anticipating these requirements, and having strategies and plans in place. This isn’t just experience of the development project cycle but a matter of asking the right questions at the right time, most often at the very beginning of projects. The start of a project is generally a critically important phase, because all the decisions that are undertaken during this period can affect the success of the entire project, for better or worse: This is true even of agile projects.
In order to find the most appropriate architecture and components, the team must not only focus on determining the business goals and requirements but also on clarifying the functional requirements. These functional requirements will include cross-cutting concerns like performance, scalability, compatibility, internationalization, branding, security, auditing, diagnostics & logging, fail-over and disaster recovery. The consequences of ignoring any of these topics at the beginning of the project can be catastrophic, though a smart architect can transparently enable some of them later, by creating an architecture that is open for such changes or extensions. .
As part of the task of determining the architecture and components, the technical Architect must identify the most suitable technology stack and frameworks. The architect does some research, finds those third-party solutions that are most appropriate, and proposes how to integrate them. By using third-party components and frameworks, the efforts and energy of the team can be focused primarily on solving those challenging problems that actually require writing code.

Delivery Focus:

Responsibility for the quality and effectiveness of code is, of course, shared by the whole team; however, an architect needs to challenge the team and help it to implement even better code which meets industry standards. This can be achieved by evangelizing and promoting good principles & practices (SOLID, KISS, DRY), tools, metrics – or just by giving a good example in doing regular development tasks. This last aspect is very important because it helps the architect to stay close to the team and technical nuances as well as allowing him to double-check how well the proposed design materializes in code.

Technology Skill Development

An architect is an integral part of a team but, because of his experience, he has a large impact upon a team and imprints his mark on it. While proposing a solution, the architect must be sure that the team he is working in shares the same vision. This vision should be well understood and accepted by the team, so that the solution is correctly implemented. Moreover, the team should be able to take over the proposed solution, develop it and feel and act as is they own it. To achieve these goals a TA needs to work on two fronts: in addition to such obvious aspects as training, code review, daily coaching or a team’s involvement in the application design process, it may be necessary to align the solution to the skills and profile of a team – this applies both to the technology stack as well as to development tools.
Last but not least, as the project grows it is very important to delegate responsibility for some aspects of the application to the team so as to engender a good team spirit, and foster professional growth. At some point in the development cycle this may become a necessity, because the architect is not an expert in all the technologies and techniques that are used in a project.

Positive Customer relationship

The TA role, next to the Project Manager (PM) and Business Analyst (BA), is key in keeping a good relationship with the customer. This might take a different form depending on whether we are relating to the IT department or directly with business people within the client organization. Nevertheless, the most important foundation of this relationship is always mutual trust and understanding. Having the customer’s trust allows an architect to operate effectively with a high level of confidence. It guarantees a proper level of autonomy and shortens the decision-making process, allowing the architect to react quickly to emerging challenges that very often occur in agile projects. Of course, this trust is partially based on the proper records and registries, which make an architect’s job as transparent as possible. Depending on the project, the TA may leverage a decision log, technical debt log, risk & assumptions list, or just a product backlog, on which a TA keeps the key components or actions in the form of product backlog items.
Looking back at the history of the relationships with our customers in various projects, we noticed that the TA, BA and PM act as the voice of the team. They care collectively about the consistency of communication on a business- and technical-level. Proper cooperation of these roles empowers the team and allows it to move to a higher level of collaboration. Instead of just focusing on daily tasks, the team becomes a trusted software and competencies provider, a supplier who shares its practices, processes and values with a customer.

Delivery focus

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 and make certain that the technical vision fits it, by planning related actions (e.g. release support) and deliveries (creating packages, writing deployment scripts) on a project backlog and prioritizing them appropriately.
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 PM and Release manager to ensure them and to deliver upon the team’s requests.

Organization activities

As well as all the project-based roles, Technical architects will bear responsibility for several organizational and management tasks. Technical architects in most organizations are organized as a virtual team that is engaged in many working with different tasks at the company level. They are responsible for the company’s technical competences by looking for new technologies and techniques, which are recommended to the developers and it engineers through training, workshops or newsletters. Additionally, experience gathered in many projects of a very different nature, empowers Technical architects to define an internal development infrastructure and standards like source code repository, bug management systems, code quality metrics and coding guidelines, Moreover, depending on Technical architects specializations, they also personally support projects, technology groups & communities and areas of specialization that arise on cross-projects / company level, like performance community, test automation group, Technology Architecture Groups, etc. It is especially important to support and foster this last group; Technical architects are aware how important is the reliable Continuous Delivery infrastructure and so they participate in a process of creating a company wide vision and standards in this area.
Technical architects  also ought to support thought-leadership initiatives in the areas of development and delivery. They provide very important input to the sales process by rendering work breakdown and estimates in all of a project’s winning phases. Finally, they very often act as line managers for developers, or mentors for Technical architects candidates. As the consequence they  play a very important role in the team members’ induction and growth by conducting the training and workshops or organizing coding events.

So get started on , empower yourself with relevant training and certifications that will help grow your understanding of different technologies and architecture and try for opportunities where you can work on small projects/modules that give you can opportunity to work as an architect. Don't be afraid of challenges and be willing to put extra hours to read/research/experiment with your architecture. Your experience will build your credentials which will help you get bigger opportunities and you will soon be on the move!