Role of the Technical Architect
The question “What does a Technical Architect (TA) at Objectivity do?” often crops up during recruitment and in conversations with developers. Alternatively, they may ask “What would my duties be?” or “What would I be responsible for?” In fact, every architect currently working at Objectivity regularly asks himself this question. The answer very often varies as the role of a TA changes and evolves over time. It depends on a specific business context, project phase and character of relationship with a customer as well as on technical constraints. It is also influenced by the size and number of teams working on a particular project. Nevertheless, our experience at Objectivity shows that, irrespective of the above factors, we can find common ground in all answers regarding several areas of responsibility. During a recent visit by Dan North, we have identified them as follows:
- Technical vision,
- Delivery focus,
- Health of the team,
- Customer relationship.
Each area is worth a dedicated series of articles but I will at least attempt to briefly describe each of them in the rest of this article.
For many people the technical responsibility probably seems to be the most obvious area; this is probably due to the fact that there is a natural tendency to perceive the role of technical architect as the next stage of a senior developer’s career. It is a logical assumption; however, there are some significant differences between these two roles. It is mandatory for an architect to control (or, to say more succinctly, “embrace”) the project and the product on a higher 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 pretty good anticipation of what might happen in a project or just calls for one to ask the right questions at the correct moments, most often from the very beginning of projects. The start of a project is generally a critical point in time, because all the decisions undertaken during this period can affect the success of the entire project – even if we are talking about agile projects. Finding the most appropriate architecture and components does not only demand focus on business goals and requirements; one must also properly address non-functional requirements as well as cross-cutting concerns like performance, scalability, compatibility, internationalisation, branding, security, auditing, diagnostics, logging, failover and disaster recovery. Ignoring these topics at the beginning of the project may lead to dreadful results, even though a smart architect can transparently enable some of them later, during implementation and product growth as an aspect of a delivered solution.
While mentioning architecture and components, we are touching on another architect’s responsibility to propose the appropriate technology stack and frameworks. The architect does some research, finds 3rdparty solutions and proposes how to integrate them, to focus the team’s effort and energy primarily on solving challenging problems that actually require writing the bespoke piece of code. Speaking of code, we must remind ourselves of the quality aspect. Code is, of course, owned by the whole team; however, an architect needs to challenge the team and help it to implement even better code which is compliant with 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.
A healthy team
Architects are an integral part of a team but, because of their experience, they have a large impact upon a team and imprints their 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 corresponding 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, when project grows it is really important to delegate responsibility for some application aspects to the team to engender a good team spirit. At some point this may become a necessity, because the architect is not an expert in all the technologies and techniques that are used in a project.
The TA role, next to the Project Manager (PM) and Business Analyst (BA), is key in keeping a good relationship with the customer. This relationship might look a little bit different depending on who we are dealing with on client’s side: the IT department or business people. 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 diaries, which make an architect’s job as transparent as possible. Depending on the project, the TA may leverage: 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 relationships with our customers in various projects, we noticed that the TA, BA and PM are a 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.
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 project delivery. Therefore, it is crucial for the architect to know the release plan and assure that the technical vision fits it. Again, the right tool to address this aspect on an organisational level may be a backlog and the appropriate prioritisation. 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, project-tailored continuous integration & deployment flow, the project delivery may be at risk. Obviously, as in previous cases, the TAs do not have to do the work associated with the implementation of these aspects with their own hands; they rather collaborate with the PM and Release manager to ensure them and to deliver upon the team’s requests.
Besides project tasks, TAs at Objectivity are engaged in many actions and tasks on the company level. Obviously, they are responsible for the company’s technical competences by looking for new technologies and techniques. They 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.
The aspects described above sum up the role of a technical architect at Objectivity. As I mentioned in the introduction, depending on the project or customer, accents might vary in daily work. A common feature, however, will always be the self-assigned motto of the architects at Objectivity, read is: “Architects care the most”.