Case Study 1: CNB's Annual Capacity Planning Cycle

Case Study 1: CNB's Annual Capacity Planning Cycle

Background

Continental National Bank runs its core banking system on a z16 Parallel Sysplex with four LPARs — CNBA through CNBD. The system processes 500 million transactions per day across online banking, ATM networks, wire transfers, and ACH processing. The machine is rated at 6,534 MSU for general purpose processors, with an additional 2,400 MSU of zIIP capacity across 8 specialty engines.

Kwame Mensah has owned the capacity planning function at CNB for twelve years. When he inherited it, "capacity planning" consisted of a systems programmer checking utilization once a quarter and telling management "we're fine" or "we need more." Kwame built the discipline into a formal process that connects technical measurement to business strategy to financial planning. The process has prevented three potential capacity crises and saved CNB an estimated $4.2 million in avoided emergency upgrades and optimized software licensing over the past decade.

This case study follows CNB through one complete annual capacity planning cycle — from data collection in October to execution monitoring through the following September.

Phase 1: Data Collection (October)

Historical Data Extraction

Kwame's capacity planning cycle begins on the first business day of October. His first action is to kick off the historical data extraction batch jobs:

CAPDHIST — Extracts 36 months of daily capacity data from the DB2 capacity repository (CAPACITY_CPU_DAILY, CAPACITY_WKL_DAILY, CAPACITY_IO_DAILY tables). This produces a flat file with one record per LPAR per day, containing average and peak GP utilization, zIIP utilization, MSU consumption, and EXCP counts.
CAPDHRLY — Extracts 90 days of hourly data for detailed peak analysis (CAPACITY_CPU_HOURLY table). This is used to identify within-day patterns and calculate R4HA profiles.
CAPDRFHA — Extracts 24 months of monthly R4HA data from the SCRT history. This is the billing data — what CNB actually paid IBM each month.

The extraction jobs run for approximately 45 minutes and produce three datasets totaling about 180 MB. Kwame loads these into a capacity planning spreadsheet — yes, a spreadsheet. He has tried several capacity planning tools over the years and keeps coming back to Excel. "The tools are great at collecting data," he says. "They're terrible at the judgment calls. I'd rather have the data in a format where I can manipulate it directly."

Trend Analysis

With 36 months of data, Kwame calculates trend lines for each workload category. He uses the WLM service class breakdown to separate the aggregate data into meaningful components:

CNB Trend Analysis — October 2025
(Monthly R4HA, MSU, by workload category)

Category          36mo Ago   24mo Ago   12mo Ago   Current   CAGR
──────────────    ────────   ────────   ────────   ───────   ────
Online (CICS)      820        920       1,040      1,150     12.0%
Batch              1,350      1,440     1,530      1,610     6.1%
DB2 (DRDA/API)     180        260       380        520       42.3%
DB2 (Utilities)    280        290       300        310       3.5%
MQ/Integration     90         120       160        210       32.6%
Infrastructure     150        155       160        165       3.3%
──────────────    ────────   ────────   ────────   ───────
Total              2,870      3,185     3,570      3,965     11.3%

Several patterns emerge:

Online growth (12% CAGR) is driven by mobile banking adoption. CNB's mobile transaction volume has been growing steadily since the app redesign two years ago.
Batch growth (6.1% CAGR) is decelerating. Three years ago it was growing at 9%. The deceleration reflects CNB's batch optimization work — programs that have been tuned, jobs that have been consolidated, and some processing that has migrated to real-time.
DB2 DRDA/API growth (42.3% CAGR) is explosive. This is the z/OS Connect API layer that Carlos Vega's team at SecureFirst helped pioneer — CNB adopted it two years ago, and API call volume has been doubling annually. The good news: most of this is zIIP-eligible.
MQ/Integration growth (32.6% CAGR) reflects the event-driven architecture initiative. More systems are using MQ for inter-system communication, and the real-time fraud detection system (deployed 18 months ago) generates significant MQ traffic.
Total system R4HA (11.3% CAGR) is growing faster than any single traditional workload because the high-growth categories (API, MQ) are adding to, not replacing, the existing workloads.

