Architectural Design: Balancing Functionality, Quality, and Constraints

Architectural design is central to the success of software systems. It involves more than just defining components; it requires balancing the project's purpose, primary functionalities, quality attributes, and constraints to create an optimal structure. Every decision made during this phase impacts the system’s success and long-term sustainability, making it a crucial step in achieving the desired goals and effectively navigating trade-offs.

Architectural Design:

Design is a verb and a noun. It’s a process/activity thus a verb. The result of the process is a description of desired state – an artifact, thus a noun.

An architectural design is balancing design purpose, primary functionalities, quality attributes, and constraints and coming up with some structures, therefore an important step in achieving desired project goals. An architect may need to trade-off one critical quality attribute over another, and thus architecture may not always to the ‘best’ one. A decision is important from architecture perspective, if it has far-reaching effect on achieving desired quality attributes.

Post identifying elements accommodating primary requirements, an architect may propose inter-element interactions and even more details of elements’ internals (respecting its public interface and keeping opportunities for future non-breaking updates).

We’ll look at the architectural drivers in little more details now:

Purpose:

An architecture can be made for different purposes and can have varying levels of detail/complexity. For ex, an architecture design for a pre-sales activity may not be quite detailed but enough to predict its feasibility, budget, timelines etc. An architecture to build a prototype may be just enough to explore something unknown right now (ie fitment of a new technology, or to get customer feedback early), and may focus on a few critical aspects only. Or you may be designing for a regular project, needing to satisfy all critical aspects.

Quality attributes:

The measurable and testable *bilities, and affects the architecture most. May also include user-stories – the important scenarios that the system must support, i.e. what happens when user takes an action etc. Their importance comes from users, and technical complexity comes from architect.

Primary functionalities:

Generally, functionality is not affected by the architecture, i.e. a monolithic or service-oriented architecture may have no difference (ie still support same functions) from end-user perspective. However, these are the critical use-cases scenarios for which the system was first conceived and may or may not be directly related to quality attributes.

Other concerns & constraints:

concerns like logging, dependency management, organizations’ internal constraints, configuration management etc, and other constraints like skills available in the team or in the market, some laws to comply with, an enforced usage of a technology, or a plain deadline to deliver etc have their share of effects on architecture. Architects typically have no control over the constraints but rather required to satisfy them.

In conclusion, architectural design is a critical phase in the development of software systems, requiring a careful balance of purpose, primary functionalities, quality attributes, and constraints. The decisions made during this phase have a significant impact on the system's success and sustainability. Architects must navigate trade-offs, often prioritizing certain quality attributes over others, to achieve the desired project goals. By understanding the architectural drivers—purpose, quality attributes, primary functionalities, and constraints—architects can create an optimal structure that meets the project's needs while accommodating future updates and changes.