To some people, there is a certain mystery about the role of a Technical Architect (TA) engaged in development work. This is understandable because of the way that the TA must change and evolve the role in response to such factors as …

• the specific business context,
• The project phase
• The character of the relationship with a customer
• Technical constraints
• The size and number of teams working on a particular project

Despite the great variation, we’ve found in our experience here at Objectivity that there are certain responsibilities that are common to the role of Technical Architect in development work . These are …

• Technical vision,
• Delivery focus,
• Health of the teamwork,
• Positive Customer relationship.
• Organisation and management

Each of these areas is worth a dedicated series of articles but I will try to briefly describe each of them in this article.

Technical vision

For many people, the technical responsibility will seem to be the most obvious; this is probably due to the natural tendency to think of the role of technical architect as the next stage in the technical career path of a senior developer.

It is a fair assumption to make, but 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, internationalisation, branding, security, auditing, diagnostics & logging, failover 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 focussed primarily on solving those challenging problems that actually require writing the bespoke piece of code.

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 evangelising and promoting good practises (SOLID, KISS, DRY), tools (FxCop, StyleCop), 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 materialises in code.

Healthy teamwork

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 organisation. 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.

Organisational activities

As well as all the project-based roles, Technical architects will bear responsibility for several organisational and management tasks. TAs here at Objectivity are organised as a virtual team (called “guild”) that is engaged in many actions and tasks on 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 in a form of bulletin called “technology radar”. Additionally, experience gathered in many projects of a very different nature, empowers TAs to define an internal development infrastructure and standards like source code repository, bug management systems, code quality metrics and coding guidelines, Moreover, depending on TAs specialisations, they also personally support other guilds, different communities and areas of specialisation that arise on cross-projects / company level, like performance community, test automation group, testers guilds or Continuous Delivery minstrels. It is especially important to support and foster this last group; TAs are aware how important is the reliable Continuous Delivery infrastructure and so they participate in a process of creating a companywide vision and standards in this area.

TAs 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 TA candidates. As the consequence the play a very important role in the team members’ induction and growth by conducting the trainings and workshops or organizing coding events.

Summary

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. As well as this is the responsibility for the technical quality and successful delivery, and a good relationship with the client.