Seasonal Pattern Analysis

Kwame calculates seasonal indices using 36 months of data:

CNB Seasonal Indices (R4HA):

            Online   Batch   DB2/API   Overall
January     0.93     0.94    0.90      0.93
February    0.91     0.92    0.88      0.91
March       1.02     1.04    1.02      1.03
April       0.97     0.98    0.97      0.97
May         0.96     0.96    0.98      0.96
June        1.01     1.02    1.03      1.02
July        0.94     0.93    0.96      0.94
August      0.98     0.97    0.99      0.98
September   1.03     1.05    1.04      1.04
October     1.07     1.08    1.08      1.08
November    1.05     1.04    1.06      1.05
December    1.13     1.12    1.14      1.13

December stands out at 1.13 — 13% above the annual trend. This is year-end processing: holiday transaction volume, annual interest calculations, year-end regulatory reporting, and the general surge in banking activity. March and September show smaller peaks aligned with quarter-end processing.

Phase 2: Business Input (November)

Business Unit Meetings

Kwame schedules meetings with four groups in November:

Retail Banking Division. The retail banking VP informs Kwame that CNB is launching a buy-now-pay-later (BNPL) product in Q2 of the coming year. Estimated transaction volume: 2 million BNPL transactions per month at launch, growing to 5 million per month by year-end. Each BNPL transaction is computationally more expensive than a standard purchase because it involves credit scoring, installment scheduling, and multiple ledger entries.

Corporate Banking Division. Corporate banking is planning to onboard three large corporate clients for real-time treasury management. This will add approximately 500,000 API calls per day — all through z/OS Connect (zIIP-eligible).

Mergers and Acquisitions. CNB's M&A team is in late-stage negotiations to acquire Pacific Trust Bank, a community bank with a standalone z15 running 1,200 MSU of workload. If the acquisition closes (expected Q3), Pacific Trust's workload will be migrated to CNB's sysplex. Kwame estimates 60% additive capacity — about 720 MSU — because some processing will consolidate (shared infrastructure, deduplicated reporting, consolidated batch streams).

Technology Division. Lisa Tran's DB2 team is planning a DB2 13 upgrade in Q2. IBM's benchmarks suggest a 5-8% CPU reduction for most workloads due to optimizer improvements, with a 10-15% increase in zIIP offload for eligible processing. Additionally, the security team is deploying pervasive encryption Phase 2, which will encrypt data at rest in all DB2 tablespaces. Estimated crypto overhead: 3-4% of DB2 CPU.

Application Team Survey

Kwame sends a standardized survey to all application teams asking:

Are you planning to deploy new programs or major changes in the coming year? If yes, estimate the transaction/record volume and expected go-live date.
Are you planning to retire any programs or workloads? If yes, estimate the capacity reduction.
Are your current capacity consumption trends expected to continue, accelerate, or decelerate? Why?

He receives responses from 14 teams. Most project "steady state" or "slight increase." Two project significant increases (the BNPL team and the API gateway team). One projects a decrease (the legacy report team, which is migrating three monthly reports to a cloud-based analytics platform).

Capacity Events Calendar

Kwame consolidates the business inputs into the capacity events calendar:

CNB Capacity Events Calendar — FY2026

Event                          Quarter  GP Impact    zIIP Impact   Confidence
──────────────────────────────────────────────────────────────────────────────
BNPL product launch            Q2       +85 MSU      +30 MSU       Medium
Corporate treasury onboarding  Q2       +15 MSU      +45 MSU       High
DB2 13 upgrade                 Q2       -6% batch    +12% zIIP     Medium
                                        -4% online
Pacific Trust acquisition      Q3       +720 MSU     +80 MSU       Medium-Low
                                                                   (deal not closed)
Pervasive encryption Phase 2   Q3       +40 MSU      0             High
Legacy report migration        Q3       -25 MSU      0             High
Real-time fraud scoring v2     Q4       +50 MSU      +120 MSU      Medium
Holiday season peak            Q4       seasonal     seasonal      High

