Completely random stream of thoughts about the software business, from the perspective of an executive.

Monday, November 16, 2009

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:

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?

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:

Who are your users and what are they trying to accomplish? From here, identify the most critical operations that are performed frequently.

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.

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 upSaving 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."

2 comments:

Good article, but how development team will know what items need to be improved? What is most usable functionality and etc... I would like to rise another issue what usually happens for most of the system. 99 % of the performance and scalability issues reported by end users. It means that development do not know how system works in details, where gaps, where bottlenecks … The budget/resource limitations does not allow development team to create monitoring system which will track user activities and analyze user flow for any improvements, frequency of usage and etc. Having such information will help development team see trend what is critical operation based on real information from all customers. Estimates how much customers will be impacted by new feature, identify mass user activities what need to be considered for improvements.

Volodymyr raises excellent points. There is no guarantee that any method will produce a perfectly scalable solution the first, second, or even Nth time.

One must start with developing a culture that causes all people involved in development - designers, developers, QA, support, etc. to constantly look for and challenge each other to consider the user context.

For each application, there must be a collection of key elements considered for each feature. For example, number of customers, sizes of catalog items to search, or numbers of medications to review.

Its up to the leadership to ensure the questions are asked; its up to the team to know the right questions.