Sizing infrastructure has always required a balance between performance, capacity, and risk. What has changed is the level of precision required to make those decisions.

Hardware timelines are less predictable. Costs are under closer review. Decisions that were once routine now require clear justification. In many cases, the question is no longer just how much capacity is needed, but whether that capacity can be delivered when it is needed and whether the investment will hold up under scrutiny.

That shifts how sizing needs to be approached.

In many environments, this shows up in a very practical way. Standard refresh cycles are no longer reliable. A three-year replacement plan may not align with procurement timelines, budget approvals, or current demand. As a result, sizing decisions now determine whether existing infrastructure can be extended, where capacity can be reclaimed, and when new investment is truly required.

To size infrastructure well in this climate, you need a clearer picture of how your systems are actually performing, where capacity is available, how quickly demand is changing, and what level of risk your organization can reasonably accept. This article focuses on those factors and how they come together to support more confident decisions.

Start with What Your Environment Is Actually Doing

Sizing decisions often begin with projections. Growth estimates, expected demand, and future state assumptions all play a role. Those inputs are still useful, but they are no longer sufficient on their own.

A more reliable starting point is understanding how your environment is behaving today and how it has behaved over time.

This includes:

• Current utilization across compute, storage, and network resources
• Historical patterns that show when and how demand increases
• The difference between average usage and sustained peaks

For organizations running IBM PowerVS™ and IBM FlashSystem® storage, this visibility is particularly important. Business-critical workloads often depend on these platforms for performance, reliability, and scalability, making accurate sizing decisions essential to both operational efficiency and long-term infrastructure planning.

This level of detail helps establish a baseline that reflects actual conditions, not just expected ones.

Without it, planning tends to rely on conservative estimates that can lead to unnecessary spending or delayed decisions.

For example, a team may assume it needs additional capacity because month-end processing regularly causes concern. Once the data is reviewed more closely, the issue may turn out to be a short-lived spike isolated to one part of the environment rather than a broad capacity shortfall. That leads to a very different planning decision.

Look Beyond Averages to Understand Demand

Averages are easy to work with, but they rarely tell the full story.

A system that appears to run at moderate utilization on average may experience regular periods of high demand. Those periods are often where performance issues emerge and where capacity limits are tested.

Sizing decisions should account for:

• How often peak conditions occur
• How long they last
• Whether they are increasing over time

This provides a clearer view of what your environment needs to support, rather than what it appears to use at a glance.

A common example is a business-critical application that looks stable in weekly reporting, yet experiences a sharp increase in resource demand every Monday morning or during overnight batch activity. In that situation, average utilization can make the system look comfortable when it is actually operating with very little margin during the periods that matter most.

Understand Where Capacity Is Actually Available

In many environments, capacity is not evenly distributed.

Some systems may be approaching their limits, while others have available headroom that is not immediately visible. Workloads may also be placed in ways that do not fully utilize the infrastructure as a whole.

Before adding capacity, it is worth understanding:

• Where resources are underutilized
• Whether workloads can be adjusted or redistributed
• How different components of your environment interact under load

This does not eliminate the need for new infrastructure, but it helps ensure that existing resources are being used effectively.

This is especially relevant in environments that have grown over time through multiple projects, refresh cycles, or acquisitions. It is not unusual to find one cluster running hot while another has room to spare, or to discover that storage performance constraints are being mistaken for a compute issue. When you can see those relationships clearly, the sizing conversation becomes far more precise.

Account for Timing, Not Just Demand

One of the more significant changes affecting sizing is the role of timing.

When hardware procurement was predictable, teams could plan upgrades around anticipated demand. If capacity was needed, it could typically be added within a known timeframe.

That assumption is less reliable now.

Sizing decisions should consider:

• How long will it take to acquire and deploy new hardware
• Whether existing systems can support demand during that window
• What contingencies are available if timelines shift

In some cases, this means extending infrastructure beyond its original refresh window. In others, it confirms that additional capacity is required sooner than expected.

This adds another dimension to planning. It is no longer just about how much capacity is required, but when that capacity must be available and what happens if it is not.