The Pacific Trust acquisition is flagged as Medium-Low confidence because the deal hasn't closed and the timeline could shift. Kwame builds two versions of the forecast — one with the acquisition and one without — and presents both.

Phase 3: Modeling and Scenario Analysis (December)

Composite Forecast

Kwame builds the composite forecast by combining: 1. Trend: Linear regression on 36 months of data, by workload category 2. Seasonal: Monthly indices applied to the trend 3. Business events: Added as step functions at their expected quarter

CNB Composite Forecast — FY2026 (Expected Scenario, with Pacific Trust)

           Q1      Q2      Q3      Q4
           ────    ────    ────    ────
Online:    1,200   1,380   1,420   1,530
Batch:     1,650   1,630   2,320   2,490
DB2/API:   560     680     730     820
DB2 Util:  315     300     420     450
MQ/Integ:  230     260     290     340
Infra:     170     175     180     185
           ────    ────    ────    ────
Total GP:  4,125   4,425   5,360   5,815
zIIP:      690     870     1,020   1,230

Notes:
- Q2 includes BNPL launch, treasury onboarding, DB2 13 upgrade
- Q3 includes Pacific Trust migration (+720 batch, +80 zIIP),
  pervasive encryption (+40 GP), legacy migration (-25 GP)
- Q4 includes seasonal factor (1.13) and fraud scoring v2

Three Scenarios

CNB R4HA Forecast — FY2026 (MSU)

                Q1      Q2      Q3      Q4
Conservative:   3,950   4,100   4,500   4,850
Expected:       4,125   4,425   5,360   5,815
Aggressive:     4,350   4,700   5,700   6,250

Machine capacity: 6,534 MSU GP

Headroom (Expected scenario):
  Q1: 2,409 MSU (37%)
  Q2: 2,109 MSU (32%)
  Q3: 1,174 MSU (18%)
  Q4: 719 MSU (11%) — BELOW 15% threshold

The Q4 Expected scenario leaves only 11% headroom — well below the 15% minimum that Kwame considers safe. The Aggressive scenario for Q4 (6,250 MSU) is within 4% of the machine's rated capacity, which is dangerously close.

Financial Impact

CNB MSU Budget — FY2026

                       Q1       Q2       Q3       Q4      Annual
                       ────     ────     ────     ────    ──────
GP R4HA (Expected):    4,125    4,425    5,360    5,815
TFP/ECS commitment:    4,200    4,200    4,200    4,200
Overage MSU:           0        225      1,160    1,615

TFP base ($11/MSU):    $138.6K  $138.6K  $138.6K  $138.6K  $554.4K
TFP overage ($18/MSU): $0       $12.2K   $62.6K   $87.2K   $162.0K
Hardware depreciation:  $185K    $185K    $185K    $185K    $740K
CoD charges:           $0       $0       $15K     $25K     $40K
                       ──────   ──────   ──────   ──────   ───────
Total:                 $323.6K  $335.8K  $401.2K  $435.8K  $1,496.4K

The TFP overage charges in Q3 and Q4 are significant — $149.8K combined. Kwame evaluates whether renegotiating the TFP commitment to 5,000 MSU (increasing the base charge but reducing overage) would be more cost-effective:

Alternative: TFP commitment at 5,000 MSU

TFP base ($10.50/MSU*): $157.5K × 4 = $630K  (* bulk discount at higher commitment)
TFP overage ($18/MSU):  $0 + $0 + $6.5K + $14.7K = $21.2K

Total TFP: $651.2K vs. current $716.4K
Savings: $65.2K/year

Renegotiating the commitment saves $65K annually. Kwame recommends this to the CFO with the caveat that it only makes sense if the Pacific Trust acquisition proceeds — without it, the higher commitment would be wasteful.

Phase 4: Review and Approval (January)

Executive Presentation

Kwame presents the capacity plan to the CIO, CFO, and VP of Infrastructure in a 45-minute meeting. His presentation follows a deliberate structure:

Slide 1: Executive Summary. One sentence: "CNB's mainframe capacity will be adequate through Q2 2026 under current configuration; Q3/Q4 require either a hardware upgrade or workload optimization to maintain service levels, primarily driven by the Pacific Trust acquisition."

