When thinking all the aspects that might define “what quality means”, there is several so called “ilities”. If quality is something that matters to someone who matters then it is more than likely your project has several “bilities” even if you are not yet aware of them. Maybe your delivery team has goals to improve many aspects of a new product you’re developing. Some of these might be maintainability, observability, testability and deployability. These are all so called -bilities. It includes also other things such as security and accessibility. But we’re not looking into those here.

Instead, let’s see what we could do before single line has been written yet and you’re looking at your new architecture plans!

Generative AI tools were used to extract bullet points for the different abilities. Content has been “spiced” up by me using my experience across various software projects

Maintainability: The Future-Proof Lens

How easily the system we’re desiginging can evolve, repair, or improve without breaking existing functionality?

Following might apply to your design, maybe not.

Key Principles:

• Coupling & Cohesion: Identify God Components (components with too many responsibilities) or tangled dependencies. This is bit like the infamous God Class.
• Abstraction Layers: Verify implementation details are hidden (can you swap databases without rewriting business logic?). This might be familiar to you from “good tests”, be they unit, integration or end to end tests. Can you switch frameworks, tools “easily”.
• Standardization: Consistent patterns for error handling, logging, data access, and configuration
• Configuration Management: How settings and secrets flow across environments.
• Backward Compatibility: Check mechanisms to prevent breaking changes, not just handle them
• Technical Debt Visibility: Confirm architecture exposes complexity metrics

Remember, there is such thing as “too much of a good thing”. Sometimes for example abstractions can become too abstract. One aspect of maintainability is “how easy it is for a new person to jump in”.

Observability: The Internal Health Lens

Can we quickly observe and track things as they move across the architecture. And especially if something goes wrong.

Key Principles:

• Traceability: In distributed systems, can you track single requests across all services?
• Measurement Consistency: Specify what’s measured (business metrics vs. infrastructure) and ensure uniform collection methods. This can be tricky in large organisations and multiple teams.
• Context Enrichment: Include Correlation IDs and metadata for meaningful logs and metrics
• Alerting Strategy: Define when and how teams receive notifications
• Debugging Workflows: Map the path from alert to resolution
• Security & Audit: Track security events and compliance trails
• Cost Visibility: Monitor observability infrastructure overhead

If you’re only one team dealing with the architecture under design, things can be much easier than in large organisation. As sometimes you need to do with what tooling is available for you. Just because you want to track something across distributed systems, is it even feasable? Do you get enough “bang for buck” if you implement partial traceability?

Testability: The Verification Lens

Testability measures how easily you can verify system and test the system. I am using here both words verify, associated with automated testing, and test system for what could be described as exploratory testing.

Key Principles:

• Isolation: Test components independently without full infrastructure
• Determinism: Minimize side effects causing flaky tests (hidden global states)
• Controllability: Inject failures and bad data to validate resilience
• Contract Validation: Verify service agreements in distributed systems
• Performance Testing: Support load and stress testing scenarios
• Privacy-Safe Data: Generate test data respecting compliance requirements
• Deployment Testing: Validate the deployment process itself

Once again, your situation is different. What if you cannot control test data? Is there any ways you can create mocks, containers or similar to control things that are outside your control? This can be affect greatly the speed at which your team moves if you’re waiting days for test data availability for single round of automated or especially exploratory testing. Isolation becomes very important factor. But then you really need to understand also how the systems you’re interfacing with can fail, behave. So you need to take this into account when your team is defining your test strategy.

Deployability: The Production Release Lens

Deployability measures how safely and efficiently code reaches production.

Key Principles:

• Deployment Independence: Deploy components without coordinated releases
• Rollback Mechanisms: Quick reversion when issues arise
• Progressive Delivery: Support blue/green, canary, and feature flag patterns
• Environment Parity: Minimize differences between dev, staging, and production
• Automation: Reduce manual steps and human error

This can be important goal for your team especially in monolith to microservice migration projects. What guidelines your team needs to follow from the organisation? How much you can decouple and when you can start moving faster? Is the architecture plan mix and match of monolith and microservice architecture? What service and server architecture you have available for example to reach environment parity?

The Checklist Questions for Each bility

When your team is working on the plans, here is some questions that can be relevant. Remember, we’re dealing here with the architecture planning phase. And no, doesn’t mean we are dealing with waterfall SDLC.

