Building Process Scalability into Software

We often associate scalability with system response time. There is another aspect of scalability that is often ignored until too late. Ironically, it is perhaps one of the easiest aspects of scalability to address before any code is written. I'm referring to scalability of the software to support large, complex processes that touch many people.

Here are two examples:

• Adding large numbers of something to your system at one time. For example, users, payments, or products.
• Making administrative changes across many items. For example, changing permissions for many users, adjusting process to many items, or applying payments to many customer accounts.

I've noticed most software appears to be designed for entry of one new user, changing one product, and so on. This works well most of the time. However, two things usually happen:

1. A customer grows so large that updates happen frequently enough to start impacting productivity. For example, posting a customer payment by hand may be reasonable if you get a few payments a day. What happens for a multiple location business with centralized billing and dozens or even hundreds of payments?
2. Periodic bulk changes consume very large amounts of time and effort for a short period of time. New laws and across the board price adjustments are examples of things that may occur only once or twice a year, but have to be done for many, many items in a very short period of time.

Scalability in this context means scalability of process. It may be fine that it takes 30 seconds to increase the price of one product by 5%. But what if I need to increase the price for 10,000 products? You are going to have to provide me an efficient way to do this.

Unlike hunting down slow performing algorithms, you have to apply user experience principles. Identify operations your users perform to large numbers of items. There are three questions that arise from this:

1. Who are your users and what are they trying to accomplish? From here, identify the most critical operations that are performed frequently.
2. What does “perform frequently” mean to them (not you). Something that is performed once daily, but takes 30 minutes may be frequent to your user. This is especially true if it is something that they will likely do more frequently if their business grows.
3. How big is "large numbers"? For some things, 3-5 times may be a large number if each time it take 2-3 minutes. In other cases, it may be hundreds of times, even if each time takes a few seconds.
   

Seconds add up
Saving one person 2 hours per task, when it is performed 10 times per week, is easy to understand. Be careful to not overlook an opportunity to save 30 seconds of a 2 minute operation when 10,000 people perform it 2 times a week. I've used somewhat extreme examples to make a point - not to set a standard. The core point is that saving time from seemingly small operations for many users can provide a very real net benefit to your customer over time. Don't overlook those opportunities, even if the savings seems small initially.

These lessons can be applied very early in the development cycle - well before any code has been written. The observations made through interacting with the users allow you to focus energy on making your customers efficient with your software, even if that means slightly fewer features.

Keep in mind - you are likely to be better off with fewer usable features than a lot of features that are inefficient. And let's not fool ourselves - once a feature is released we seldom go back and improve it proactively. Take the time to build in support for scalable processes along with all the other "ilities."