NFRs: Your Architectural North Star in Software Design
Welcome to the last part of our exploration of non functional requirements (NFRs) in software architecture! After exploring individual NFRs in depth, it's time to understand how they collectively guide architectural decision-making and why choosing primary and secondary NFRs is a very crucial step in your journey to build an ever evolving system.
So, what did we looked at so far ?
Scalability: How systems handle growth in users, data, and complexity. [Link]
Reliability: How systems consistently meet user expectations under various conditions. [Link]
Availability: Ensuring systems are operational and accessible when needed. [Link]
Maintainability: How easily systems can be modified, repaired, or enhanced over time. [Link]
Extensibility: How systems can accommodate new features or modifications without major rewrites. [Link]
Usability: How the system's architecture supports an intuitive and efficient user experience. [Link]
Security: How the system protects data, users, and itself from threats. [Link]
Performance: How the system delivers speed and efficiency. [Link]
Testability: Building Confidence Through Design. [Link]
Starting next week we will start looking into system coupling and interaction models, but let’s not get ahead of ourselves…
The Compass of Architecture Decision-Making
Imagine you're planning a journey across uncharted territory. While you have many tools at your disposal, your primary compass (your North Star) keeps you oriented towards your true destination. Similarly, in software architecture, while all NFRs matter, having a primary NFR and 1-2 supporting NFRs acts as your architectural compass, guiding all subsequent decisions.
Why You Need a Primary NFR
Every significant system has one dominant quality that defines its success. Think of Netflix - while they care about security, maintainability, and other qualities, their primary NFR is availability. They famously operate under the principle that "the service being unavailable is worse than the service being inconsistent."
This primary NFR becomes your decisive factor when facing architectural trade-offs. It's your "tie-breaker" in architectural decisions and helps align your team's efforts toward a common goal.
The Role of Secondary NFRs
Secondary NFRs complement your primary NFR, providing additional guidance when:
The primary NFR isn't significantly impacted by a decision
Multiple solutions equally satisfy the primary NFR
You need to balance competing concerns
For example, if your primary NFR is scalability, you might choose security and maintainability as secondary NFRs to ensure your scaling solutions remain secure and manageable.
How to Choose Your North Star NFRs
Consider these factors when selecting your primary and secondary NFRs:
Business Context 🎯
What's your core business proposition?
What would cause the most significant business impact if it failed?
What do your users value most?
System Characteristics 🏗️
What's the nature of your system (user-facing, backend, data-processing)?
What are your system's critical operations?
What are your non-negotiable requirements?
Industry Requirements 📋
What are the regulatory requirements?
What are the industry standards?
What do competitors prioritise?
Common Primary-Secondary NFR Combinations
Here are some typical combinations based on system types:
Financial Systems
Primary: Security
Secondary: Performance, Reliability
E-commerce Platforms
Primary: Availability
Secondary: Scalability, Performance
Healthcare Systems
Primary: Reliability
Secondary: Security, Maintainability
Social Media Platforms
Primary: Scalability
Secondary: Performance, Availability
Impact on Architectural Decisions
Let's see how having clear primary and secondary NFRs influences decisions:
Example: Message Processing System
Primary NFR: Scalability Secondary NFRs: Reliability, Maintainability
This combination would lead to decisions like:
Choosing event-driven architecture over monolithic
Implementing asynchronous processing
Using distributed databases
Implementing circuit breakers
Designing for horizontal scaling
Trade-off Analysis Example:
When choosing a database:
Option A: Traditional RDBMS
High consistency
Limited scalability
Easier maintenance
Option B: Distributed NoSQL
Eventually consistent
Highly scalable
More complex maintenance
With scalability as the primary NFR, Option B wins despite the maintenance trade-off, as it better serves the primary goal.
Architect's Alert 🚨
Remember: Your NFR priorities might evolve as your system matures. What starts as a system primarily focused on maintainability might need to shift to scalability as user adoption grows. Regular reassessment of your NFR priorities is crucial.
Practical Implementation Steps
Document Your NFR Hierarchy
Clearly state primary and secondary NFRs
Explain the rationale behind choices
Share with all stakeholders
Create Decision Templates
Include NFR impact analysis
Prioritise based on your NFR hierarchy
Document trade-offs
Establish Metrics
Define success criteria for each priority NFR
Set up monitoring and reporting
Regular review and adjustment
Conclusion
Treating NFRs as your architectural North Star provides clarity in decision-making and helps align your team towards common goals. While all NFRs matter, having clear priorities helps navigate the complex landscape of architectural choices.