I recognize that architecture also emerges as you go. And some of these questions are not relevant for you in early architecture planning. But they will become important as your solution starts maturing. So it is good thing to be aware of them now and get back to them when time is more mature.

Maintainability Questions

The Replaceability Test: If replacing the primary database or third-party API, how many components require modification? This is sort of thing to consider, if we’re already replacing some APIs, what happens if say the payment gateway API changes again as they often can.

The New Hire Test: Can new developers understand a module’s purpose without reading system-wide documentation? This is one of my favorite “flags” for maintainability. If we assume you’re say starting from the infamous “big ball of mud”, you want the end up with much streamlined, easier to understand landscape.

Dependency Mapping: Are there circular dependencies between services that we’re drafting?

Version Strategy: How does the architecture handle API breaking changes? Is versioning built-in? When you’re moving into microservices out from monoliths, expect APIs to start changing more often too as the organisation gaines more momentum for changes thanks to the microservices.

The Configuration Chaos Test: Can you trace how a single setting propagates from source to runtime? Are secrets managed securely? This could go as well in observability section.

The Abandoned Code Test: How are we identifying unused services or features for removal? How we find out if someone else is still using it?

Documentation Auto-Generation: Does the architecture support generating docs from code (OpenAPI specs, dependency graphs)?

Observability Questions

The Needle in a Haystack Test: When users report errors, what unique ID finds the exact log entry across all services? What hidden assumptions we might have of the observability tools we have?

The New Hire Test (Observability): Can someone new understand telemetry without tribal knowledge?

Health Definitions: Does the architecture define Healthy vs. Degraded vs. Down states for each component? Can it? Which parts of the architecture can report different states, and what does it mean from the point of view of cascading problems?

Measurement Standards: Is there consistent format for logs (JSON with standard fields) and metrics (naming conventions, labels) across the entire system? What can we do in our team to start implementing these good practises?

The 2 AM Test: If this breaks at 2 AM, what does the on-call engineer see first? Is it actionable?

The Regulatory Audit Test: Can you prove what happened six months ago? Are audit logs tamper-proof?

Cost Attribution: Can you track observability costs per service or team? What are the cost implications of our teams observability riggings?

Testability Questions

Mock-ability: Are external dependencies (APIs, databases, file systems) hidden behind interfaces for easy mocking?

State Management: How do you reset the system to a clean state for automated checks and verifications?

Failure Injection: What do we need to do with our plans to allow us to create intentional failures? Time outs, cut connections. Wrong API versions.

Data Seeding: Is there a clear path for generating and injecting test data?

Contract Testing: How do you verify service contracts (API schemas, message formats) between teams?

Performance Baselines: Can you run load tests that mirror production traffic patterns? Which parts of your architecture you can exercise that are under your control? How you isolate 3rd parties or agree on test windows?

Privacy Compliance: Does test data generation anonymize or synthesize sensitive information?

Environment Cloning: Can you replicate production-like conditions in test environments?

Deployability Questions

The Solo Deploy Test: Can you deploy one service without coordinating with other teams?

Rollback Speed: How quickly can you revert to the previous version? Is it automated?

Progressive Delivery: Does the architecture support canary releases (deploying to 5% of users first)?

Feature Flags: Can you toggle functionality without deploying code?

Environment Promotion: How do artifacts move from dev to staging to production? Are they identical?

The Zero-Downtime Test: Can you deploy during business hours without user impact?

Deployment Observability: Do deployments generate telemetry showing their progress and impact?

Disaster Recovery: Can you test failover procedures without causing downtime?

In Conclusion

You notice how much these related to testing. Testing failovers, testing in production with progressive delivery and flags for example. No wonder maintainability, observability, deployability are classified as software quality attributes. Or maybe that is because of my own bias as a quality advocate, tester and QA.

So there you have it, a lot could be also written say on asking as a team cross cutting questions on these bilities that highlight where they intersect. Such as intersection of maintainability and observability. Or maybe “red flags” for your architecture design phases. And this doesn’t cover other bilities such as resilience.

Talking explicitly about these kind of abilities in architecture drafting phase is one of those things that can shift quality left. And if you’re a QA, bring these up with your product owner, product manger, project manager. Work with them on the business goals of your project, and find out what goals might be hidden in the technical side and expectations that do not reflect directly to end user say in form of a product feature (“add product to cart”, “publish a blog post”.).