These are properties of engineering systems.
- Quality
- Reliability
- Safety
- Flexibility
- Robustness
- Durability
- Scalability
- Adaptability
- Usability
- Observability
- Interoperability
- Sustainability
- Maintainability
- Testability
- Modularity
- Resiliency
In software engineering, following are most used “-ilities”.
1. Usability
Software usability can be described as how effectively end users can use, learn, or control the system. Some questions to ask yourself to determine usability might be:
Is there a UI metaphor that I am using to help users adapt? (for example, the ‘desktop’ is a metaphor)
Are the most common operations streamlined to be performed quickly?
Can new users quickly adapt to the software without help? (is it intuitive?)
Do validation and error messages make sense?
2. Maintainability ( or Flexibility / Testibility)
The definition of maintainability [for me] implies how brittle the code is to change. As a result, I tie the terms flexibility and testability into the overall maintainability of a project.
Does the entire team understand the code base or does knowledge islands exist?
Is the code throughly regression tested?
Can modifications to the project be done in a timely manner?
3. Scalability
Scalability is the ability for your program to gracefully meet the demand of stress caused by increased usage. In short, ensuring your program doesn’t slow or bust when pounded by more users than you originally anticipated.
What is your current peak load that you can handle?
How many database records can create until critical operations slow down?
Is the primary scaling strategy to “scale up” or to “scale out” — that is, to upgrade the nodes in a fixed topology, or to add nodes?
4. Availability (or Reliability)
How long the system is up and running and the Mean Time Between Failure (MTBF) is known as the availability of a program.
How long does the system need to run without failure?
What is the acceptable length of time for the system to be down?
Can down times be scheduled?
5. Extensibility
Are there points in the system where changes can be made with (or without) program changes?
Can the database schema flex to accommodate change?
Does the system allow Inversion of Control (IoC)?
Can end users extend the system (scripts, user defined fields, etc)?
Can 3rd party developers leverage your system?
6. Security
I shouldn’t need to go into this one but to be thorough I like this definition of security: the measure of system’s ability to resist unauthorized attempts at usage or behavior modification, while still providing service to legitimate users.
Does the system need user or role based security?
Does code access security need to occur?
What operations need to be secured?
How will users be administered?
7. Portability
Portability is the ability for your application to run on numerous platforms. This is can include actual application hosting, viewing, or data portability.
Can the data be migrated to other systems?
For web applications, which browsers does your web app support?
Which operating systems does your program run on?
Obviously, this is not an exhaustive list. There are many many more (Backwards compatibility, Interoperability, and Reusability to name a few)
Software Quality Attributes — Enterprise Architecture Reference
The following summary covers 17 software quality attributes through the lens of Enterprise Architecture and solution design. Definitions are aligned primarily with ISO/IEC 25010:2023, which defines a product quality model composed of main characteristics — including Functional Suitability, Performance Efficiency, Compatibility, Usability, Reliability, Security, Maintainability, and Portability — each decomposed into sub-characteristics. Where an attribute is not an explicit ISO/IEC 25010 characteristic, it is described using accepted EA terminology, and its relationship to the standard is noted.
Quality (Overarching Concept)
Definition: The composite measure of a software system’s fitness for purpose across all functional and non-functional dimensions. In systems and software engineering, quality attributes are realized non-functional requirements used to evaluate the performance of a system, sometimes referred to as “architecture characteristics” or “-ilities”. Software architects are responsible for matching these attributes with business and user requirements.
Example: An enterprise CRM platform that consistently meets acceptance criteria across reliability, usability, security, and performance is judged high-quality because it satisfies stakeholder expectations holistically.
Reliability (ISO/IEC 25010 — Main Characteristic)
Definition: The degree to which a system, product, or component performs specified functions under specified conditions for a specified period of time. ISO/IEC 25010 decomposes Reliability into sub-characteristics including Availability, Fault Tolerance, and Recoverability. In reliability engineering, it is formally defined as the probability that a product, system, or service will perform its intended function adequately for a specified period of time.
Example: A cloud-based payroll service engineered for fault tolerance and recoverability delivers consistent uptime, ensuring payroll runs on schedule despite individual component failures.
Safety (Recognized in RAMS; ISO/IEC 25010:2023 evolution)
Definition: The degree to which a system operates without causing unacceptable risk of harm. A widely referenced formal definition is “freedom from unacceptable risk” (ISO/IEC 2014). In safety-critical systems, the acronym RAMS (Reliability, Availability, Maintainability, and Safety) is frequently used to address these concerns together. Safety is also closely related to Dependability, which is an aggregate of availability, reliability, safety, integrity, and maintainability.
Example: An industrial IoT control system with built-in fail-safes that automatically shut down equipment when sensors report dangerous operating conditions prevents physical harm to operators.
EA tradeoff note: Increasing safety mechanisms (redundant checks, fail-safes) typically adds latency and development cost, creating tension with performance efficiency and time-to-market.
Flexibility (Not an explicit ISO/IEC 25010 characteristic)
Definition: The ability of a system to respond to potential internal or external changes affecting its value delivery, in a timely and cost-effective manner. Uncertainty is a key element: flexibility becomes valuable precisely because uncertainty creates both risks and opportunities.
Example: A configurable enterprise order-management platform that allows business analysts to adjust pricing rules and promotion logic without code changes responds swiftly to shifting market strategies.
Robustness (Not an explicit ISO/IEC 25010 characteristic)
Definition: The degree to which a system functions correctly and maintains stability under stress, invalid inputs, or abnormal conditions — degrading gracefully rather than failing catastrophically. A useful distinction: robust systems are designed to resist change and maintain stability through strength, whereas resilient systems focus on recovery after disruption.
Example: A banking API that continues processing valid transactions when it receives malformed requests — logging errors without crashing — demonstrates robust boundary handling.
Contrast with Resilience: Robustness prevents degradation under adverse conditions; resilience restores service after degradation has occurred.
Durability (Not a standalone ISO/IEC 25010 characteristic; core ACID property)
Definition: In database systems, durability is the ACID property that guarantees that the effects of committed transactions will survive permanently, even in cases of failures, including incidents and catastrophic events. More broadly in EA practice, durability refers to a system’s ability to remain operational and preserve data integrity over prolonged use without degradation.
Example: A flight-booking system where, once a seat is successfully reserved, the booking persists even if the system crashes immediately afterward — this illustrates durable transaction handling. Mechanisms include write-ahead logging (WAL) to non-volatile storage and replication strategies that provide logical stable memory.
Scalability (Not an explicit ISO/IEC 25010 characteristic)
Definition: The property of a system to handle a growing amount of work, which for software systems may be achieved by adding resources to the system. Scalability can be measured across multiple dimensions, including Administrative (more organizations/users), Functional (adding features without disruption), Geographic (expansion to larger regions), Load (heavier/lighter traffic), and Generation(adopting new component generations).
Two primary scaling strategies exist:
- Horizontal (scale out): Adding or removing nodes, e.g., scaling from one web server to three.
- Vertical (scale up): Adding resources (CPUs, memory, storage) to a single node.
Example: A web application that seamlessly scales from hundreds to hundreds of thousands of concurrent users by dynamically adding cloud instances illustrates horizontal scalability.
EA tradeoff note: Horizontal scaling avoids single-node limits but introduces distributed-systems complexity (synchronization, latency, data consistency). As a guiding principle, “a system is scalable in the range where marginal cost of additional workload is nearly constant”.
Adaptability (ISO/IEC 25010 — Sub-characteristic under Portability)
Definition: Within ISO/IEC 25010, Adaptability is a sub-characteristic of Portability, describing the ability of software to be transferred and function effectively in different environments. An important nuance from software engineering: adaptability refers to users substantially customising the system through tailoring activities, while adaptivity refers to a system that adapts automatically to changing conditions.
Example: A containerized microservice deployable across AWS, Azure, or on-premises Kubernetes clusters with minimal configuration changes — fitting diverse IT environments without rearchitecting.
Extensibility (Not an explicit ISO/IEC 25010 characteristic; related to Agility)
Definition: The ability of a system’s architecture to accommodate new features or capabilities through planned extension points (plug-ins, modules, APIs), with minimal change to existing components. In the systems-quality taxonomy, extensibility is one of seven attributes constituting Agility alongside debuggability, portability, scalability, securability, testability, and understandability.
Example: A corporate analytics platform that supports adding new data connectors via a plug-in framework, enriching its data-source ecosystem without altering core processing logic.
Usability (ISO/IEC 25010 — Main Characteristic)
Definition: The degree to which a software product can be used by specified users to achieve specified goals with effectiveness, efficiency, and satisfaction. ISO/IEC 25010 decomposes Usability into sub-characteristics: Appropriateness Recognizability, Learnability, Operability, User Error Protection, User Interface Aesthetics, and Accessibility.
Example: An internal employee self-service portal with clear navigation and contextual help that new hires can use without formal training — reducing support tickets and improving task-completion speed.
Observability (Not an explicit ISO/IEC 25010 characteristic; operational practice)
Definition: A measure of how well internal states of a system can be inferred from knowledge of its external outputs. The concept originated in control theory (introduced by Rudolf E. Kálmán for linear dynamic systems) and has been adopted in modern cloud-native and DevOps practice through the “three pillars” of logs, metrics, and distributed traces.
Example: A microservices platform instrumented with structured logging, distributed tracing, and real-time dashboards — enabling SRE teams to diagnose latency spikes or error cascades within minutes rather than hours.
EA tradeoff note: Comprehensive observability instrumentation increases telemetry data volume and storage costs; architects must balance depth of insight against operational overhead.
Interoperability (ISO/IEC 25010 — Sub-characteristic under Compatibility)
Definition: The ability of a system to work seamlessly with other systems or components, exchanging data and services via agreed interfaces, formats, or protocols. ISO/IEC 25010 places Interoperability alongside Coexistence as sub-characteristics of Compatibility — the ability to operate with other products or systems without negative impact.
Example: An enterprise data warehouse that integrates with ERP, CRM, and supply-chain systems via standardized APIs and open data formats, enabling frictionless data exchange across the organization’s software ecosystem.
Sustainability (Not an explicit ISO/IEC 25010 characteristic; emerging EA concern)
Definition: The degree to which a software system can be maintained and evolved over the long term with acceptable cost, effort, and resource consumption — encompassing both technical sustainability (low technical debt, clean architecture) and environmental sustainability (energy-efficient computation, minimal resource waste). Academic research frames sustainability as a distinct property of software quality, addressing the environmental dimension of software performance.
Example: A corporate application built with clean-code practices, modular design, and energy-efficient deployment patterns that remains economical to operate, update, and extend on evolving infrastructure over a multi-year lifecycle.
Maintainability (ISO/IEC 25010 — Main Characteristic)
Definition: The ease with which a software product can be modified to correct defects, improve performance, or adapt to a changed environment. ISO/IEC 25010 decomposes Maintainability into Modularity, Reusability, Analyzability, Modifiability, and Testability. High maintainability is especially critical for long-term enterprise systems and DevOps success.
Example: A well-documented enterprise billing system with clear separation of concerns, where developers can implement regulatory changes or fix defects rapidly without triggering unintended side effects in adjacent modules.
Testability (ISO/IEC 25010 — Sub-characteristic under Maintainability)
Definition: The degree to which test criteria can be established for a system and tests performed to determine whether those criteria have been met. As a sub-characteristic of Maintainability in ISO/IEC 25010, testability directly enables confidence in releases and supports continuous delivery pipelines.
Example: A service-oriented application designed with dependency injection and clearly separated logic layers that enables fully automated unit and integration test suites — QA teams can verify each release with high confidence and minimal manual effort.
Modularity (ISO/IEC 25010 — Sub-characteristic under Maintainability)
Definition: The degree to which a system is composed of discrete, well-encapsulated components with defined interfaces, so that a change to one component has minimal impact on others. ISO/IEC 25010 lists Modularity as the first sub-characteristic of Maintainability.
Example: An ERP system composed of independent, bounded modules (HR, Finance, Inventory) with clearly defined integration APIs — allowing a team to update the Inventory module without affecting HR or Finance.
Resilience (Not an explicit ISO/IEC 25010 characteristic; related to Reliability)
Definition: The capacity of a system to withstand disruption and recover quickly, ensuring continuity of critical service. The key distinction from robustness: “Software is resilient if it can go back to normal after a disruption,” whereas robustness describes the ability to withstand high load before going down. Resilience is closely related to the ISO/IEC 25010 Reliability sub-characteristics of Fault Tolerance and Recoverability.
Example: A distributed e-commerce platform that automatically reroutes traffic to backup availability zones and preserves critical checkout operations even when a primary data center goes offline — restoring full service within seconds.
Quick-Reference: ISO/IEC 25010 Alignment Map
| Attribute | ISO/IEC 25010:2023 Status |
|---|---|
| Reliability | Main characteristic (Availability, Fault Tolerance, Recoverability) |
| Usability | Main characteristic (Learnability, Operability, Accessibility, …) |
| Maintainability | Main characteristic (Modularity, Reusability, Analyzability, Modifiability, Testability) |
| Interoperability | Sub-characteristic of Compatibility |
| Adaptability | Sub-characteristic of Portability |
| Testability | Sub-characteristic of Maintainability |
| Modularity | Sub-characteristic of Maintainability |
| Safety | Addressed via RAMS practice; related to Dependability aggregate |
| Scalability | addressed as architectural concern |
| Flexibility | addressed as architectural concern |
| Robustness | related to Fault Tolerance under Reliability |
| Durability | core ACID property for data systems |
| Extensibility | part of Agility aggregate |
| Observability | This is one of the key qualities of a software systems or Systems engineering |
| Sustainability | Measure of usage of power and where the power is drawn |
| Resilience | Works with Recoverability and Fault Tolerance |
Architectural note: These attributes are interdependent and often involve tradeoffs. For example, maximizing safety may reduce performance efficiency; achieving high scalability may complicate maintainability; and deep observability increases operational costs. In TOGAF-based EA practice, architects should map these quality attributes to business requirements and negotiate acceptable tradeoff positions with stakeholders, recognizing that synchronous communication between architectural components entangles them and forces shared architectural characteristics. [en.wikipedia.org]