Architectural Drivers: Why We Design Systems the Way We Do

Software architecture is simply a collection of decisions you make as an engineer. Those choices should not stem from intuition, chance, or the current hype. Every structural change, every database choice, every technology pick must be grounded in the realities of the project. The forces that drive us toward specific decisions are called architectural drivers.

When you define these drivers well from the start, you save enormous amounts of time, money, and misunderstandings. Today's IT market offers an endless choice of technologies, frameworks, and architectural approaches. Well-defined drivers act as a filter: they eliminate unnecessary options, keep focus on what the business truly needs, and protect against Hype Driven Development and over-engineered team visions.

Five Classes of Architectural Drivers

From an architect's perspective, all requirements and conditions influencing a project can be grouped into five straightforward categories. Each targets a different piece of the puzzle.

1. Functional Requirements

This is simply the list of features and behaviors the system must deliver for the business to make money. Although architecture focuses primarily on structure, key business processes — known as architecturally significant requirements — heavily influence the shape of the application.

Example: You're designing an educational portal where teachers upload long video recordings. The system must automatically generate captions (transcription) and compress the file to several resolutions. That single requirement immediately rules out simple, synchronous processing in the main application thread — users would get a browser timeout. It forces an architecture based on task queues and asynchronous background workers.

2. Quality Attributes

These define how well the system should operate. Here we enter the realm of numbers and measurable parameters — properties like scalability, security, extensibility, auditability, configurability, and observability.

Example: The home page render time must not exceed 500 ms under a concurrent load of 10,000 users.

3. Constraints

Projects don't come to life in sterile conditions. Constraints are facts and decisions imposed from above that you, as an architect, cannot change — you must simply accept them. They typically concern time (hard deadlines), budget, law (e.g., GDPR), and the competencies of your team.

Example: Even if a niche new database fits your problem perfectly, you won't pick it if the dev team doesn't know it and the system must ship before Black Friday. You also won't buy an expensive commercial database if the project budget calls for minimizing licensing costs.

4. Conventions

This is the set of internal rules, standards, and best practices that apply within a given company. Their purpose is to keep systems across the organization consistent and allow developers to rotate between projects with minimal friction.

Example: If your company has a proven, deployed monitoring system, you use it instead of introducing a custom solution. Deviating from this principle requires very compelling arguments.

5. Project Goals

This category is about why you're building a given system at all, and how long it needs to live in the market. You choose tools differently for a system that will run in a bank for the next decade versus a quick business experiment.

Example: If you're building a quick prototype (MVP) to validate a business idea, you can cut corners and use an in-memory database for lightning-fast deployment. If you're building a production-grade stable system, that shortcut will be a mistake — choose durable tools instead.

Trade-offs: When Architectural Drivers Conflict

Architectural drivers have one very important characteristic — they are local. You don't need to design the entire system to the same exacting standards. Expecting every module to be super-performant and extremely secure to the same degree is the fastest route to burning your budget.

Drivers also shift depending on the phase of the project life cycle:

• Implementation (writing code): the most important qualities are readability, testability, and extensibility.
• Deployment: ease of configuration across different environments becomes critical.
• Maintenance (production): security, scalability, observability (metrics, logs), and raw performance take center stage.

As business reacts to the market, its priorities shift — and with them the drivers and the architecture itself.

Drivers are not set in stone — review and update them regularly. The best source of knowledge about them is the stakeholders: developers and CTOs, business and management, lawyers, and external regulators.