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!
