Scalability Requirement Pattern
Basic Details
Pattern manifestation:
Standard
Belongs to domain:
Flexibility
Related patterns:
None
Anticipated frequency:
Zero or one requirement; rarely more
Pattern classifications:
Affects database: Yes
Pattern author:
S. Withall
Applicability
Use the scalability requirement pattern to specify a way in which a system must be able to expand without
undue pain, typically to accommodate growth in business volume.
Do not use the scalability requirement pattern to demand a particular level of performance; use one of the
performance requirement patterns for that.
Discussion
Scalability means never having to say you’re sorry that the system can’t cope with more. Scalability means being
prepared when the load on the system increases, having ways to react without resorting to drastic changes or
redevelopment. Scalability doesn’t happen by accident, and if you don’t ask for this ability, don’t be surprised if
you don’t get it. Scalability can be expensive, so if you want it, you’d better be prepared to pay for it. And if
don’t need it, don’t ask for it; when you’re building a system for a small environment and the chances of using it
elsewhere are low, think twice about whether it’s worth it.
A scalability requirement is an instruction to developers to design the system such that it can grow in a
particular direction, with no obstacles in its way. It is a signal that the system must not be restricted to any stated
business volume.
Scaling is often driven by an increase in a single factor only. In a commercial system, it’s usually the number of
customers (or, more generally, the number of users). Rarely are there are more factors whose growth
independently causes a proportionate increase in load on the system (and, consequently, a need for a separate
scalability requirement). For example, doubling the number of products a retail business offers for sale is
unlikely to double the load directly. A single scalability requirement usually suffices.
Scaling a system’s overall performance is of two main types. First is scaling out, the ability to spread the
processing load across more machines. Second is scaling up, by increasing the power of individual machines.
Generally, requirements should be concerned only that the system can scale, without caring how. But an ability
to scale out is sometimes worth demanding in requirements because it influences a system’s basic software
architecture and cannot be retrofitted, whereas scaling up typically doesn’t affect the software at all. A system
Scalability Requirement Pattern
17Feb16 V1.0
Confidential and copyright  2006-2008 Stephen Withall
Page 1
can accommodate a growing load only if the quantity and/or power of its hardware are increased accordingly, in
proportion. A system isn’t scalable if the hardware needed grows at a faster rate than the load; for instance, if
doubling the load demands four times the hardware, we’d soon be unable to keep up with increasing load.
Performance requirements implicitly apply regardless of the extent to which the system has been scaled, unless
otherwise stated in either the scalability or performance requirements. This is especially relevant to response time
and availability requirements (because we can expect overall throughput and capacity to grow as the system
grows): they must not become progressively worse as the system scales. In practice, performance measures are
likely to change marginally with the system’s load. This is acceptable if it’s barely perceptible to users.
Nevertheless, if you sense there’s a risk that the importance of maintaining performance levels could be
forgotten as the system grows, you could strengthen the relevant requirements to make it clear.
Consider flow-on scalability demands upon third parties—that is, all systems you interface to and all third-party
products you use. Investigate whether they are all suitably scalable; if they’re not, you’re in trouble. This applies
to products you are forced to use and any the project is at liberty to choose for itself. For the latter, impose our
scalability requirements on them too, when evaluating their suitability.
Content
A scalability requirement should contain the following:
1.
Type of item to be scalable: What aspect of the system needs to be scalable? For example, it could be the
number of customers.
2.
Indicative high business volume: Just how far might the system need to scale? Indicate only a rough
order of magnitude: tens, hundreds, thousands, millions, or whatever it might be. Expressing it in vague
terms is a positive advantage, because it prevents the development team building to accommodate a
specific number (as if it were a performance requirement)—with the risk of that number representing an
absolute limit.
No system can be scaled without limit, so don’t use words like “infinite”’ or “unlimited” to describe the
extent of scalability. What we’re saying is that we want the system to be capable of scaling as big as
we’re ever likely to need. I like the word “unrestricted”, because it conveys that we want nothing in the
way of expansion, without implying expanding for ever. At least, that’s what it conveys to me;
admittedly it’s a fine distinction. Pick a different word if you wish.
3.
Ease of expansion: How easy must it be to expand the system? How dynamically? In ideal
circumstances, an extra machine could be added while the system’s running. Is it worth it? If omitted, it
is reasonable to assume that scalability can be achieved by shutting down the system, adding extra
hardware, doing a bit of reconfiguration and starting it up again. If you want more than this—or if less
will suffice—then say so. (The upgradability aspects of the installability requirement pattern, which
appears later in this chapter, cover these issues, too.)
4.
Motivation: Why do we need this kind of scalability? The commonest motivation is to cater for growth
in business.
Scalability Requirement Pattern
17Feb16 V1.0
Confidential and copyright  2006-2008 Stephen Withall
Page 2
Template(s)
Summary
«Scalability aspect» scalability
Definition
The system shall be scalable to accommodate an unrestricted
number of «Type of item to be scalable»s. «Indicative high business
volume».
[«Ease of expansion statement».]
[«Motivation statement».]
Example(s)
Summary
Customer scalability
Definition
The system shall be scalable to accommodate unrestricted growth
in the number of customers (prospectively to several hundred
thousands).
The motivation for this requirement is to cater for future growth
in the business.
Distributed office scalability
The system shall be scalable to allow its use by an unrestricted
number of distributed offices of the company. (Eventually there
could be over one hundred offices.)
The motivation for this requirement is to allow the system to be
used across the whole company and all its subsidiaries (including
future acquisitions).
Document library scalability
The document management system shall be scalable to manage
an unrestricted number of electronic documents. (There could be
millions of such documents, with a total size of several terabytes.)
Extra Requirements
Making a system scalable can (and usually does) have significant implications that go beyond simply being able
to handle a bigger load. Consider the following topics, and write extra requirements as necessary:
1.
Characteristics that must not degrade as the system grows. In what ways must the system keep
performing just as well as it grows? This is covered in the “Characteristics That Must Not Degrade with
Growth” subsection coming up.
2.
Steps to take to contribute to scalability. Are there any specific features we want our system to have to
help it be scalable? Or so it’ll continue to be as easy to use as volumes grow? This topic is discussed in
the “Steps That Contribute to Scalability” subsection.
3.
Scaling the number of sites. If we achieve scalability by running the system in more and more sites, we
need to consider how to co-ordinate them. See the “Scaling the Number of Sites” subsection.
Scalability Requirement Pattern
17Feb16 V1.0
Confidential and copyright  2006-2008 Stephen Withall
Page 3
4.
Monitoring functions. We need functions to tell us how close to maximum load the system is, which
will help us plan expansion. See the information about measuring and monitoring in the performance
requirement patterns and in the introduction to the performance domain.
5.
Not wasting hardware. If you’re especially concerned to make the most of precious money spent on
hardware, insist on being able to keep old hardware in service whenever new hardware is purchased.
That is, you can write a requirement that it shall be possible to add hardware in order to expand the
system.
Characteristics That Must Not Degrade with Growth
It’s sometimes useful to specify that a particular characteristic of how the system behaves must not noticeably
degrade as the system scales—that is, as the factor identified in the main scalability requirement increases. For
example, regular down time for housekeeping must not increase in proportion to volume. Do this if you’re
worried that this area is at risk of being left behind—of performing badly as business volume grows. Explicitly
identifying things that shouldn’t degrade as the system scales spells out the implications of a scalability
requirement. These things can themselves then be examined to see if there are specific steps we can take to help
achieve them, as described in the “Steps That Contribute to Scalability” subsection that follows.
Here are a few examples of requirements for this purpose:
Summary
Transaction data scalability
Definition
The time taken to produce any report or inquiry showing
information about transactions shall depend predominantly upon
the quantity of data to show (and not the total quantity of data
stored).
This requirement does not apply to any report or inquiry that
allows the user to enter arbitrary selection criteria.
Non-growth in system
operation effort
The effort needed to administer the system (as measured in hours
per week of system administrators’ time) shall not grow as the
number of customers grows. That is, if there is any increase in
system operation work, it shall be proportionately less than the
increase in customers.
Availability unaffected by
growth
Any increase in the number of customers shall not degrade
system availability to an extent noticeable by any users.
No report size limits
There shall be no limit upon the size of a report. A report can be
as large as necessary to show all the data it is asked to show. It
shall be practical to manipulate very large reports.
This requirement has significant implications for the reporting
infrastructure. For a start, it implies that a large report should not
be stored as a monolithic blob.
Observe that the first three are hard to test. They’re intended mainly factors for developers to take into account.
Scalability Requirement Pattern
17Feb16 V1.0
Confidential and copyright  2006-2008 Stephen Withall
Page 4
Steps That Contribute to Scalability
When thinking about scalability, the emphasis is on performance factors: having enough sheer horsepower to
cope with an increasing load, being able to process more transactions, being able to store more data, and so on.
But that’s not the whole story. All the system’s functions must continue to be practical to use as the system
scales. Scan all the specified functions to see which ones might involve more work for users as the system grows.
Pay special attention to the following areas:
1.
Inquiries and reports. Specify functions such that an increase in the quantity of data in the system is not
accompanied by a similar increase in the amount a user must plough through. One way to do this is to
allow the work to be shared among several users, perhaps by segregating the data (so each user is
responsible for only part of the data).
2.
Maintaining and administering. Tasks that are straightforward at low volumes can become timeconsuming, tedious, increasingly liable to human error, and finally impractical as volumes grow.
Making such functions just as easy to use as the system scales up means they must be more
sophisticated, and consequently more expensive to develop (though that might be justified by reduced
operational costs).
Consider the impact of a large number of configuration entities, and of a large number of server
machines. One way to reduce the problem is to arrange for some information to be shared by multiple
configuration entities (so that one change affects them all) – that is, structuring data with the
maintenance implications of scalability in mind. A more sophisticated approach is for maintenance
functions to be able to apply a change to multiple entities at once.
3.
Installing and upgrading. How frequently is extra hardware likely to be added? How much advance
warning are we likely to get? Just how many machines might we end up with? The answers to these
questions might justify special steps to make it as easy as possible to install the system on a machine, to
upgrade the software on a machine, and to slot a new machine into the live environment. This topic
builds on what a scalability requirement says about “ease of expansion”. (See the installability
requirement pattern for more.)
Scaling the Number of Sites
A system that scales by being installed in more sites has an extra kind of complexity: how to co-ordinate those
sites, both technically and businesswise. A head office and a number of satellites is the most common situation
(and the simplest, except for the case of no co-ordination at all). Investigate the relationships between sites and
the extra functionality needed: functions used by head office only, data to be sent to head office, dissemination
of data to satellites (for example configuration information that embodies aspects of business rules or corporate
policy), and possibly numerous other things.
Then, what kinds of corporate restructuring might happen (such as merging two satellites)? Does the system
need to be ready for such eventualities? If no provision at all is made, achieving them later might be very
difficult indeed—if, for example, different sites allocate the same customer number to different customers.
Complexity of this kind could go unnoticed if you concentrate on an initial implementation in a single site, so
ask yourself whether you need to worry about it. It is important, is bound to have a major impact on how the
system is implemented, and must be properly specified.
Scalability Requirement Pattern
17Feb16 V1.0
Confidential and copyright  2006-2008 Stephen Withall
Page 5
Considerations for Development
Scalability can be achieved by choosing underlying technology built to help spread processing load across
multiple machines, or it can be achieved by our own software, or by a mixture of both. Distributing loads across
machines is a lot more complicated to implement than it at first appears, so use a third-party product to do the
hard work for you whenever possible.
Consider whether the scalability being asked for can be achieved by a single database. If not, work through the
implications of having multiple databases. How closely do they need to work together? What would need to be
done to co-ordinate them? Can the overall system be divided into a number of islands that work largely
independently of one another?
Take special care with the design of database tables that are directly or indirectly affected by the kind of
scalability being demanded and with the design of functions that maintain this data. Avoid duplicating data for
which many entities could share the same values, to save having to modify a value many times (a number of
times that increases as the system scales up).
Considerations for Testing
Scalability is difficult to test at all. One exercise is to get the system running and verify that adding extra
resources is as easy as it should be. Then test that the new configuration can cope with a proportionately
increased load. Measure the actual performance gain as the resources scale. If you get that far, you’ve done well.
But it doesn’t prove that you can keep on adding hardware with the same effect. It’s unrealistic to test that the
system possesses “unrestricted” scalability.
You can probably get a subjective feel for how scalable the system is by talking to the developers about it. What
steps have they taken? How did they approach the subject? Are there any design documents that deal with
scalability? Have they discovered any potential problems? The depth to which they can answer these questions
should give you an insight into how much faith you can place in the scalability of their work.
Scalability is an infinite area. You must determine when you have done enough and are satisfied with the
results. Performance requirements can give you a feel for what is a reasonable point at which to stop.
Scalability Requirement Pattern
17Feb16 V1.0
Confidential and copyright  2006-2008 Stephen Withall
Page 6