And now, Why?

Software architecture acts as the bridge between the problem and solution spaces. It is where critical decisions are made to ensure the design fulfills requirements—specifically systemic qualities such as performance, security, modifiability, and availability.

This is not a simple one-to-one mapping, but rather a complex network of interdependent decisions. Every choice has a ripple effect; for instance, a decision to prioritize security may directly impact both availability and usability.

Consequently, designing software architecture is an iterative process of balancing trade-offs. Even in simple systems where the architecture follows well-known styles—often already embedded within frameworks—decisions must still be made regarding which framework to select and how to apply it to the specific problem at hand.

Software architecture is not merely a set of decisions; it also includes the mechanisms for verifying their impact and ensuring that the implementation remains consistent with the defined architecture.

The role of Large Language Models (LLMs) in the architectural phase of software development is multifaceted.

First, within the problem space, the focus is on the ‘what’—specifically the non-functional requirements (NFRs) previously discussed. LLMs can assist us in both eliciting and specifying these requirements to ensure a comprehensive architectural foundation.

In the opposite direction, LLMs can assist in verifying that the code conforms to the software architecture. This is particularly relevant in projects that follow a harness engineering approach, where automated checks ensure structural compliance.

The most compelling aspect, however, lies in the decision-making process itself. In my experience, asking an LLM to make these decisions often results in a broad array of plausible options that, while logical, may not be the ‘right’ ones for the specific context. The true challenge is not merely identifying potential solutions for requirements, but finding the adequate balance between them—a quality defined as the elegance of the architecture.

Therefore, while LLMs serve as a generative aid, their contributions often oscillate between being overly broad or excessively granular. The software architect retains the vital role of synthesizing these inputs, ensuring that the final architecture remains both functional and elegant.