10.1 Scalability Requirement Pattern


10.1 Scalability Requirement Pattern

Basic Details

Related patterns:

None

Anticipated frequency:

Zero or one requirement; rarely more

Pattern classifications:

Affects database: Yes

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 as 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 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.

Template(s)

Open table as spreadsheet

Summary

Definition

«Scalability aspect» scalability

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)

Open table as spreadsheet

Summary

Definition

Customer scalability

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.

  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 downtime 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:

Open table as spreadsheet

Summary

Definition

Transaction data scalability

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.

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 that each user is responsible for only part of the data.

  2. Maintaining and administering Tasks that are straightforward at low volumes can become time-consuming, 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 be 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.

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.




Microsoft Press - Software Requirement Patterns
Software Requirement Patterns (Best Practices)
ISBN: 0735623988
EAN: 2147483647
Year: 2007
Pages: 110

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net