5. Technical Architect

In a purely software project, the Technical Architect (TA) can also be thought of as the chief designer or lead developer. The remit of this role is to bridge the gap between the business problem and its technological solution.

It's worth taking a minute to distinguish between an Enterprise Architect (EA), Solution Architect (SA), and TA, because these terms are sometimes used interchangeably. However, going by industry best practice, there are important differences in their definition.

EAs focus on a higher, strategic level across the entire organization. Therefore, they concentrate on long-term trends and foundations across all projects and operations; for example, a "cloud-first" strategy, whereby any new solutions being designed should consider cloud hosting as the first option. This supports major commercial activities such as the exit of an on-premise data center-hosting contract.

SAs have a broad range of technical knowledge, including infrastructure, hardware, and software products. They oversee the process of choosing and buying technology solutions. Together with EAs, they create technology roadmaps. For example, when a particular hardware or software product reaches its end of service life, the roadmap plans what the replacement product should be.

Technical Architects have the most focused, in-depth knowledge in a particular technology area because their work is more specialized, for example, Java or integration architecture. In contrast to EAs and SAs, they focus on implementation activities and typically work on a small number of projects at any one time. They work on tailoring the chosen technology products to solve the current business problem. Ensuring that the project designs and implements an application that supports the overall enterprise strategy.

At a project level, the TA is the most relevant and most hands-on in terms of approach. They provide technical leadership for development teams and define best practice standards for them to follow. They also help individual developers to understand and work within the design principles, at times, assisting with technical troubleshooting and problem solving at a code level, if required.

The most visible part of a TA's work will normally be done at the application design phase. They collaborate with the Business Analyst and development team to understand the business requirements together and incorporate any technical requirements such as reliability and maintainability, such as Disaster Recovery (DR), before translating all requirements into a set of actionable technical specifications.

For example, deciding how the data needs to be structured and designing the database accordingly. Or designing the modular structure of the software to ensure it is flexible and performant, such as breaking down the data Extract, Transform, and Load (ETL) process so that certain extractions, transformations, and loads can share the same modules or use the same code.

An important role of the TA is to ensure any technical debt accrued by a project is clearly recorded and explained to the project stakeholders, as well as the SAs and EAs, and that there is a plan to repay that debt. Technical debt, and specifically code debt, is essentially a compromise on certain technical aspects of the software product, usually done to save time or cost.

This should not be confused with allowance for more bugs or defects, which is directly related to quality.

An example of code debt would be when there isn't enough time to redevelop and merge two ETL interfaces, which essentially do the same thing but were written at different times, using different adapters. So, a new interface is developed to sit alongside the existing module, which increases overall complexity, maintenance effort, and additional connections.