Quality attributes define the characteristics of the system. These might be run-time characteristics that are visible to the end user or development-time characteristics visible to the developer.
|Security||1||Companies won't adopt a system they do not trust|
|Availability||2||Companies won't adopt a system that isn't there|
|Reliability||3||Companies won't adopt a system they cannot depend on|
|Correctness||4||Users will avoid a system that produces results they cannot trust|
|Usability||5||Users will gravitate towards a system that is intuitive|
|Elasticity||6||We need to continuously match cost and performance to demand|
|Operability||7||We need a system that is easy to monitor and service to meet reliability goals at reasonable cost|
|Updatability||8||We need to continuously evolve the system, but not if it breaks any of the above|
|Deployability||9||We need to be able to deploy new instances and users ; however, this happens less frequently than servicing existing instances and users|
Data security is the number one concern of the customer. To achieve this quality, we look at security in depth. With an open system, deployed in the cloud we have adopted the notion that:
- The perimeter of the system is defined by identity and encryption
- Privileged access should be avoided at all times
- Data assets should be owned by the user rather than the service accounts.
- Secure down to the resource level
The results from the data ecosystem should be consistent and explainable.
We need to ensure that the system is perceived as desirable to work with by a large number of casual users. This means that engagement with the system should appear natural and interactive.
The system should automatically scale up to meet demand and scale back to remain cost effective.
We have a large user base located around the world. Onboarding these users requires the ability to effectively deploy new instances and organizations.
We have adopted a process focused on continuous deployment for services that are highly available. This requires that a running system be updatable while running, either to introduce new features and fixes or to roll-back defective updates.
To satisfy our goal of schema and quality on consumption from original data, we need the ability to add and compose new enrichment services.
We need to be able to scale our operational support cost as a function of the number of systems rather than the number of users or amount of data that we serve.
We have adopted the principles of Site Reliability Engineering where reliability is a function of what the user observes rather than how the underlying systems are performing. Thus, we focus our metrics on user journey's and underlying developments of resiliency over robustness.
This is the most visible Reliability goal. If the system is not available, it has no value to the users. We would rather run in a restricted mode than be unavailable.
Agile architecture enables incremental value delivery by balancing between emergent design and intentional architecture:
Emergent design – Provides the technical basis for a fully evolutionary and incremental implementation approach. This helps designers respond to immediate user needs, allowing the design to emerge as the system is built and deployed.
Intentional architecture – This is a set of purposeful, planned architectural initiatives, which enhance solution design, performance, and usability and provide guidance for inter-team design and implementation synchronization."
Read more at: Scaled Agile, Inc.
A key design goal of the data ecosystem is to support new:
- Data and Format coverage requiring frequent additions to ingestion and storage capabilities
- Enrichment techniques, requiring frequent additions of services that act on data
- Workflows, requiring frequent additions to consumption models.
A highly flexible system is often a challenge for developers. To offset this, we:
- invest in good developer documentation
- encourage the introduction of type-safe convenience APIs where they are proven to increase usability, consistency and performance despite the inherent fragility that such APIs introduce.
We have a highly distributed organization continuously developing and deploying services to a system intended to be reliability. This means that any coupling among services should be necessary to achieve business goals, and testable to avoid the introduction of breaking changes.
Quality Attributes often compete with each other, The chart below describes tradeoffs against common system qualities. There are two techniques for dealing with these tradeoffs
- Rank them in priority, and sacrifice the less important to achieve the most.
- Allocate conflicting quality attributes to different parts of the system rather than trying to impliment them uniformly in every service.