Slide 2: Current State. Machine utilization (67% average, 89% peak), R4HA trend, year-over-year growth.

Slide 3: Business Drivers. The capacity events calendar — but translated into business language, not technical. "Pacific Trust migration adds capacity equivalent to a 20% increase" rather than "720 MSU additive."

Slide 4: The Three Scenarios. Visual chart showing R4HA trend lines for conservative, expected, and aggressive scenarios, with the machine capacity ceiling drawn as a horizontal line.

Slide 5: Financial Impact. The MSU budget comparison — current TFP commitment vs. recommended renegotiation. The total cost by quarter.

Slide 6: Recommendation. Three options: 1. Hardware upgrade to z16 A02 (6 additional GP engines, rated at 8,200 MSU). Cost: $2.8M, timeline: order in Q1, install in Q3. Provides headroom through 2028. 2. Capacity on Demand for Q3/Q4 (temporary capacity activation). Cost: $180K for 90 days of 1,200 additional MSU. Buys time but doesn't solve the underlying constraint. 3. Workload optimization (aggressive zIIP offload, batch scheduling optimization, WLM capping). Cost: $250K in consulting and implementation, potential to defer the hardware upgrade by 12 months.

Kwame recommends Option 1 with Option 3 as a parallel track: "Buy the hardware because the acquisition demands it, but also optimize because the savings compound every year."

Approval Outcome

The CFO approves Option 1 contingent on the Pacific Trust acquisition closing. If the acquisition is delayed or cancelled, CNB will execute Option 3 and defer the hardware decision. The CFO also approves the TFP renegotiation to 5,000 MSU, contingent on the same condition.

Rob Calloway, attending the meeting as batch operations lead, raises a practical concern: "When do we install? We can't take the sysplex down during quarter-end processing." Kwame has already planned for this: the installation window is the second weekend of July — the lowest-volume period in the banking calendar. The z16 parallel sysplex capability allows rolling upgrades, so only one LPAR at a time is taken offline.

Phase 5: Execution and Monitoring (February–September)

Monthly Tracking

Kwame publishes a monthly capacity dashboard that goes to the CIO, the VP of Infrastructure, and the operations management team:

CNB Capacity Dashboard — March 2026

                    Plan     Actual   Variance
R4HA (GP):          4,125    4,080    -1.1%    ✅ Within tolerance
zIIP utilization:   58%      61%      +3 pp    ⚠️ Trending high
Batch window:       83%      81%      -2 pp    ✅ Under plan
GP peak util:       82%      80%      -2 pp    ✅ Under plan

Commentary:
- R4HA tracking slightly below forecast. Mobile banking growth
  slower than projected in Q1 (seasonal). Expected to accelerate in Q2.
- zIIP utilization 3 points above plan. API call volume growing faster
  than projected. Not a concern yet but monitoring closely — if the
  trend continues, zIIP capacity may become a constraint before GP.
- Batch window healthy. Rob's scheduling optimizations from Q4 last year
  continue to provide margin.

Capacity events status:
- BNPL launch: on track for Q2. Capacity POC completed — actual CPU is
  0.0065 sec/txn vs. estimate of 0.0055 sec/txn. Revising impact
  estimate upward by 18%.
- Pacific Trust acquisition: legal close expected end of May. Migration
  planning underway. Workload assessment of Pacific Trust's z15 in progress.
- DB2 13 upgrade: moved from Q2 to Q3 due to testing delays.

Quarterly Review (April)

The Q1 quarterly review reveals:

R4HA is tracking 1-2% below the Expected scenario — good news, primarily because January and February are seasonally low months and the mobile banking growth was slightly below projection.
The BNPL capacity impact is 18% higher than estimated. Kwame revises the Q2 forecast upward by 15 MSU. Not a crisis, but it illustrates why capacity POCs are essential.
The DB2 13 upgrade slipped from Q2 to Q3. This means the 5-8% CPU reduction Kwame had forecast for Q2 won't materialize until Q3. He adjusts the Q2 forecast upward (no DB2 savings) and Q3 forecast downward (DB2 savings arrive later but coincide with the Pacific Trust migration, partially offsetting it).
zIIP growth is outpacing GP growth. Kwame adds a zIIP capacity analysis to the next quarterly review — CNB may need to add zIIP engines when the hardware upgrade occurs.

