The Sum of a System's PARTs

Today, regardless of who we are or what we do, our lives are dependent on information technology. Everyday functions as mundane as setting up a meeting, sending e-mail or even ordering a cheeseburger are now driven by complex information systems that are difficult to design and not guaranteed to perform well.

When it comes to designing a system as part of a technical solution, functionality, rather than performance, usually is given top priority. System performance is typically examined at the end of a project — if there’s time. Granted, functionality is essential, but performance should be carefully factored in and made part of a system’s design from the outset in order to prevent implementation problems down the road.
 
We create information systems to solve a variety of problems, so the types of systems available vary widely. They might be built to exist on a single computer, or they may span multiple services, applications, computers and networks. Regardless of the problem you’re trying to solve, the basic steps of designing any system for optimal performance depend on four things:

• Purpose
• Audience
• Resources
• Time

These variables should always factor into an initial system design, but it’s easy to lose sight of them over the course of a development project. Each of these PARTs, however, must be scrutinized carefully in order to guarantee system performance.

Purpose: What Problems Will Your System Solve?

At the beginning, middle and end of the creation of any information system, it is important to continually evaluate what the system will be used for and what problems it will solve. Keeping in mind the system’s intended purpose will ensure that the design accounts for all functionality from the beginning. Losing sight of that purpose can lead to “scope creep,” in which the system is constantly overhauled to include additional features. It’s common for enhancement ideas to bubble up as a project develops, but adding features into a system late in its development can lead to project delays and unforeseen performance issues. Squeezing in extra functionality at the last minute can have unexpected consequences, especially if there’s no time to test how new features affect the rest of the system. 

One example of an IT project with a bad case of scope creep is the FBI’s Virtual Case File (VCF). Started in 2001, VCF was intended to automate a largely manual process of collecting information. Constant changes to both the IT staff and the project’s requirements resulted in numerous delays. In one 18 month period, the FBI changed the project requirements 399 times. Under such conditions, creating a fully functional system — much less an efficient one — was not possible. 

Audience: Who Will Be Using Your System?

After determining what the system is being built (or rebuilt) to do, you need to consider who will be using it. Your target audience is a huge factor, not only in deciding how the system’s features will be displayed to the user, but also in evaluating performance. For example, what is the size of the intended audience? Is it a small group of users within a single company? Or are you creating a Web system with potentially millions of online users? What languages does your audience speak? Might any users have disabilities that could make it difficult to use the system? Putting a face to your audience will help you keep your project in perspective.  

You can’t generate sales if you design a system that’s aimed at the wrong demographic. But designing a system without a targeted audience in mind can also affect system performance. If you underestimate the size of your audience, you’re at risk of creating a system that will be bogged down by too many users and too much data — possibly more than your network connection can handle.

Resources: What Do You Have to Work With?

Once you have defined the proposed system’s purpose and audience, consider what the system will be made of: How many servers can be dedicated to the system? How many applications will it run? How many people will be needed to maintain it? What kind of a budget is there to make all this happen?

It’s vital to ensure that the system has enough capacity to handle the target audience. Google, for example, attempts to accommodate an unlimited number of users and has built an expansive network of servers for web searching as a result. In 2006, Google had a network of more than 450,000 servers to ensure that there is always a server available for incoming search requests. While not everyone has a need for such extensive hardware and software, it’s always wise to expand your system as far as your resources allow.  

Time: How Much Time Do You Need?

Now that you’ve determined your system’s purpose, its intended audience and your available resources, you need to examine how long it takes for the system to process a given request. Is there a certain amount of time in which the system must process the request? How much time is used by each component of the system during the request? 

Modern information systems are composed of multiple applications, distributed across multiple servers. They can run room to room, coast to coast, or even country to country. Many are constructed using service oriented architecture (SOA), in which a series of reusable components and services can be networked together quickly to build or augment a system. While this reduces the time required to construct a system, it also makes it difficult to ensure performance. After all, a system is only as fast as its slowest component. That means every system component or process must be closely scrutinized and timed to determine which component, if any, might create a potential performance bottleneck.  

Put It All Together

During the initial design of most systems, the purpose, audience, available resources and timing benchmarks are usually taken into account. Unfortunately, many projects fail to keep these four key points in mind throughout the project. Losing track of any one of them can lead to poor performance.

By defining your system’s purpose, audience and resources, and by regularly testing each facet of the information system separately, the time needed for troubleshooting issues later will be greatly reduced. When it comes to building a high-performance solution to a technical problem, the important thing is to make sure that the complete information system is still the sum of its PARTs.