Role and functions of an architect in a software development project

In this article, we clear up some of the popular questions about the roles, functions, and responsibilities of an architect in a software development project. 

At the stage of a new software project evaluation, it is crucial to analyze and define the main technical characteristics of the future product and how well it achieves a customer’s business goals. In the IT industry, such functions are performed by the software architect, whose role may be distributed among different team members.

Who is an architect?

The architect in the IT-sphere is a person responsible for making technological decisions regarding the software solution and its compliance with customer business needs. Such an expert knows the systems and methodologies applied in the development process, the languages used for coding and the architecture building process as a whole. The architect plays an important role in the process of discussing, developing and implementing a technological product meeting the business needs of a customer.

Architect functions on a project

The architect’s work and decisions directly affect the activities at every stage of the project. Basically, a major part of the architect’s responsibilities relates to the early identification of the concerns regarding product delivery. The architect makes decisions to mitigate the detected risks for each process: business needs capturing, planning, implementation, testing and deployment.

In a nutshell, the architect’s activities include defining the results of each development stage to get the expected product. The following function set expresses such activities in more detail.

Understanding the purpose

The main interest of the architect is to understand the customers’ needs and the goals they want to achieve by implementing a new system (or reworking an existing one). For example, such needs or goals could be sales increasing, entering a new market, costs optimization, etc. While gathering this information, the architect focuses on finding potential failures in the technical aspects of the software.

Here at *instinctools, often a customer has an existing system that was developed considering only the functional requirements. The previous vendor (or in-house specialists) could have delivered all the required functionality, but the product doesn’t satisfy the customer anyway. Why? In most of the cases, the system wasn’t aimed to solve the business problem. No one validated that the required functionality provided the required solution.

To minimize such risks, we suggest that the architect be involved from the first clarification call. Together with business analysts, architects can identify the purpose and possible “pain points” at the earliest stages of the future project.

Defining quality attributes

From a customer or a user perspective, any software system can be defined by its functionality. But there is an aspect that is often omitted while considering the system requirements: the system’s quality, i.e. how well the functions are provided. Each quality aspect is expressed by the term quality attribute. Here are some examples of such attributes:

• performance (response time, hardware resources required, max number of users working with the system at the moment, etc.)
• usability (UI simplicity, easiness of operation, user error protection, etc.)
• reliability (max possible downtime per year, fault tolerance, etc.)
• maintainability (efforts for the system modification).

It’s a common wish to implement a system with ideal quality. But in reality, it would be quite costly, extremely time-consuming, and, in general, impossible. The good thing is that software, being in a specific environment, doesn’t need to be ideal in all aspects. For example, a CRM system in a 10,000-employee company doesn’t need the functionality for a billion users access as a worldwide social network do. But also the CRM requires much less human and hardware resources to support it.

That’s why it’s important to have clear quality attribute requirements during software development. And it’s the architect’s job to identify them. Understanding the purpose of the product and the customer’s goals, the architect prioritizes and emphasizes the crucial quality attributes for further product implementation.

Building a technical solution (architecture)

An architect deals with different technological aspects: existing programming practices, development frameworks, data storage engines, cloud technologies, testing strategies, etc. Such an expert uses this knowledge to compose a vision of the system that will solve the business problem. The common word for this vision is the solution or architecture.

Since a single problem can have multiple solutions, the architect has to validate each of them, test hypotheses, and build required prototypes. As a result of this work, the architect proposes the most suitable option. It implies the reasoning that includes:

It’s no secret business people and IT specialists speak different languages. Both sides often complain that it’s difficult to communicate with each other. However, it’s crucial to have an unambiguous understanding of the developing system. That’s why there should be a person that will understand both sides and make a “communication bridge” between them. An architect is that person who can bring an understanding of the business domain aspects to engineers and explain to business people what the system really is.

Architect: Role vs. Job

Here at *instinctools, we have a strong belief that any software project requires someone responsible for the activities mentioned above. But it doesn’t mean that any development team must have a member with a special “badge” to make the architectural decisions.

For example, a lead software developer with deep expertise in the project domain who has already earned the customer trust can determine the solution for the product as a whole. It would be also more effective to delegate architectural decisions to a specialist in a specific technological stack if the solution is completely based on it.

Another common case is when the architect’s functions are distributed among other project participants. For instance, a project manager with a technical background defines the functional and quality attribute requirements. Meanwhile, a lead developer is responsible for building a technical solution. Both of them are capturing the business purpose and bridging the communication gap.

The distribution of an architect’s role among team members depends on the project itself. A system’s complexity, the developer’s background, the terms of cooperation, and other conditions can affect it. But in general, when the project has many unknowns and requires more technical engagement, the role is assigned to a solution architect, who is an expert in such tasks.

Within several years of delivering software solutions, *instinctools has gained certain experience in optimizing processes for achieving customer goals. That implies an understanding of technical requirements and how they correlate with customer business goals. Here at *instinctools, an architect performs such expertise at different stages of a software development project. Whether a person or a role, the architect uses their expertise to better analyze business problems or the current system’s drawbacks and suggest the best possible solutions for the future that we are ready to deliver. Now.