Consider a team planning for a platform upgrade tied to a business initiative six months out. On paper, the project may appear well within range. In practice, long procurement cycles, deployment lead time, and internal approval steps can shorten the margin for error considerably. That is why timing has become part of the sizing discussion, not just an operational detail that gets addressed later.

Be Explicit About Risk

Every sizing decision involves some level of risk. The difference now is that risk needs to be understood and communicated more clearly.

Common trade-offs include:

• Delaying investment versus increasing the chance of performance impact
• Adding capacity versus increasing cost
• Extending the life of existing systems versus accepting operational constraints

These decisions are easier to manage when the risks are defined in concrete terms.

For example:

• How close are systems to their limits under peak conditions?
• How quickly is demand increasing?
• What is the potential impact if capacity is exceeded?

Answering these questions with data makes it possible to align decisions with both technical requirements and business priorities.

This is where many sizing discussions either gain traction or lose credibility. Saying that capacity is getting tight is not enough. Showing that a system has reached the same utilization threshold in each of the last three quarter-end cycles, with each event lasting longer than the one before it, gives leadership something concrete to evaluate.

Use Historical Data to Support Decisions

Historical data provides context that is difficult to replace.

It shows how systems have performed under different conditions, how demand has changed, and where patterns exist. This information supports more accurate sizing and helps avoid decisions based solely on short-term observations.

With sufficient historical data, you can:

• Compare current demand to previous peaks
• Identify trends that indicate future growth
• Validate whether capacity concerns are immediate or emerging

This makes it easier to determine when action is required and when existing infrastructure can continue to support demand.

Historical data is also useful when a proposed investment is challenged. A request for additional infrastructure is easier to defend when you can show a sustained pattern of growth over twelve months rather than a temporary spike over the last two weeks. It also works the other way. In some cases, historical analysis shows that a recent issue was isolated and does not justify a broader expansion.

Prepare to Explain the Decision

Sizing decisions are increasingly part of broader conversations that include finance and executive leadership.

It is not enough to determine what is needed. You also need to explain why.

This includes:

• The data used to support the decision
• The risks associated with different options
• The expected impact on performance and cost

Clear explanations build confidence and help ensure that decisions are understood and supported.

This is particularly important when budgets are tight, and other priorities are competing for the same dollars. A well-supported sizing decision helps leadership understand whether they are funding necessary capacity, reducing avoidable risk, or preserving performance for a critical service. It moves the conversation away from opinion and toward evidence.

Where Visibility Becomes Critical

All of these considerations depend on having access to accurate and complete information.

Basic monitoring provides useful insight into current performance. For sizing decisions, you need a deeper view that includes:

• Detailed historical data
• Consistent metrics across systems
• The ability to analyze trends and relationships across your environment

With that level of visibility, sizing becomes a more informed process. Decisions are based on observed behavior and supported by data that can be validated and shared.

Platforms like Galileo, originally developed to provide deep performance visibility across IBM Systems environments, are designed to capture and retain detailed performance data over time and present it in a way that supports both analysis and communication.

That matters when the issue is not isolated to one system. A slowdown in application performance may be tied to storage latency, a workload placement issue, or increased demand in another part of the stack. When those relationships are visible, you can size more accurately and avoid solving the wrong problem.

A More Deliberate Approach to Sizing

Sizing infrastructure has always required judgment. What has changed is the need for that judgment to be grounded in clearer, more complete information.

By focusing on actual usage, understanding how demand behaves over time, accounting for timing constraints, and defining risk explicitly, you can make decisions that are both practical and defensible.

This approach does not eliminate uncertainty. It provides a way to navigate it with greater confidence.

In many organizations, that is what effective sizing looks like now. It is not a one-time estimate created in isolation. It is an informed decision shaped by performance data, historical context, procurement realities, and business priorities.

What This Means for IBM Systems Environments

As an IBM Gold Business Partner, ATS Group helps organizations evaluate, implement, and optimize IBM Systems environments. Combined with Galileo®, originally developed to provide deep visibility into IBM infrastructure, teams gain the historical performance insight and operational context needed to support confident sizing and planning decisions.