Performance is not just your solution’s ability to respond in a timely manner, but its ability to change in response to varying levels of demand.
Cloud solutions provide the ability to scale out and up dynamically, but this of course comes at a cost. If demand is directly related to generating revenue, then we may want our application to scale without any bounds.
Conversely, if your solution is a business support function, or if usage patterns are well known, we may want to constrain resources.
For example, a subscription-based tool that end users must sign up to could scale indefinitely because as more users sign up, more resources are required to support the growing userbase. Conversely, a payroll system will have a known demand, and we might instead scale down at weekends and evenings or scale up at the end of the month.
We should therefore ask questions such as the following:
- What are the solution’s usage patterns?
- What are the boundaries within which we must perform?
If a solution does not scale in line with demand, it will perform much slower, however, in extreme cases, it could even cause failure. We must therefore also understand reliability requirements.
Understanding reliability requirements
Reliability is your solution’s ability to withstand outages, and from a business perspective, we need to know what impact downtime has.
An internal application that does not perform a critical or time-sensitive function can withstand being offline longer in the event of an issue. However, an external revenue-generating application will result in the loss of income if it is unavailable and therefore will most likely need to be more resilient.
Increasing resilience often means increasing costs, especially if you need to duplicate components in other regions to protect against regional loss. The increased costs need to be weighed against the potential loss of revenue. For example, you may decide that a small loss of income is less than the cost of a potential outage, at least up to a point.
Finally, the solution may offer external customers Service-Level Agreements (SLAs), with penalties to be paid should they be breached. Internal systems may offer operational-level agreements.
As we can see, it is not a simple question of does your application need to be resilient? We also need to understand the levels of durability that are required.
These are some example questions we could ask:
- Do you have to adhere to any SLAs or Operational-Level Agreements (OLAs)? If so, what are they?
- What would be the financial cost of an outage?
Once we understand how resistant to an outage our solution must be, the final area to consider is security.
Understanding security requirements
Security generally impacts all levels of your solution, and we often need to include specialist security teams in our conversations to understand organizational-wide security requirements.
Business owners may also have their own views on security, especially if the solution is for another customer with specific security demands of their own.
Organizational requirements will usually be defined as a set of principles and policies, such as requiring all data to be encrypted, or for traffic to be internal only.
When building solutions for other parties, we may also need to consider additional levels such as who has access to data and how it can be transferred between systems.
Finally, many countries have their own restrictions and compliance rules around handling data, protecting it, and how long it can be kept.
Some example questions we may need to ask the business are as follows:
- Are there any specific data-handling requirements?
- Are there any rules around data retention periods?
- Are there any data residency requirements (such as, which countries data can reside or be processed in)?
The example questions are just a few examples, and although we align them with specific areas, in fact, many might span multiple concerns.
Over time you should build a standard set of questions that can then be added to or tweaked as each project demands. Once we have our business requirements, we can then start to map them to technical options.
Leave a Reply