The Pacific Trust Migration (Q3)

The acquisition closes in late May. Pacific Trust's workload assessment reveals:

Standalone capacity: 1,180 MSU (slightly below the 1,200 MSU estimate)
Expected additive capacity after consolidation: 680 MSU (vs. Kwame's estimate of 720 MSU)
The 40 MSU difference is because Pacific Trust's batch processing is more efficient than Kwame assumed — their batch operations lead had recently completed an optimization project.

The migration occurs in three phases: - Phase 1 (July): Online transactions migrated to CNBC/CNBD (add 180 MSU online) - Phase 2 (August): Batch processing migrated to CNBA/CNBB (add 400 MSU batch) - Phase 3 (September): DB2 data consolidation and Pacific Trust z15 decommissioned (add remaining 100 MSU)

The hardware upgrade (Option 1) is installed during the July weekend as planned. The upgrade provides the headroom needed for Phase 2 and Phase 3 of the migration.

Results and Lessons

By the end of September, CNB's capacity picture looks like this:

Post-Upgrade, Post-Migration Status (September):

Machine:          z16 A02, rated 8,200 MSU GP, 3,200 MSU zIIP
Current R4HA:     5,180 MSU (GP)
Headroom:         3,020 MSU (37%) — healthy
zIIP utilization: 64% average — adequate but worth monitoring
Forecast accuracy: MAPE of 2.8% for months where no business events occurred,
                   7.1% for event months (Pacific Trust was 5.6% below estimate,
                   BNPL was 18% above estimate)

Lessons Learned

Business event estimates are the largest source of forecast error. The trend and seasonal components were within 2-3% of actuals. The business events (BNPL, Pacific Trust) contributed the most variance. Kwame's takeaway: invest more time in capacity POCs for high-impact events.
The capacity events calendar works. Every significant capacity change in the year was on the calendar — no surprises. The calendar forced early conversations with business units that would not have happened without the formal process.
zIIP is becoming a planning dimension, not just an optimization. For the first time, CNB's zIIP utilization is a capacity concern independent of GP utilization. Kwame adds zIIP capacity forecasting as a permanent element of the annual plan going forward.
Contingent planning is essential. The CFO's decision — "approve the upgrade contingent on the acquisition" — was possible because Kwame presented multiple options with clear decision points. If the acquisition had fallen through, CNB would have executed Option 3 (optimization) and deferred the hardware upgrade. Having both options ready made the organization agile.
The spreadsheet works, but it's reaching its limits. With four LPARs, twelve service classes, two engine types, five business events, and three scenarios, Kwame's capacity planning spreadsheet has grown to 47 tabs. He's evaluating BMC Capacity Management and IBM's Z Capacity Analytics for the next cycle — not to replace his judgment, but to reduce the data wrangling effort so he can spend more time on analysis and business engagement.

Discussion Questions

Kwame's forecast accuracy was 2.8% for baseline months and 7.1% for event months. Is 7.1% acceptable? What would you consider an unacceptable error rate, and what actions would you take if the error rate exceeded that threshold?
The Pacific Trust acquisition capacity estimate was revised downward from 720 MSU to 680 MSU after the workload assessment. What would Kwame have done if the assessment had shown 900 MSU — exceeding the machine's post-upgrade capacity? Walk through the decision process.
The CFO approved a $2.8M hardware upgrade. How would you present the ROI of this investment? What metrics would you use to demonstrate value to a financially-oriented audience?
Kwame recommends both Option 1 (hardware upgrade) and Option 3 (workload optimization) in parallel. Why is optimization still valuable even after the hardware upgrade? Quantify the potential savings over a three-year horizon.
The zIIP trend is a new capacity concern. Design a zIIP-specific capacity planning analysis for CNB. What data would you collect, what metrics would you track, and how would you forecast zIIP requirements independently from GP?