You’re starting a new project. The code still smells fresh, the backlog is full of promise, and as a team leader, you get that one question every developer dreads: should we go microservices or a modular monolith?
You know there’s no single right answer. Because, of course, it depends. But… depends on what exactly? On project scale? Performance requirements? Team size? Or maybe just because someone once said “microservices are the future”?
This is where architectural drivers come into play – subtle yet powerful forces that can completely change the direction of a project. They are your compass in the chaos of technical decisions, helping you answer not only what to build, but more importantly, why to build it that way.
This article is a comprehensive guide to Architectural Drivers – a knowledge compendium that covers everything from definitions and categories to real-world applications. You’ll learn how these drivers shape architectural choices and discover how the same set of drivers can lead to completely different outcomes in two distinct projects.
So grab a coffee and get ready for a deep dive into the world of architectural decision-making – where it depends finally starts to make sense.
What are architectural drivers?
Simon Brown, author of the book “Software Architecture for Developers” describes it this way:
“Regardless of the process you use — traditional or agile — there is a set of things that really drive, influence, and shape the final software architecture.”
To put it simply: drivers are the main factors — business, technical, and organizational — that force us to make specific architectural decisions, which ultimately influence the final appearance of our system. It's not without reason that they're called "drivers" — they control the architecture, direct it, and influence decisions. Drivers are always defined individually, for a specific problem, for each system individually. They form the foundation of the entire software architecture.
If we don't recognize them early enough, there's a huge risk that our solution will develop in the wrong direction. These factors determine whether we choose distributed or a modular architecture. And they ensure that the architecture responds to real needs, not just a coincidence. Without a thorough driver analysis, we risk excessive costs, technical debt, or simply creating a system that no one will want to maintain or develop.
Mark Richards, in his "Head First Software Architecture" book, places Architectural Drivers on par with what he calls three other dimensions of architecture. Each of these dimensions defines the software architecture, and each of them influences it equally. All dimensions also influence each other. Mark refers to Drivers as architectural characteristics – since it's common to refer to them as Architectural Drivers, that's the term we'll use.
Types of architectural drivers
Architectural drivers can be divided into four categories: Core Functionalities, Quality Attributes, Project Constraints, and Technical and Architectural Practices. Let's discuss each in turn.
1. Core Functionalities
It's a good idea to start every new project by analyzing and defining the system's core functionalities. To make this easier, it's worth answering a few basic questions:
- What exactly do we need to deliver to achieve the project goals?
- For what roles are we creating these functionalities?
- What is our minimum viable solution?
- What larger features are we planning for the next stages?
So, we're talking about what the system does. Based on these functionalities, the architect can make decisions on how to deliver a given feature, taking into account cost, time, and the team's experience.
2. Quality Attributes
After determining the core functionalities, we move on to quality attributes, also called architectural features or, imprecisely, non-functional requirements, depending on the literature. These attributes determine how well our system will perform.
These attributes don't exist in a vacuum, but are linked to the main functionalities. For example one of them states: "The system should be ready to handle Black Friday's traffic." This gives us information about the system's expectations in terms of a given functionality. Thanks to this definition, we can extract a quality attribute called flexibility and measure whether the system can actually handle a sudden increase in users on such a scale.
Quality attributes are all those "-abilities," such as scalability, observability, or testability. We have prepared a handy list of the most common quality attributes, along with their descriptions. Each of them shows how well it is supported by a given architectural style. This list is not complete — because it cannot be. Our industry is evolving rapidly, and software quality is defined differently today than it was just five years ago. That's why no one has yet compiled a comprehensive list, though many have tried. On the https://pistacy.io/tools/architectural-drivers.html, you'll find only the most popular quality attributes to get you started.
3. Project Constraints
Even the best plans must face reality. This is where project constraints come into play. These are all externally imposed conditions that we must consider. We typically divide them into three main categories:
Technological Constraints:
- What technologies must we use?
- What are the team's standards?
- What do we already have in place?
Organizational Constraints:
- What processes are in place within our company?
- Do we have to follow specific procedures?
Environmental Constraints:
- What requirements does the external world place on us?
- Do we have client-imposed deadlines or seasonal market requirements?
For example: If our project is to be ready by Black Friday, it's not enough to deliver the system "when it's ready." If we don't implement everything by Friday, our client will suffer enormous losses.
Note that these aren't decisions or choices, but the existing state of affairs. When you have the option to decide between solution A and B, we're talking about an architectural decision that should be described in an ADR. Project constraints describe reality and are non-negotiable (this is not a choice) – they can't be changed just like that. Understanding project constraints is crucial. Without them, we can create something technically brilliant... but practically useless.
4. Technical and architectural practices
Technical and architectural practices are simply a set of principles that guide a team's software development. These principles are specific and unique to a given project. They influence the coherence of the software being created, guiding decision-making throughout its development. Examples of such practices include: programming language selection, the use of specific linters for static code analysis, module structure, and even decisions regarding connections between microservices.
Conflicts between drivers
You're probably familiar with the triangle where you can only choose two out of three. You can do something quickly and well, but it will cost you. You can do it well and cheaply, but not quickly, and so on. It's similar with drivers, and especially with quality attributes. Imagine a situation where you need to create an efficient system that is both secure and allows for a high level of observability. Think for a moment – is such a system even possible to implement?
In specific situations, security requires the addition of data encryption or secure communication channels. Encryption is time-consuming, and so is observability. As more logs or observation points are added to the code, application performance decreases.
The table you see below lists the most popular quality attributes and their relationships. A plus sign indicates synergy, while a minus sign indicates conflict between attributes. Of course, not all drivers are mutually exclusive, but to make the right decision, it's worth keeping in mind that some interact with each other.
Full-width image can be found in here: https://pistacy.io/static/uploads/images/blog/2025/10/quality-attributes-synergy-matrix.png
If you want to have an automated mechanizm that checks if your quality attribute fits into existing ones, you can use Pistacy's Architectural Drivers module. Pistacy.io supports 36 predefined quality attributes so far, with relationships between them. When you want to add new attribute, you will be informed if it's in conflict or synergy with other attributes in list.
Driver Acquisition
Knowing drivers exist is one thing, but actually acquiring them is a different story. Each type of driver is acquired differently.
You'll obtain key functionalities from the business and stakeholders during discussions about what the system should do. You'll partially distill quality attributes from business descriptions, but you'll have to find others yourself in the maze of implicit requirements and features.
An example of such an implicit requirement is the business requirement "The system should be easy to develop because the roadmap changes monthly." When the architect receives this requirement from the business, he'll automatically understand that the system must be modular and flexible to meet future business needs.
Project constraints are a rather broad topic. Technological constraints can be found within the team implementing the system or within the client's infrastructure. Organizational constraints can be found within the company itself and within the team. Environmental constraints are everywhere. For example, for e-commerce systems, these can include holidays or days with increased sales, while for banking systems or those processing sensitive data, these can include data security and processing issues.
The range of places where drivers should be sought is very wide. Therefore, architects sometimes specialize in a specific industry, as this provides them with greater knowledge and allows them to make better decisions. This part of an architect's work requires significant commitment and experience, as poorly selected drivers can significantly impact the project.
The influence of drivers on architectural decisions
Now that you know what drivers are, let's move on to how they influence architectural decisions. Here are three different stories where you can see how driver can change the final decision.
Example #1 - SpecShop system
When building a SpecShop system, you need to design an authentication system, using both email and social media. This is the core functionality. Now, based on this, you can decide how to implement it. Your options include:
- writing your own solution from scratch, which would be time-consuming;
- purchasing a pre-built system that requires configuration;
- or using a SaaS solution, thus becoming dependent on an external provider.
Each solution has its advantages and disadvantages. If you add the project constraint of the Black Friday deadline, you're left with only two of the three options — because there's no time left to create your own solution. If we're talking about an e-commerce system, another driver is likely to be Black Friday flexibility, so we can't afford to become dependent on an external provider. The only option left is to purchase a ready-made solution, which is expensive but secure and scalable.
Example #2 - IoTaAnalyzer system
When building an IoTaAnalyzer system, you need to choose a database for your IoT data analysis platform, where devices send measurement data every second. Your primary functionality is the rapid storage and retrieval of large amounts of time-based data with non-defined schema. Based on this, you have several options:
- use a classic relational database (e.g., PostgreSQL)
- use a document database (e.g., MongoDB)
- or use a database specialized for time-based data (e.g., InfluxDB).
Each of these databases has its advantages and disadvantages: PostgreSQL provides relationships and ACID, MongoDB provides rapid schema development, and InfluxDB offers significant optimization for storing and aggregating time-based data.
And here is the game: you need to ensure ease of data reporting for analysts (e.g., the ability to use SQL and easy integration with BI tools). At this point, the list of possible options narrows: MongoDB, although fast, has limited query capabilities and more difficult integrations for analysts — it's out. InfluxDB, while great for time-based data, requires specialized knowledge of its own query language and isn't naturally compatible with most BI tools — it's out of the question. That leaves PostgreSQL, which, thanks to features like the TimescaleDB extension, can handle time-based data very well while also offering the full power of SQL and integration with reporting systems.
Example #3 - SmartDoctor system
You're building the SmartDoctor system and designing a new online doctor appointment booking platform. The main features include real-time appointment booking, doctor calendar management, and SMS/email reminders. Based on this, you can choose from several architectural styles, each with own strengths and weaknesses:
- a modular monolith is quick to build,
- microservices are scalable and fault-tolerant,
- a serverless architecture is great for fluctuating traffic and rapid deployment.
Now let's go deeper into the solution. The organization has a small development team — four people, without significant experience in infrastructure management. At this point, the architectural style must be adapted to this driver: Microservices are out of the question — too much organizational and technological overhead for a small team. Serverless looks tempting, but requires a lot of new knowledge that the team lacks, as well as complex monitoring — also out of the question. What remains is a modular monolith, which, with a well-structured code structure, allows for order, rapid functionality delivery, and easy change implementation, while not overwhelming the team with excessive operations.
As you can see, architectural drivers influence architectural decisions and solution selection. Every decision should be made in a holistic context — taking into account all identified drivers from each of the four categories.
Case Studies
The examples presented so far have been carefully selected to clearly demonstrate the topic. But what would learning be without real case studies, real projects? Now we'll show you two different projects, at different scales and levels of sophistication.
Case Study #1: Booking.com - High-Performance Project
First project is a Booking.com. The system is used by millions of users daily. The main functionalities are quite obvious, so we won't discuss them. Quality attributes are most important, as they play a major role in such large projects.
- Scalability, so the system can handle large traffic.
- High availability, to ensure minimal downtime – a key factor in customer trust.
- Fault tolerance, so the system ensures service continuity in the event of a failure.
- Performance, which impacts the user experience.
- Flexibility, allowing for the implementation of a wide range of services and features.
Now it's time for project constraints. What limitations might Booking have? The materials we found don't indicate anything specific, but as you'll soon see, such a large company probably doesn't have many limitations.
Let's now move on to the decisions made by the developers. Considering virtually all quality attributes, the decision was made to implement the system using microservices. They ensure independent deployment, fault isolation, and technological diversity. Do you already know why we struggled with these limitations? The need for scalability and high availability requires the creation of an architecture that allows for optimization not only in the form of increasing the number of processors or RAM but also adapting the technology to the given problem. The cost of such a system is high, but a company of this size has the budget to afford it.
Additionally, the use of polyglot persistence, where the system utilizes different database types, depending on the type of data stored, is interesting. Relational databases provide ACID for transactional data, NoSQL databases for semi-structured data such as user profiles or activity logs, and in-memory databases for cache storage.
The final noteworthy decision is the use of Event Driven Architecture for communication between microservices. This communication ensures service independence and scalability because messages can be processed in parallel by multiple microservice instances.
Case Study #2 - Pistacy.io - MVP Project
The opposite project is a Pistacy.io - a fresh SaaS platform. It was created to help developers and architects document software architecture. Key features include: the ability to manage ADR and RFC documents, C4 models, code metrics, database modeling, and defining Architectural Drivers for the project. This is a project being developed after hours, so the main factors here are development time and maintenance costs. We needed to design the architecture so that new features could be added quickly, without rehashing the entire system. And, additionally, the entire system would be sufficiently scalable. Therefore, the quality attributes are maintenance costs, extensibility, and scalability.
In addition, there were project constraints. The project is being developed in Symfony. The "Extensibility" driver, combined with "Maintenance Costs," forced us to adopt a modular monolithic architecture. The frontend was supposed to be reactive, so we chose Vue. We had a harder time with the database, as it was originally supposed to be based on standard MySQL. After a deeper analysis, we concluded that Postgres would be a better option, as the entry threshold is the same (especially since it's supported by the same ORM) but it offers more functionality. For example, more advanced full-text search, which we'll need. Instead of investing in ElasticSearch, a cheaper option was to focus on Postgres initially.
Let's summarize the Case Studies
It's not without reason that we chose these two completely different projects. Note that the drivers discovered resonate with the chosen technology, architectural style, and decisions made. That's why they're so important. Removing one driver or replacing it with another completely changes the balance of power.
But even drivers don't exist in a vacuum and are permanently connected to the business. In the case of an MVC like Pistacy.io, the number of users is small, and costs are a priority, so the drivers will be adapted to these realities. In the case of Booking.com, we're talking about millions of users and a measurable capital company that can afford microservices.
The "reason"!
The process of Drivers Acquisition is long and complex. Once you have defined Drivers, you know why those were chosen. But would you remember that in a year? The reason of "why" you have chosen particular driver, is as much important as the Driver itself. You won't be able to argue with your team in future, why you have chosen this.
Pistacy.io adds descriptions to quality attributes, briefly describing what each attribute provides. And when defining project constraints, we should provide a reason for the constraint as well. Today, you know why you're using Postgres, but will you know it in a year? Documenting the REASON is one of the most important things in software architecture.
Conclusion
Architectural drivers are the foundation of every good design decision. Without understanding and considering them, everything else is guesswork. If you want to design systems that are durable, scalable, and truly meet business needs, start with drivers.
Analyze the context, document decisions, and communicate with stakeholders. At Pistacy.io, you'll find tools that will help you practice not only thinking but also acting like a software architect.
Thanks for your attention, stay warm. May the architectural force be with you.
Top comments (0)