Fujitsu Services Horizon Capacity Management and Business Volumes __ Ref:
Commercial In Confidence
Version:
Date:
FUJ00001719
FUJ00001719
PA/PER/033
1.0
31-Dec-2002
Document Title:
Document Type:
Release:
Abstract:
Document Status:
Originator & Dept:
Contributors:
Internal Distribution:
Horizon Capacity Management and Business Volumes
Requirements
N/A
This document describes the process of managing capacity and
the business workload volumes that the Horizon system will
support under contract extension.
It will form part of the new contract as a CCD.
APPROVED
James Stinchcombe, IPDU
Colin Lenton-Smith
Liam Foley
Peter Jeram
Martin Riddell
Gill Jackson Hilary Forrest
Dave Hollingsworth Peter Robinson
Allan Hodgkinson John Pope
Peter Burden Tony Drahota
Richard Brunskill Dave Cooke
Tony Oppenheim
External Distribution: Post Office
Keith Baines Bob Booth
Torstein Godeseth Clive Reed
Mike Wells Liz Tuddenham
Approval Authorities:
Name Position Signature Date
Dave Hollingsworth
Consultancy Services Director,
Fujitsu Services, Pathway
Clive Reed
Head of Technical Architecture,
Post Office Ltd
© 2002 Fujitsu Services
Commercial In Confidence
Page: I of 35
FUJ00001719
FUJ00001719
Fujitsu Services Horizon Capacity Management and Business Volumes __ Ref: PA/PER/033
Version: 1.0
Commercial In Confidence Date: 31-Dec-2002
0.0 Document Control
0.1 Document History
Version No. I Date Reason for Issue Associated
CP/PinICL
0.1 8/11/02 1* Draft - issued internally only.
0.2 19/11/02 2" Draft following comments on 0.1 Issued
internally only.
0.3 2/12/02 3" Drafi. Issued to Post Office for review
0.4 16/12/02 4" Draft following review with Post Office.
0.5 20/12/02 5" Draft following further comments by Post Office.
0.6 30/12/02 6" Drafi following further discussions with Post
Office
0.7 30/12/02 7 Draft following review of 0.6 with Post Office.
0.8 31/12/02 8" draft following Post Office review
0.9 31/12/02 FS [final] drafting changes
1.0 31/12/02 Agreed Version
0.2 Review Details
Review Comments by :
31% December 2002
Review Comments to :
James Stinchcombe
Mandatory Review Authority
Name
Commercial
Hilary Forrest
Colin Lenton-Smith*
Tony Oppenheim*
Customer Services
Martin Riddell
Peter Robinson
Peter Burden*
Richard Brunskill
Requirements
Dave Hollingsworth*
John Pope*
Dave Cooke*
Post Office
Keith Baines*
Richard Cowan*
Clive Reed
Liz Tuddenham
ASD
Tony Drahota
Allan Hodgkinson*
© 2002 Fujitsu Services
Commercial In Confidence
Page: 2 of 35
FUJ00001719
FUJ00001719
Fujitsu Services Horizon Capacity Management and Business Volumes __ Ref: PA/PER/033
Version: 1.0
Commercial In Confidence Date: 31-Dec-2002
Optional Review / Issued for Information
Post Office Fujitsu Services
Peter Jeram
Bob Booth Liam Foley
Torstein Godeseth Gill Jackson
Mike Wells
(*) = Reviewers that returned comments
0.3. Associated Documents
Reference Version I Date I Title Source
NewBusVols 3.0 PA/PER/031 - "Horizon New Service PVCS
Business Volumes"
ExistBusVol 0.1 PA/PER/032 - “Horizon Existing PVCS
Service Business Volumes”
AllocProcess 1.0 TD/PRO/003 - “Process for Allocating I PVCS
Network Service Type to Outlets”
AllocSheet 13/9/02 I Outlet Allocation Spreadsheet Fujitsu
"OutletA llocation_020912.xlIs" Services
Unless a specific version is referred to above, reference should be made to the current
approved versions of the documents.
0.4 Abbreviations/Definitions
Abbreviation Definition
ACDB Autoconfig Database
Agreement Agreement between Post Office and Fujitsu Services dated 28 July 1999 as varied
and restated by CCN 1100.
APS Automated Payment Service
Banking Transactions
NBS and DC Transactions
CAPO™
Card Account at Post Office. The official brand name of POCA (Post Office Card
Account).
ccD Contract Controlled Document
CCN Contract Change Notice
© 2002 Fujitsu Services
Commercial In Confidence
Page: 3 of 35
FUJ00001719
FUJ00001719
Fujitsu Services Horizon Capacity Management and Business Volumes __ Ref: PA/PER/033
Version: 1.0
Commercial In Confidence Date: 31-Dec-2002
Contracted Volumes
The volumes that Fujitsu Services contracts to support. Exceeding these volumes
will cause given Service Levels to automatically not apply (see Schedule 15 for
details).
CSR Core Systems Release
CSR+ Core Systems Release (plus)
DC Debit Card. Previously known as EFTPOS.
Design Limits
The volumes that the system can support without significant failures. Exceeding
these volumes could cause any Service Level or other obligation not to apply (see
Schedule 15 for details).
DRS Data Reconciliation Service
EFTPoS Electronic Funds Transfer Point of Sale
EPOSS Electronic Point of Sale Service
Historical Peak
A peak workload based on historical data from start of Horizon until 30 August
2002
TIN Issuer Identification Number
ISDN Integrated Services Digital Network
LAN Local Area Network
LFS Logistical Feeder System
MIDTID The MID/TID allocation database for Debit Card
MVL Motor Vehicle Licenses
NB Network Banking
NBE Network Banking Engine
NBS Network Banking Service
OCMS Outlet Change Management System
OBCS Order Book Control Service
Online Transactions
Transactions that require an interaction with the data centre, currently OBCS
Foreigns and Banking Transactions.
Pathway Fujitsu Services (Pathway) Ltd
POL, Post Office Post Office Ltd
RDDS Reference Data Distribution Service
RDMC Reference Data Management Centre
Services The services provided under the Agreement
SLA Service Level Agreement
VPN Virtual Private Network
WAN Wide Area Network
Terms and expressions defined in the Agreement have the same meanings where used in this
document.
© 2002 Fujitsu Services
Commercial In Confidence Page: 4 of 35
FUJ00001719
FUJ00001719
Fujitsu Services Horizon Capacity Management and Business Volumes __ Ref: PA/PER/033
Version: 1.0
Commercial In Confidence Date: 31-Dec-2002
0.5 Changes in this Version
Version Changes
0.1 I* Version
0.2 Changes following comments. Addition of section on the capacity model
summary.
0.3 Changes following comments. Section 2 replaced by a formal description
of the Capacity Management Service.
04 Changes following comments. Some parts of section 2 moved to the
contract schedules. Added reference data volumes, impact of ADSL and
number of Post Office branches changed.
0.5 Added wording from current responsibilities to cover Post Office
providing updates to future volumes. Change to numbering in section 2 to
bring in line with the rest of the document. Other changes following
comments.
All changes are redlined except for change to numbering in section 2 (to
make it more readable).
0.6 Changes to EPOSS Volumes (increased by to 5% above Historical Peak)
and Online Transactions to separate core system and network. Changes to
Capacity Model to reflect these. All changes are redlined.
0.7 Clarification on the source of the online transaction volumes. All charges
are redlined.
0.8 Wording changes proposed by Post Office
0.9 Wording changes.
1.0 Final wording changes by Post Office and Fujitsu
0.6 Changes Expected
Changes
© Updates following Review
* Changes under CCN to the current volumes
¢ Changes under CCN to introduce new business types (e.g. E-TopUps or DVLA online).
0.7 Table of Contents
1.0 INTRODUCTIO?
1.1 PURPOSE .
ey. N
© 2002 Fujitsu Services Commercial In Confidence Page: 5 of 35
FUJ00001719
FUJ00001719
Fujitsu Services Horizon Capacity Management and Business Volumes __ Ref: PA/PER/033
Version: 1.0
Commercial In Confidence Date: 31-Dec-2002
1.4 CAPACITY MANAGEMENT PRINCIPLE
1.5 PHASING OF CAPACITY .
2.0 CAPACITY MANAGEMENT SERVICE...
SERVICE SUMMARY
SERVICE AVAILABILITY
2.6 SERVICE DEPENDENCIES AND POST OFFICE RESPONSIBILITIE
3.0 BUSINESS METRICS...
3.1 EPOSS....
3.1.1 Products
3.1.2
3.2.1 Transactions...
3.2. Clients ..
3.3. OBCS..
3.3.1 With No Network Banking
3.3.2. With 50% Network Banking Rolled Out
3.3.3. With Network Banking Fully Rolled Out..
3.4 LFS.........
3.5 I MESSAGE BROADCAST .
3.6 REFERENCE DATA...
3.6.1 Reference Data Distribution
3.6.2. Token Definitions
3.7 NETWORK BANKING SERVIC!
3.7.1 Phase 1 Transaction Volumes
3.7.2. Phase 2 Transaction Volumes
3.7.3 Routing Gateways.........
3.8 DeBirT CARD
Introduction...
3.9.2 Central Systems ...
3.9.2.1 Phase 1
3.9.2.2 Phase 2 coeeessteeenneneennneeennees
3.9.3. Branch to Data Centre Network.
3.10 Post OFFICES
4.0 CAPACITY MODEL SUMMARY
4.1 ASSUMPTIONS...
4.2. Day ONLINE LoaD.
4.3. OVERNIGHT BATCH
44 STORAGE
5.0 VOLUME JUSTIFICATION...
5.1 ONLINE TRANSACTION ROLLOUT ....
© 2002 Fujitsu Services Commercial In Confidence Page: 6 of 35
FUJ00001719
FUJ00001719
Fujitsu Services Horizon Capacity Management and Business Volumes __ Ref: PA/PER/033
Version: 1.0
Commercial In Confidence Date: 31-Dec-2002
1.0 Introduction
1.1 Purpose
The ‘Horizon Capacity Management and Business Volumes’ documents the process of
managing the business workload volumes that the Horizon system will support and the
capacity required to support this workload under contract extension. It will form part of the
new contract as a CCD and replaces [NewBusVols] from the start date of the contract change.
This document is under Hard Change Control.
The key changes from [NewBusVols] are:
e The addition of Services not previously covered by [NewBusVols] - i.e. EPOSS, APS,
OBCS, LFS, Message Broadcast and Reference Data. Most of these were covered by
[ExistBusVols] which was previously issued for information to Post Office.
e Addition of a formal definition of the Capacity Management Service.
e Addition of a summary of the capacity model.
e Removal of the concept of “Contracted Notice Period”, “Design Limit Notice Period” and
“Scalability Thresholds” - changes to capacity are now treated like any other requested
change to the system rather than having specific notice periods.
¢ Changes to the Online Transaction Volumes required following the change in network
charges from variable cost to fixed cost.
1.2 Scope
The intention of the document is to:
e Describe the process of managing capacity within the Horizon system, the “Capacity
Management Service”. This includes how the key business metrics are agreed and the
impact of exceeding these (e.g. on Service Levels).
¢ Document the key business metrics required to determine the capacity required for the
different services that Horizon provide.
e Provide a summary of the output of the current capacity model, which is used to estimate
the amount of capacity required by the system.
The business metrics in this document will be used for:
e Sizing the infrastructure within the Fujitsu Services operational domain required to
deliver the Services.
e Capacity Management of the infrastructure within the Fujitsu Services operational
domain for those Services
© 2002 Fujitsu Services Commercial In Confidence Page: 7 of 35
FUJ00001719
FUJ00001719
Fujitsu Services Horizon Capacity Management and Business Volumes __ Ref: PA/PER/033
Version: 1.0
Commercial In Confidence Date: 31-Dec-2002
e Calculating the capacity used by the workload. This allows the impact of new services or
changes in volumes to be assessed.
The target audience for this document is varied and includes systems designers, capacity
managers and business and financial analysts. Some parts of this document may not be
appropriate for all readers.
1.3 Structure
Section 2 describes the Capacity Management Service and section 3 the Business metrics.
Section 4 provides a summary of the capacity model.
1.4 Capacity Management Principles
Capacity management is a balance between risk and cost. Having significant spare headroom
reduces the risk of unexpected peaks causing poor performance or service failures, but the
spare capacity has to be paid for.
The agreed principles under which business volumes and capacity will be managed are:
e Post Office estimates the business volumes that the system needs to support. As part of
this assessment they need to decide how much headroom or contingency for unexpected
growth in volumes is required.
e Fujitsu Services will support the Contracted Volumes and implement the infrastructure
needed to support that level of business volumes. This infrastructure may be implemented
in several phases if all of the additional capacity is not needed initially.
e Appropriate lets are given against Service Levels if the business volumes are exceeded.
e The Service Review Forum will periodically review the actual business volumes handled
by the system and projected future volumes, to allow sufficient notice to be given to allow
any additional capacity to be installed.
e Fujitsu Services shall maintain a capacity model that is shared with Post Office. This
allows the impact of changes to be jointly assessed.
e fan error is found in the capacity model or the assumptions on which it is based (see
section 4.1) are shown to be invalid, and this has a material consequence, either Party
may request an urgent review of the Contracted Volumes and Design Limits it needs to
support. Changes to these volumes cannot be unreasonably refused by Post Office,
provided that such change does not reduce the Contracted Volumes below the actual
volumes at that time.
© If Post Office requests an increase in any Contracted Volume or Design Limit, Fujitsu
Services shall not unreasonably withhold or delay its consent to such an increase, subject
to Post Office (i) agreeing (by Work Order) to meet all costs reasonably incurred by
Fujitsu Services in effecting such increase, and (ii) agreeing to meet (by CCN) any
© 2002 Fujitsu Services Commercial In Confidence Page: 8 of 35
FUJ00001719
FUJ00001719
Fujitsu Services Horizon Capacity Management and Business Volumes __ Ref: PA/PER/033
Version: 1.0
Commercial In Confidence Date: 31-Dec-2002
additional ongoing costs reasonably incurred by Fujitsu Services as a direct result of such
increase. Having given such consent, Fujitsu Services shall implement such increase as
promptly as reasonably practical. If an urgent increase is required within three months or
a significant increase is required within nine months of such consent, Fujitsu Services
may propose deferral of existing Work Order commitments and amendment of the
existing Resource Plan and Post Office shall determine its priorities.
e The costs of increased capacity, including any test kit configuration, are borne by Post
Office on the basis described in Schedule 10 ref 7.2.
To achieve this, the following are required:
e Anagreed capacity management process - the “Capacity Management Service”.
e A documented set of volumes the system should support.
e A capacity model.
This document covers all three items.
The consequences of exceeding the Contracted Volumes and Design Limits are set out in
schedule 15. This falls into two basic types:
e Volumes, which if they are exceeded, cause a let in the relevant Service Levels.
e Volumes, which if they are exceeded, require Post Office and Fujitsu Services to look at
the cause and see if the Service Levels or Volumes need to be changed.
The majority of volumes fall into the first type. Where the second type applies this is
highlighted in the document.
Notifying the author of changes to this document is a joint responsibility but Fujitsu Services
will maintain the document and submit updates to Post Office for review and approval.
1.5 Phasing of Capacity
Where a new service is rolled out over time, it may be beneficial to phase the installation of
additional capacity. This approach avoids having to purchase 100% capacity from day one,
which has the advantages that:
e It defers spend on capacity that is not needed initially.
e If the expected transaction volumes do not arise or occur later than expected, it may be
possible to avoid or delay having to increase the capacity.
© 2002 Fujitsu Services Commercial In Confidence Page: 9 of 35
FUJ00001719
FUJ00001719
Fujitsu Services Horizon Capacity Management and Business Volumes __ Ref: PA/PER/033
Version: 1.0
Commercial In Confidence Date: 31-Dec-2002
e Typically the unit cost of capacity decreases over time. Hence waiting to purchase
capacity typically means more capability can be purchased for the same price or the same
capacity for a lower price. However this cannot be guaranteed.
If it is decided to roll out capacity over time, the phasing will be included in this document.
For Network Banking and Online Transactions, the following shall apply:
(A) The Contracted Volumes and Design Limits relating to the Network Banking Service
shall, save as provided in paragraph (B), be those applicable in respect of Phase 1 (as defined
by section 3.7)
(B) In the event that Post Office serves a Phase 2 Notice on the Contractor, the Contracted
Volumes, Design Limits for the Network Banking Service shall, with effect from the date
specified in the Phase 2 Notice, be those applicable in respect of Phase 2. For the purposes of
this paragraph B, a “Phase 2 Notice” shall be a notice in writing given by Post Office to the
Contractor specifying a date, at least six months after the date of service of that notice but not
earlier than 1 September 2003, on which Post Office requires Phase 2 to commence.
© 2002 Fujitsu Services Commercial In Confidence Page: 10 of 35
FUJ00001719
FUJ00001719
Fujitsu Services Horizon Capacity Management and Business Volumes __ Ref: PA/PER/033
1.0
Commercial In Confidence Date: 31-Dec-2002
2.0 Capacity Management Service
This section provides the formal definition of the Capacity Management Service.
2.1. Service Summary
The process of managing capacity and the business workload volumes that the Horizon
system will support.
2.2. Service Principles
Operational staff will be appropriately trained and competent to carry out the services
expected of them as described within this document.
2.3. Terms and Meanings
In this Section, unless the context otherwise requires, the following terms have the following
meanings:
Contracted Volumes Each of the levels defined in section 3.0 of this document
Design Limit Each of the levels defined in section 3.0 of this document
Phase 1 As defined in section 3.7 of this document
Phase 2 As defined in section 3.7 of this document
Terms defined in the Agreement shall have the same meaning where used in this CCD.
2.4 Service Definition
(A) Fujitsu Services shall monitor the actual volumes as against the volumes specified in this
CCD and shall report such numbers and resulting trends at each meeting of the Service
Management Forum. The frequency of such reporting shall be agreed by the Service
Management Forum. The Service Management Forum shall also review volume forecasts
and may in the light of such reports, recommend changes that may be required. The parties
shall agree volumes, trends and/or peak thresholds which, if they occur or are exceeded in
live operation, shall be reported by Fujitsu Services to the Service Management Forum.
(B) Fujitsu Services shall produce and maintain a capacity model of the system. The
assumptions, inputs, calculations and outputs of the model shall be shared with, and used by,
for the purposes of capacity planning only, the Post Office members of the Joint Architecture
Forum and such other Post Office employees and professional advisors as reasonably require
access to such information. In the event that such information is disclosed by Post Office or
© 2002 Fujitsu Services Commercial In Confidence Page: 11 of 35
FUJ00001719
FUJ00001719
Fujitsu Services Horizon Capacity Management and Business Volumes __ Ref: PA/PER/033
Version: 1.0
Commercial In Confidence Date: 31-Dec-2002
(at Post Office’s request) by Fujitsu Services to Post Office's professional advisors, Post
Office shall procure that such professional advisors shall comply with the restrictions
contained in Clause 50 of the Agreement. For the avoidance of doubt, the disclosure of such
information shall not and shall not be deemed to transfer any Intellectual Property Rights of
Fujitsu Services in such information to any of Post Office, its employees or its professional
advisors.
The first version of the model produced before the signing of the contract amendment covers
the major systems. Additional components may be added later as required to provide, as far
as is reasonably practicable, a quantified understanding of system performance characteristics
as they relate to technical parameters such as Dial-Up Transaction Volumes
(C) Fujitsu Services shall use reasonable endeavours to optimise the capacity of the Horizon
Service Infrastructure so as to minimise the need for any future cost increase.
(D) As part of the Feasibility Assessment Stage for any changes, Post Office shall provide
initial business volumes and transaction details. From these Fujitsu Services shall produce
indicative capacity usage and indicative costs for any infrastructure changes required.
E) As part of the Requirements and Analysis Stage, Post Office shall produce final volumes,
which Fujitsu Services shall use to update this document. The reason for changes to the
infrastructure to support the business volumes and other changes shall be included in the
Design Proposal, including any quantification needed to provide transparency.
(F) In the event that Post Office requires a Contracted Volume or a Design Limit to be
increased it shall only be increased where such increase (and the amount of any additional
equipment required and/or the re-allocation of any system capacity or equipment) has been
agreed, through the Change Control Procedure. The impact of any such changes shall be
reviewed by the Joint Architecture Forum.
2.5 Service Availability
The Capacity Management Service shall be available 09:00 to 17:30 Monday to Friday
excluding Bank Holidays.
2.6 Service Dependencies and Post Office Responsibilities
(A) On request, Post Office shall use reasonable endeavours to supply information to assist in
the capacity management of the Horizon system (e.g. introduction of New Services, data to
help update to this document or the capacity model). Such information should only be
required on an ad-hoc basis and may include, but not be limited to, workload breakdown by
Branch or workload breakdown by product by time.
(B) Post Office shall co-operate with Fujitsu Services in the assessment of future transaction
types and volumes.
© 2002 Fujitsu Services Commercial In Confidence Page: 12 of 35
FUJ00001719
FUJ00001719
Fujitsu Services Horizon Capacity Management and Business Volumes __ Ref: PA/PER/033
Version: 1.0
Commercial In Confidence Date: 31-Dec-2002
© 2002 Fujitsu Services Commercial In Confidence Page: 13 of 35
FUJ00001719
FUJ00001719
Fujitsu Services Horizon Capacity Management and Business Volumes __ Ref: PA/PER/033
Version: 1.0
Commercial In Confidence Date: 31-Dec-2002
3.0 Business Metrics
This section describes the business metrics that the Horizon system will support and is broken
down by service type or functional area. The demand on the infrastructure generated by the
Horizon workload is not uniform and different parts of the system need to handle the volumes
generated over different periods of time. This means that the volumes need to consider
different time periods as shown below:
Month The total business volume in the Sizing storage capacity
busiest month of the year. E.g., correspondence server storage, DRSH storage.
Week The total business volume in the Sizing storage capacity
busiest week of the year. E.g. data warehouse weekly data
Two Days I The total business volume in the Sizing storage capacity
busiest two consecutive days of the E.g. Overnight host processing - the Host must be
year. ci le of storing and processing two days data ifa
jor failure occurs and overnight processing is delayed
bya day
Day The total business volume in the Sizing components that need to support the full day load.
busiest day of the month. . .
E.g. overnight batch processing
Hour The total business volume in the Sizing components that need to keep up during the day
busiest hour of the month. but do not need to support the peak 5 minutes.
E.g. DRSH
5 Minutes I The aggregate business over the Sizing components that need to support on line
peak 5 minute period of the month, I transactions.
expressed as a per second rate E.g. WAN, VPN Servers, Correspondence Servers etc
For each area, the following volumes are given:
e Historical Peak - the peak volumes actually processed by the Horizon Service
Infrastructure. These are either actual values or estimates based on profiles.
e Contracted Volumes - the maximum volumes that Fujitsu Services will contract to
support. Exceeding these volumes will cause given Service Levels to automatically not
apply (see Schedule 15 for details).
e Design Limits - the volumes that the system will support without significant failures.
Exceeding these volumes could cause any Service Level or other obligation not to apply
(see Schedule 15 for details).
In addition, other areas of concern are covered for each service where appropriate.
© 2002 Fujitsu Services Commercial In Confidence Page: 14 of 35
FUJ00001719
FUJ00001719
Fujitsu Services Horizon Capacity Management and Business Volumes __ Ref: PA/PER/033
Version: 1.0
Commercial In Confidence Date: 31-Dec-2002
3.1 EPOSS
There are two parts of EPOSS, the processing of Products and the handling of Settlements.
3.1.1 Products
EPOSS Product volumes have been fairly consistent over 2001 and 2002 and are not
expected to grow significantly in subsequent years. The Contracted Volumes are therefore set
at 5% above the Historical Peak with the Design Limits set at 20% above this.
The Historical Volumes are taken from actual volumes for the Peak Month, Peak Week, Peak
2 Days and Peak Day. For Peak Hour and Peak 5 Minutes the Historical Peak volumes are
calculated from the Peak Day and a known profile.
Hi
Peak Month 100,195,596 105,205,376
Peak Week 33,637,564 35,319,442 42,383,331
Peak 2 Days 14,876,498 15,620,323 18,744,387
Peak Day 8,192,874 8,602,518 10,323,021
Peak Hour 1,171,581 1,230,160 1,476,192
5 Minutes (Per Sec) 328 344 413
The graph below shows the Peak Day each week together with the Contracted Volumes and
Design Limits.
Peak Day Each Week for EPOSS Transactions
12,000,000
10,000,000
8,000,000
a emaePOss
E 6,000,000 Design Limit
. [~~~ Contracted Volume.
i
5
2 4,000,000
2,000,000
Week
© 2002 Fujitsu Services Commercial In Confidence Page: 15 of 35
Fujitsu Services Horizon Capacity Management and Business Volumes
Commercial In Confidence
Ref:
Version:
Date:
FUJ00001719
FUJ00001719
PA/PER/033
1.0
31-Dec-2002
3.1.2 Settlements
Settlement transactions are generated by the Horizon system when the customer session is
settled. They record the payment of cash to the customer or the receipt of cash or cheque by
the Branch.
For Settlements, all volumes are estimated, as historical volumes are not available. The
formula used is that for each Product sold (APS, OBCS or EPOSS) there is 0.6 settlements
are generated (alternatively for each Settlement there are 1.7 Products sold). The Contracted
Volumes are above the Historical Peak as it is assumed the growth in APS transactions
causes an increase in customers
Peak Month ! 119,631,436 3
Peak Week 34,644,173 36,112,618 43,335,142
Peak 2 Days 16,470,811 17,188,486 20,626,183,
Peak Day 9,179,138 9,565,842 11,479,010
Peak Hour 1,658,719 1,730,259 2,076,311
5 Minutes (Per Sec) 509 532 638
The graph below shows the peak day each week together with the Contracted Volumes and
Design Limits.
114,900,000 4
12,000,000
10,900 000
Peak Day Each Week for Settlement Transactions
Number of Transactions
[EE Seitioment
Dosiga Lirit
[Contracted VorumeI
© 2002 Fujitsu Services
Commercial In Confidence
Page: 16 of 35
FUJ00001719
FUJ00001719
Fujitsu Services Horizon Capacity Management and Business Volumes __ Ref: PA/PER/033
Version: 1.0
Commercial In Confidence Date: 31-Dec-2002
3.2 APS
There are two aspects of the APS Service that need to be considered: transaction volumes and
client volumes.
3.2.1 Transactions
APS is a rapidly growing service. Over the last few years, the annual growth has been 10%
per year (compound) and it is assumed that this will continue. This growth excludes the move
of DVLA V11 from an EPOSS Product to an APS one as this was a one-off activity (e.g.
including V11, July 2002 was 18.5% larger than July 2001). . The Contracted Volumes are
set at the expected volumes in March 2005, which is 27% above the Historical Peak. The
Design Limits are set at 20% above the Contracted Volumes.
The Historical Peak volumes are taken from actual volumes for the Peak Month, Peak Week,
Peak 2 Days and Peak Day. For Peak Hour and Peak 5 Minutes the Historical Peak volumes
are calculated from the Peak Day and a known profile.
Peak Month 32,001,334 40,641,694 48,770,033
Peak Week 9,064,479 11,511,888 13,814,266
Peak 2 Days 4,430,096 3,626,222 6,751,466
Peak Day 2,387,065 3,031,573 3,637,887
Peak Hour 441,607 360,841 673,009
5 Minutes (Per Sec) 141 179 215
The graph below shows the peak day each week together with the Contracted Volumes and
Design Limits.
© 2002 Fujitsu Services Commercial In Confidence Page: 17 of 35
FUJ00001719
FUJ00001719
Fujitsu Services Horizon Capacity Management and Business Volumes __ Ref: PA/PER/033
Version: 1.0
Commercial In Confidence Date: 31-Dec-2002
Peak Day Each Week for APS Transactions
4,000,000
3,500,000
3,000,000
Number of Transactions
3.2.2 Clients
The number of clients being supported by APS is also important, as a file needs to be
produced and transferred for each client. There are three client types that need to be
considered:
e Large Clients - those that process more than 5% of the total workload, measured monthly.
These are currently DVLA, BT, Quantum and BBC/TVL. They need special
consideration due to the size of files produced.
e Small Clients - those that process less than 5% of the total workload, measured monthly.
e Girobank Clients - those clients processed by Girobank.
The table below shows the number of clients that can be supported.
Large Clients 4 6 10
Small 22 30 36
Girobank Clients 500 600 720
If these volumes are exceeded, Post Office and Fujitsu Services will look at the cause and see
if the Service Levels or Volumes need to be changed (see schedule 15 for details).
© 2002 Fujitsu Services Commercial In Confidence Page: 18 of 35
FUJ00001719
FUJ00001719
Fujitsu Services Horizon Capacity Management and Business Volumes __ Ref: PA/PER/033
Version: 1.0
Commercial In Confidence Date: 31-Dec-2002
3.3. OBCS
OBCS is expected to decline over 2003 and 2004 as Network Banking replaces it as the way
benefit payments are made. Therefore three sets of numbers are given:
e Volumes with no Network Banking rolled out. For these the Contracted volumes are
therefore set at the Historical Peak with the Design Limits set at 20% above this.
e¢ Volumes with 50% of Network Banking (see section 3.7) rolled out - defined as 20.9M
transactions per month. It is assumed at this point that OBCS is 60% of current volumes.
¢ Volumes with Network Banking (see section 3.7) fully rolled out - defined as 41.8M
transactions per month. It is assumed at this point that OBCS is 5% of current volumes.
During the transition periods, it is assumed that OBCS declines in proportion to Network
Banking Increasing.
The Historical Peak volumes are taken from actual volumes for the Peak Month, Peak Week,
Peak 2 Days and Peak Day. For Peak Hour and Peak 5 Minutes the Historical Peak volumes
are calculated from the Peak Day and a known profile.
3.3.1 With No Network Banking
lume.
Peak Month 58,548,437 58,548,437 70,258,124
Peak Week 15,038,246 15,038,246 18,045,895
Peak 2 Days 8,144,758 8,144,758 9,773,710
Peak Day 4,718,625 4,718,625 5,662,350
Peak Hour 1,151,345 1,151,345 1,381,613
5 Minutes (Per Sec) 380 380 456
The graph below shows the peak day each week together with the Contracted Volumes and
Design Limits.
© 2002 Fujitsu Services Commercial In Confidence Page: 19 of 35
FUJ00001719
FUJ00001719
Fujitsu Services Horizon Capacity Management and Business Volumes __ Ref: PA/PER/033
Version: 1.0
Commercial In Confidence Date: 31-Dec-2002
Peak Day Each Week For OBCS Transactions
6,000,000
5,000,000
4,000,000
3,000,000
acted Volumes.
‘Number of Transactions
2,000,000
41,000,000
3.3.2. With 50% Network Banking Rolled Out
These are the volumes of OBCS that will be supported once Network Banking is 50% rolled
out as defined above
Peak Month 38,548,437 35,129,062 42,154,875
Peak Week 15,038,246 9,022,948 10,827,537
Peak 2 Days 8,144,758 4,886,855 5,864,226
Peak Day 4,718,625 2,831,175 3,397,410
Peak Hour 1,151,345 690,807 828,968
5 Minutes (Per Sec) 380 228 274
3.3.3. With Network Banking Fully Rolled Out
These are the volumes of OBCS that will be supported once Network Banking is fully rolled
out as defined above
Peak Month 58,548,437 7,42: 12,906
Peak Week 15,038,246 751,912 902,295
Peak 2 Days 8,144,758, 407,238 488,685
Peak Day 4,718,625 235,931 283,118
Peak Hour 1,151,345 5 69,081
5 Minutes (Per Sec) 380 23
© 2002 Fujitsu Services Commercial In Confidence Page: 20 of 35
FUJ00001719
FUJ00001719
Fujitsu Services Horizon Capacity Management and Business Volumes __ Ref: PA/PER/033
Version: 1.0
Commercial In Confidence Date: 31-Dec-2002
3.4 LFS
LFS is a low volume service to support stock and cash ordering in the Branches. For this
reason, only the Peak Day numbers are appropriate.
There are a number of different components for LFS. These are covered separately in the
table.
Planned Orders 17,050 20,000 24,000
Advice Notices Not Used 10,000 12,000
Pouch Collection 3,506 10,000 14,000
Pouch Deliver, 6,407 24,000
Cash Declaration 17,313 24,000
Stock Declaration 17,050 24,000
3.5 Message Broadcast
Message Broadcast is a low volume service that allows messages to be sent on behalf of Post
Office to the Branches. For this reason, only the Peak Day numbers are appropriate. In any
given day, there will be a number of messages, each being sent to one or more Branches. The
table below shows the maximum number of “Branch messages” that can be supported (the
same message being sent to N Branches counts as N “Branch messages”).
Branch Messages - 100,000 120,000
3.6 Reference Data
This section covers reference data volumes.
3.6.1 Reference Data Distribution
Reference Data is much more difficult that the other services as the relationship between the
business change and the impact on capacity is complex due to the large number of different
types of changes and the variability in the number of Branches these are targeted at.
For this reason, rather than providing the level of business change that can be supported, the
maximum number of reference data messages (i.e. Riposte messages inserted into the
correspondence servers) that can be distributed each night to the Branches is defined. Fujitsu
Services will continue the current practice of working with Post Office to ensure that the
© 2002 Fujitsu Services Commercial In Confidence Page: 21 of 35
FUJ00001719
FUJ00001719
Fujitsu Services Horizon Capacity Management and Business Volumes __ Ref: PA/PER/033
Version: 1.0
Commercial In Confidence Date: 31-Dec-2002
level of business change does not exceed these values and advise on scheduling of
distribution to the estate.
There are three types of reference data that need to be considered:
e Branch Targeted - this is data targeted at one or more Branches rather than distributed to
the whole estate (either by Tivoli, APS or RDDS). It is either Branch specific (e.g. an
address) or non-core data (e.g. DVLA product which is only sold in the larger Branches).
This volume is the average messages per outlet (e.g. if 170,000 messages are sent to an
estate of 17,000 Branches this would be 10).
¢ Core Replicated - This is data sent to all Branches in the estate via a replication method
(i.e. the data is copied into each Branch separately by a set of agents, having been first
loaded via RDDS, APS or Tivoli into a dummy Branch). Examples include core reference
data and APS tariff data.
e Global - This is data sent to all Branches in the estate without replicating it to each
Branch (i.e. the correspondence servers do it themselves). This is a new method and is
currently only being used for MAILS data.
The Contracted Volumes and Design Limits are shown in the table below. Only Peak Day
volumes are covered, as only the overnight batch is significant.
Branch Targeted - 25 30
(average per Branch)
Core Replicated - 250 300
(per Branch)
Global - 1,000 1,500
(per Branch)
If these volumes are exceeded, Post Office and Fujitsu Services will look at the cause and see
if the Service Levels or Volumes need to be changed (see schedule 15 for details).
3.6.2 Token Definitions
The number of token definitions defined for each service can have an impact on the counter
transaction time for its own and other services. This is because when a card is swiped or a bar
code scanned, the counter code needs to search its list of tokens for a match. The table below
shows the number that can be supported for each service and the impact of increasing this.
(tokens)
. an
APS (tokens) 2000 OBCS, NBS and DC
OBCS (tokens) 20 30 NBS and DC
© 2002 Fujitsu Services Commercial In Confidence Page: 22 of 35
FUJ00001719
FUJ00001719
Fujitsu Services Horizon Capacity Management and Business Volumes __ Ref: PA/PER/033
Version: 1.0
Commercial In Confidence Date: 31-Dec-2002
NBS and DC Combined 1600 2000
(UN Ranges)
If these volumes are exceeded, Post Office and Fujitsu Services will look at the cause and see
if the Service Levels or Volumes need to be changed (see schedule 15 for details).
3.7 Network Banking Service
NBS is a service to provide a service to both:
e Existing benefit customers who will be paid through the NBS rather than OBCS and
e New (non benefit) customers accessing the services provided by the NBS .
The number of benefit customers serviced by Post Office once NBS is in place is predicted to
be lower than the number serviced under OBCS. This is due to some customers choosing not
to collect their benefit from the post office if it is paid directly into their bank accounts.
The load generated on the Fujitsu Services infrastructure by NBS is significantly different to
that of other services due to the high level of online transactions.
The rate of growth of NBS is driven by:
1. The take-up rate of the service by personal banking customers and CAPO™ customers
2. The rate at which CAPO™ cards are to be issued and the number of such cards
3. The replacement rate of benefit payment books by cards.
Post Office Ltd. has predicted the future workload volumes but the process for the
introduction of infrastructure capacity recognises that there are variables in the workload
volumetrics and allows for planned change through the Capacity Management Service.
As agreed with Post Office (see the NBS pricing in Annex D to Schedule 10) capacity is
being installed in two phases for Network Banking:
e Phase 1 - These volumes (sized at 50% of final volumes) are used for all components
from the start of the service.
e Phase 2 - These volumes are used for all components six months after PO Ltd has given
notice that it needs Fujitsu Services to support these volumes, such notice to be given no
earlier than 1“ March 2003.
The expected areas of change at phase 2 include:
e Increased processing power for the correspondence servers and potentially a new version
of WebRiposte to improve connection concurrency handling.
© 2002 Fujitsu Services Commercial In Confidence Page: 23 of 35
Fujitsu Services Horizon Capacity Management and Business Volumes __ Ref:
Version:
Commercial In Confidence Date:
PA/PER/033
1.0
31-Dec-2002
FUJ00001719
FUJ00001719
e Increased processing power for the NBS agents
e Increased storage for the DRS
e Increased processing power for the DRS Host
3.7.1 Phase 1 Transaction Volumes
For Phase I the system will support the volumes below:
Peak Month 20,923,780 25,108,536
Peak Week 5,480,016 6,576,019
Peak 2 Days 2,828,379 3,394,055
Peak Day 1,632,090 1,958,508
Peak Hour 347,488 416,986
5 Minutes (Per Sec) i 133
3.7.2 Phase 2 Transaction Volumes
For Phase 2 the system will support the volumes below:
Te
Peak Month 41,847,560 30,217,072
Peak Week 10,960,032 13,152,039
Peak 2 Days 5,656,759 6,788,111
Peak Day 3,264,181 3,917,017
Peak Hour 694,976 833,971
5 Minutes (Per Sec) 222 267
3.7.3, Routing Gateways
The DRSH has the concept of "Routing Gateways", which are defined by reference data for a
particular IIN/operation combination. These are used to group transactions into separate
reports.
The reconciliation report structure, in agreement with Post Office Ltd, has assumed a
maximum number of routing gateways. The Contracted Volume and Design Limit for this is
30 routing gateways.
If these volumes are exceeded, Post Office and Fujitsu Services will to look at the cause and
see if the Service Levels or Volumes need to be changed (see schedule 15 for details).
Each routing gateway produces up to 11 daily reports and 2 weekly reports from the DRS.
There are also 2 daily reports for covering all gateways.With 30 gateways in operation the
table below shows the maximum number of reports:
© 2002 Fujitsu Services Commercial In Confidence
Page: 24 of 35
FUJ00001719
FUJ00001719
Fujitsu Services Horizon Capacity Management and Business Volumes __ Ref: PA/PER/033
Version: 1.0
Commercial In Confidence Date: 31-Dec-2002
Normal Weekday (not Monday) I 332
Monday (not Bank Holiday) 1056
Tuesday after BH. Monday 1388
Tuesday after Easter 1720
3.8 Debit Card
Debit Card is a new addition to the Horizon system so that a customer in addition to paying
by cash or cheque could now do so by Card.
It is predicted that the customer behaviour that determines the distribution of DC payments
over the day will be similar to that for EPOSS transactions. The key difference between DC
and other services is that Saturdays are expected to be busier than weekdays.
The predicted Saturday peak results from a series of variable events occurring on the same
day e.g.:
¢ Month end resulting in a significant increase in MVL payments and
e Large utility companies issuing quarterly bills
The system will support the volumes below:
Peak Month 210,000 5,052,000
Peak Week 1,264,768 1,517,721
Peak 2 Days 565,949 679,139
Peak Day 288,425 346,110
Peak Hour 79,368 95,242
5 Minutes (Per Sec) 22 26
3.9 Online Transactions
3.9.1 Introduction
Online Transactions need to be considered as a generic transaction type in addition to the
individual services that make them up. This is because Online Transactions cause load on the
central systems and the Branch to data centre network. These two areas are covered
separately.
There are three services that generate Online Transactions:
1. OBCS Foreigns (OBCS transactions taking place at a Branch which the customer has not
previously visited) - this is expected to decline as Network Banking rolls out
© 2002 Fujitsu Services Commercial In Confidence Page: 25 of 35
FUJ00001719
FUJ00001719
Fujitsu Services Horizon Capacity Management and Business Volumes __ Ref: PA/PER/033
Version: 1.0
Commercial In Confidence Date: 31-Dec-2002
2. Network Banking Service
3. Debit Card
3.9.2 Central Systems
These volumes are used to size components that process and store Online Transactions in a
common way in the central systems (e.g. Correspondence servers). The Branch to data centre
network is explicitly excluded from this subsection and is covered separately.
As with the Network Banking Service, the capacity is split into two phases.
Note that the volumes in this section do not necessarily match the sum of the Debit Card and
Network Banking volumes from previous sections. This is because the peaks from NBS and
DC are expected to happen at different times.
3.9.2.1 Phase 1
For Phase I the system will support the volumes below:
Peak Month
Peak Week 6,247,744 7,497,293
Peak 2 Days 3,184,657 3,821,588
Peak Day 1,818,771 2,182,525
Peak Hour 379,436
5 Minutes (Per Sec) 120
3.9.2.2 Phase 2
For Phase 2 the system will support the volumes below:
Peak Month 46,101,471 55,321,766
Peak Week 12,236,079 14,683,294
Peak 2 Days 6,228,817 7,474,580
Peak Day 3,556,145 4,267,374
Peak Hour 739,012 886,814
5 Minutes (Per Sec) 234 281
3.9.3, Branch to Data Centre Network
As NBS and DC roll out, the capacity of the network will be increased to meet the growth in
demand. This is achieved by moving more Branches onto fixed connections. The factor that
forces this behaviour is that there is a limit to the rate of ISDN calls being established (the
“call attack rate”) that the network can support. Hence the need to ensure that the workload
generated by the Branches that dial on demand is less than the call attack rate that the
network can support.
Since fixed connections are more expensive than dial on demand ones, there is a straight
trade off between the network capacity and the network cost.
© 2002 Fujitsu Services Commercial In Confidence Page: 26 of 35
FUJ00001719
FUJ00001719
Fujitsu Services Horizon Capacity Management and Business Volumes __ Ref: PA/PER/033
Version: 1.0
Commercial In Confidence Date: 31-Dec-2002
This section has changed significantly from [NewBusVols] to reflect the change in network
charges from variable charges to fixed charges as set out in Schedule 10. Rather than provide
tules on how the network capacity will be jointly managed (as in [NewBusVols]), the peak
volume of Online Transactions that will be supported in each month by the capacity which
equates to the Schedule 10 charges is now stated in the second table below. Post Office can
increase that capacity by paying upgrade charges as set out in Schedule 10.
Each month has 4 different time periods (shown in the first table below) reflecting the three
periods in [NewBusVols] plus the use of “Silver Part Time connections”. The volumes for
Period 1 are taken from [AllocProcess]. As with the key network numbers in [NewBusVols],
there is no difference between the Contracted Volumes and Design Limits.
The network is able to support different capacities at different times of the day or day of
week. There are 4 time periods for online transactions as defined by the table belo
Mon 08:30 to 10:30 - 00:00 to 08:00
: :30_I & 17:30 to 23:59
Tue 08:30 to 09:30 09:30 to 10:30 08:00 to 08:30 00:00 to 08:00
& 10:30 to 17:30_I_& 17:30 to 23:59
Wed - 08:30 to 10:30 08:00 to 08:30 00:00 to 08:00
& 10:30 t0 17:30_I & 17:30 to 23:59
Thu 08:30 to 09:30 09:30 to 10:30 08:00 to 08:30 00:00 to 08:00
& 10:30 t0 17:30_I_& 17:30 to 23:59
Fri - 08:30 to 10:30 08:00 to 08:30 00:00 to 08:00
& 10:30 t0 17:30_I & 17:30 to 23:59
Sat : 08:30 to 10:30 08:00 to 08:30 00:00 to 08:00
& 10:30 to 13:00_I_& 13:00 to 23:59
Sun : : 00:00 to 23:59.
The network capacity will be increased over time to support the assumed increase in Online
Transaction volumes. The table below gives the Peak 5 minute Contracted Volumes for
Online Transactions expressed in transactions per second:
Jan-0: 25 16 12 5
Feb-03 50 33 24 5
Mar-03 30 33 24 3
Apr-03 50 33 24 5
May-03 50 33 24 5
Jun-03 50 33 24 5
Jul-03 53 35 26 5
Aug-03 76 49 36 5
Sep-03 87 57 42 5
Oct-03 105 68 51 5
Nov-03 118 77 57 5
Dec-03 130 84 62 3
Jan-04 152 99 73 5
Feb-04 162 105 78 5
Mar-04 172 12 83 3
Apr-04 182 11s 87 5
© 2002 Fujitsu Services Commercial In Confidence Page: 27 of 35
Fujitsu Services Horizon Capacity Management and Business Volumes __ Ref: PA/PER/033
Version: 1.0
FUJ00001719
FUJ00001719
Commercial In Confidence Date: 31-Dec-2002
May-04 122 91 5
Jun-04 128 95 3
Jul-04 134 99 35
Aug-04 136 101 3
Sep-04 141 104 5
Oct-04 146 108 5
Nov-04 148 110 35
Dec-04 Isl 112 3
Jan-05 152 112 5
Feb-05 154 114 5
Mar-05 154 ll4 3
After 154 14 5
Mar-05
The Design Limits for Online Transactions are the same as the Contracted Volumes.
The ADSL branch network shall support at least the volumes defined in the table above.
In calculating the numbers in the table above, the following method has been used:
Period Method
1 During this period the online transaction volumes are supported by Dialled Connections and
daytime silver and part-time silver Branches.
The peak second volumes by month are as approved by Post Office in I AllocProcess]. The
working behind these numbers is included in section 5.
v
During this period the online transaction volumes are supported by Dialled Connections and
daytime silver Branches, but not part-time silver Branches.
These values are 65% of Period 1. This equates to the impact of removing 1200 part time silver
Branches.
This impact is illustrated in [ AllocSheet] which shows that 11,400 silver Branches are needed to
support the peak March 2005 volumes, whereas 10,200 silver Branches can only support the
January 2004 volumes. The ratio of these two volumes is 152/236=65%, this being the factor used
to calculate the Period 2 volumes
we
During this period the online transaction volumes are supported by Dialled Connections and
daytime silver Branches, but not part-time silver Branches. However fewer online transactions can
be supported than Period 2, as there are regular Riposte synchronisations that also need to take
place.
In [NewBusVols] this difference was allowed for by having two different dial rates during the day:
* “5 Minute Dialled Transaction Rate - Period I (per second)” of 13.5 transactions per second
e “5 Minute Dialled Transaction Rate - Period 2 (per second)” of 10 transactions per second
This same ratio (i.e. 10/13.5 = 74%) has been applied to the Period 2 volumes to calculate the
volumes in Period 3.
© 2002 Fujitsu Services Commercial In Confidence Page: 28 of 35
FUJ00001719
FUJ00001719
Fujitsu Services Horizon Capacity Management and Business Volumes __ Ref: PA/PER/033
Version: 1.0
Commercial In Confidence Date: 31-Dec-2002
4 This period equates to the “S Minute Dialled Transaction Rate - Period 3 (per second)” in
[NewBusVols]. Since there are no silver branches during this period, the rate of 5 transactions per
second is used.
3.10 Post Offices
The number of Post Office Branches and counters is shown in the following table. This is
provided for information only and represents the current forecast - the contractual baseline is
given in Schedule 10. At this version of the document the two sets of numbers are the same.
Jan-03
Feb-03 40,077
Mar-03 40,028
‘Apr-03 39,978
May-03 39,929
Jun-03 39,819
Jul-03 39,709
Aug-03 16,949 39,599
Sep-03 16,867 39,489
Oct-03 16,786 39,380
Nov-03 16,704 39,270
Dec-03 16,623 39,160
Jan-04 16,541 39,050
Feb-04 16,459 38,940
Mar-04 16,378 38,896
Apr-04 16,296 38,852
May-04 16,214 38,808
Jun-04 16,133 38,764
Jul-04 16,051 38,720
Aug-04 15,970 38,676
Sep-04 15,888 38,632
Oct-04 15,806 38,589
Nov-04 15,725 38,545
Dec-04 15,643 38,501
Jan-05 15,562 38,457
Feb-05 15,480 38,413
Mar-05 15,398 38,369
Apr-05 317 38,325
May-05
Jun-05 15,154 38,237
Jul-05 15,072 38,193
Aug-05 14,990 38,149
Sep-05 14,909 38,105
Oct-05 14,827 38,061
Nov-05 14,745 38,017
Dec-05 14,664 37,973
Jan-06 14,582 37,929
© 2002 Fujitsu Services Commercial In Confidence Page: 29 of 35
Fujitsu Services Horizon Capacity Management and Business Volumes
Commercial In Confidence
Ref:
Version:
Date:
PA/PER/033
1.0
31-Dec-2002
FUJ00001719
FUJ00001719
Feb-06 14,501 37,885
Mar-06 14,419 37,841
Apr-06 14,337 37,797
May-06 14,256 37,753
Tun-06 14,174 37,709
Jul-06 14,093 37,665
Aug-06 14,011 37,621
Sep-06 13,929 37,577
Oct-06 13,848 37,533
Nov-06 13,766 37,490
Dec-06 13,684 37,446
Jan-07 13,603 37,402
Feb-07 13,521 37,358
Mar-07 505 37,350
Apr-07 37,343
May-07 37,336
Jun-07 37,329
Jul-07 37,322
Aug-07 37,315
Sep-07
Oct-07
Nov-07
Dec-07
Jan-08 37,279
Feb-08 37,271
Mar-08 13,305 37,264
Apr-08 13,289 37,257
May-08 37,250
Tun-08 37,243
Jul-08 37,236
Aug-08
Sep-08
Oct-08
Nov-08 37,207
Dec-08 37,200
Jan-09 37,192
Feb-09 37,185
Mar-09 37,178
Apr-09 37,171
May-09. 37,164
Jun-09 37,157
Jul-09 37,149
Aug-09 3,023 37,142
Sep-09 13,007 37,135
Oct-09 12,990 37,128
Nov-09 12,974 37,121
Dec-09 12,957 37,114
Jan-10 12,940 37,106
Feb-10 12,924 37,099
Mar-10 12,907 37,092
© 2002 Fujitsu Services
Commercial In Confidence
Page: 30 of 35
FUJ00001719
FUJ00001719
Fujitsu Services Horizon Capacity Management and Business Volumes __ Ref: PA/PER/033
Version: 1.0
Commercial In Confidence Date: 31-Dec-2002
4.0 Capacity Model Summary
This section provides a summary of the capacity model. It only covers the critical
components and more detail can be found in the model.
The model itself is quite complex, as each part of the infrastructure needs to be considered in
turn and each component has several aspects to capacity (e.g. processor usage, memory usage
or disk storage). The first version only covers the critical systems and will be extended as
required. The consequences of errors in the model or the assumptions are given in section 1.4.
4.1 Assumptions
The key assumptions used by the model are given below by type.
Workload / Business Processes:
e APS Smart Card Transactions (e.g. Quantum) account for 10% of all APS Transactions
(from historic data)
e A receipt is printed for 5% of Settlements.
e 2 Receipts are printed for all APS transactions (one office and one customer copy).
e 1 Receipt is printed for all NBS Transactions (one customer only - no office copy). It is
assumed the number of Non-PIN based transactions (which require two receipts) is
negligible.
e 2 Receipts are printed for all DC Transactions (one office and one customer copy).
© Only serve customer transactions occur during the peak 5 minutes of the week (i.e. during
the peak 5 minutes there are no logon/logoff and no back office functions such as LFS
pouch receipt, cash accounts, other reports etc).
e The peak 5 minutes of the different serve customer transactions happen at the same time.
Computer System:
e The workload is split into 4 Riposte clusters, which are not perfectly balanced. The
busiest cluster handles 28% of the total workload.
e The average Riposte message size is 510 bytes excluding network overheads.
e No more than 3 Riposte subscription groups are used.
Data Retention Summary (these values are defined elsewhere in the contract or other
documents, but are included for completeness):
e Riposte messages are kept for 35 days within the correspondence servers.
e DRS data is kept online for 90 days
e Audit data is kept for 7 years
© 2002 Fujitsu Services Commercial In Confidence Page: 31 of 35
FUJ00001719
FUJ00001719
Fujitsu Services Horizon Capacity Management and Business Volumes __ Ref: PA/PER/033
Version: 1.0
Commercial In Confidence Date: 31-Dec-2002
4.2 Day Online Load
The load on the system during the day is dominated by handling the peak 5-minute workload.
Each business transaction is converted into one or more Riposte messages as shown by the
table below. The number of transactions produced for three scenarios is also given:
e BIJ3 - This is immediately after BI3 has gone live, but before Network Banking has started
to be used. At this point the infrastructure has to handle 6,500 concurrent Branch
connections.
e NBS Phase I - This is once the full NBS Phase 1 volumes are being supported. At this
point the infrastructure has to handle 10,500 concurrent Branch connections.
e NBS Phase 2 - This is once the full NBS Phase 2 volumes are being supported. At this
point the infrastructure has to handle 12,500 concurrent Branch connections.
Service EPOSS APS OBCS NBS. DC Settlement Total
Riposte Messages per Txn 1 72 i 7 9 tl =
BI3 Transactions 344 179 380, 0 0 532 1,436
NBS Phase I Transactions 344 179 228 ul 22 3. 1,417
NBS Phase 2 Transactions 344 179 19 222 22 532 1,319
BI3 Messages 344 1,292 380 0 0 585 2,602
NBS Phase 1 Messages 344 1,292 228 777 198 585 3,425
NBS Phase 2 Messages 344 1,292 19 1,554 198 585 3,993
As can be seen, although the number of transactions being handled reduces by about 9%
(from BI3 to NBS Phase 2), the number of messages being processed increases by 53%. This
is because transactions are being switched from OBCS that has only a single message per
transaction to NBS, which has 7.
There are a number of infrastructure components that support this message load in a common.
way (i.e. they don’t differentiate between the transaction types). For these components
(providing the assumptions above are not violated) the mix of business transactions can be
changed and the ability of the components to handle the message workload is not altered.
If the number of concurrent Branch connections to the data centres remained constant, the
infrastructures’ utilisation would increase linearly as the message load increased. However as
the Online Transaction workload increases, the number of concurrent Branch connections
also has to increase. This reduces the ability of the infrastructure components to support the
message load, as they also have to handle the concurrent connections.
© 2002 Fujitsu Services Commercial In Confidence Page: 32 of 35
FUJ00001719
FUJ00001719
Fujitsu Services Horizon Capacity Management and Business Volumes __ Ref: PA/PER/033
Version: 1.0
Commercial In Confidence Date: 31-Dec-2002
The table below summarises the ability of these components to handle the workload for the
three scenarios. The impact of the Branch concurrency can be seen by the reduction in the
capability of the components. The utilisation shown is the percentage of the maximum safe
utilisation that is used (i.e. it is safe to have a 100% utilisation.
Note the numbers assume that the changes required to support Network Banking Phase 2
have not taken place - hence the utilisation on the Branch to Data Centre Network Bandwidth
(the bandwidth usage between Energis and the Bootle and Wigan data centres). Once Post
Office has requested that NBS Phase 2 is supported, this table will be updated.
BIB NBS Phase 1 NBS Phase 2
Component Capability Utilisation Capability Utilisation Capability I Utilisation
(Msgs/s) (Msgs/s) (Mses/s)
Correspondence 5,410 48% 4,750 72% 4,420 90%
Servers
VPN Servers, 12,429 21% 7,485 46% 4,780. 84%
Branch to Data 7,728 34% 3,976 86% 1,461 273%
Centre Network
Bandwidth
Data Centre 13,202 20% 12,043 28% 11,352 35%
LAN Segment
Bandwidth
Data Centre 189,053 1% 187,405 2% 186,485 2%
LAN Switch
Bandwidth
4.3 Overnight Batch
The main capacity issue for the overnight batch processing is whether there is sufficient time
to complete all of the batch jobs in the available time period. However this doesn’t tell the
whole story, as the resource usage during the operation needs to be considered - a low
utilisation suggests that spare capacity should be available during part of the overnight run for
new jobs.
The table below summarises the overnight operation for the three scenarios above. The NBS
Phase 2 figures assume that the NBS Phase 2 host upgrade has not taken place. Once Post
Office has requested that NBS Phase 2 is supported, this table will be updated.
Area BI3_I _NBS Phase I NBS Phase 2
Overnight Duration (Hours) 10.1 19 17.9
Overnight Utilisation (Hours) 89% 93% 86%
Overnight Completes 16min Early I 06 minEarly I 355 min Late
The ability to deliver files to TIP, OBCS and AP Clients in the early evening also has to be
considered. This is covered in more detail in the model.
© 2002 Fujitsu Services Commercial In Confidence Page: 33 of 35
FUJ00001719
FUJ00001719
Fujitsu Services Horizon Capacity Management and Business Volumes __ Ref: PA/PER/033
Version: 1.0
Commercial In Confidence Date: 31-Dec-2002
4.4 Storage
There are a number of applications that require storage to hold their data and each application
is given its own area of physical disk to hold this data. They may in reality be in a separate
storage system from other applications (e.g. the support file server uses a separate storage
system from Riposte or Audit) or be in a shared storage system used by several applications
(e.g. The Host Databases, MIDTID and KMA all share a single EMC array). Even when a
shared storage system is used, it is extremely difficult to move physical storage from one
application to another.
Therefore practically, each application has to be given enough storage to support its full
volumes, even if those volumes reduce over time, while another application’s usage is rising.
Also it is generally more cost effective to allocate the maximum storage required by an
application from day 1, rather than adding storage as the application grows (the cost of
change is often more than the cost of the storage).
Within an application, storage may be broken into multiple areas. For example TPS has
separate areas for the database and file storage, with the database itself broken into indexes,
permanent data and temporary data. The layout of the data itself is also generally optimised to
the performance requirements of the application.
One final problem is that the average size of a data item (e.g. NBS transaction) is not well
understood until an application has been live for some time. Even then, changes to customer
behaviour (e.g. buying a different mixture of products) can cause changes to the average data
size, without increasing the workload volumes.
For all these reasons, the storage areas are sized to support the full application requirements
with sufficient contingency to allow for some unexpected growth in data or indexes sizes. It
is therefore difficult at any point in time to state how much headroom there is in the sizing.
In summary therefore, the storage system is assumed to be 100% utilised. When Post Office
wishes to increase volumes, the current storage of the applications will then be resized to see
if the increase can be accommodated without having to purchase additional capacity.
© 2002 Fujitsu Services Commercial In Confidence Page: 34 of 35
FUJ00001719
FUJ00001719
Fujitsu Services Horizon Capacity Management and Business Volumes __ Ref: PA/PER/033
Version: 1.0
Commercial In Confidence Date: 31-Dec-2002
5.0 Volume Justification
This section provides background information to justify some of the volumes in the previous
sections
This section has no contractual significance.
5.1. Online Transaction Rollout
The table below provides the estimated peak transactions per second rate for OBCS Foreigns,
NBS and DC (see [AllocProcess]).
The following assumptions were made in calculating the values for OBCS Foreigns:
e OBCS Foreigns are 1.5% of all OBCS transactions.
e OBCS Transactions peak at 350 transactions per second.
¢ OBCS declines as NBS increases from April 2003.
© Once NBS is fully rolled out there are still 5% OBCS left.
Month % of Final Workload Active Peak Transactions Per Second
OBCS NBS DCS OBCS Foreigns NBS DC Total
Jan-03 100.00% 0.47% 0.00% 5.3 1 0 6
Feb-03 100.00% 0.93% 0.00% 53 2 0 7
Mar-03 100.00% 187% 0.00% 5.3 4 0 9
Apr-03 96.45% 3.74% 4.55% 5.1 8 1 14
May-03 91.12% 9.35% 9.09% 48 20 2 27
Jun-03 86.24% 14.49% 13.64% 45 31 3 39
Jul-03 80.02% 21.03% 18.18% 42 45 4 53
Aug-03 70.26% 31.31% 22.73% 3.7, 67 5 76
Sep-03 65.37% 36.45% 27.27% 3.4 78 6 87
Oct-03 57.83% 44.39% 31.82% 3.0 95 7 105
Nov-03 52.94% 49.53% 40.91% 2.8 106 9 8
Dec-03 48.50% 54.21% 50.00% 2.5 6 u 130
Jan-04 39.18% 64.02% 59.09% 2.1 137 13 152
Feb-04 35.19% 68.22% 63.64% L8 146 14 162
Mar-04 31.64% 71.96% 72.73% LT 154 16 172
Apr-04 27.64% 76.17% 71.27% LS 163 17 182
May-04 24.98% 78.97% 81.82% 13 169 18 188
Jun-04 21.43% 82.71% 86.36% Ld 177 19 197
Jul-04 17.87% 86.45% 90.91% 0.9 185 20 206
Aug-04 16.10% 88.32% 90.91% 08 189 20 210
Sep-04 13.43% 91.12% 95.45% 0.7 195 21 217
Oct-04 9.88% 94.86% 95.45% 0.5 203 21 225
Nov-04 8.55% 96.26% 100.00% 0.4 206 22 228
Dec-04 6.78% 98.13% 100.00% 0.4 210 22 232
Jan-05 6.33% 98.60% 100.00% 03 21 22 233
Feb-05 5.00% 100.00% 100.00% 0.3 214 22 236
Mar-05 5.00% 100.00% 100.00% 0.3 214 22 236
© 2002 Fujitsu Services Commercial In Confidence Page: 35 of 35