FUJ00079089
FUJ00079089
ICL Pathway Memorandum
To: Bob Booth
cc: John Dicks
From: Dave Cooke
Date: 02/12/1998
Re: POCL Infrastructure Acceptance Specification
Bob,
Thank you for the meeting of 24" November and your follow up meeting notes
and actions. I can confirm that the action points agree with my notes.
The status of the POCL Infrastructure Acceptance Spec is now as follows: -
1. All your category 4 comments were discussed at our review. No changes to
the AS were required.
2. All the actions relating to your category 3 comments have been applied to the
AS. Some points of clarification :-
a) Action13 / Criterion 472/3 - The Audit Acceptance specification is
already cited as the reference document.
Action 17 / Criterion 478/3 - I have added "FTMS Configurations for
Pathway TPS and POCL TIP links at Release 2" rather then the
generic TIS as this document gives a precise definition of the
TMS/TPS to TIP interface.
2
a) Action 29 / Criterion 953/2 - I hope to advise an appropriate test
tomorrow.
a) Action 30 / Section 7 - This information will be included in the Low
Level Test Scripts and will be separately supplied.
Action 31 / Section 10 - This section would normally contain an extract
from the High Level Test Plans that link the Business Thread / HLTP
references to the individual test conditions. However in the case of
these technical tests the references given in each criterion are the
2
FUJ00079089
FUJ00079089
July 13, 1999
actual test conditions. This section is not required for this AS.
3. All of your category 2 issues have been addressed as follows :-
a) Action 5 & 6/ Criterion 476/2 & 3 - I believe adherence to the Release
Authorisation Processes will satisfy these criterion. For Release 2
these are described in the Horizon document " Release Authorisation
of the NR2 (Child Benefit) Release". Part of this process requires the
ICL Pathway Customer Services Director to confirm that the testing
activities and release preparation activities have been completed
Action 7 / Criterion 478/8 - I have added this criterion to the Review
section with the referenced document "FTMS Resilience and Recovery
Strategy for Release 2". This describes the automatic retry
mechanisms. I have also added some additional tests to demonstrate
the use of the "Compaq Recovery Option" which shows the automatic
cut-over between the primary and secondary file transfer PC.
2
a) Action 8 / Criterion 480/2 - I can advise you that version 2 of the BPS
Agents document contains very detailed information on data items
transferred between TMS / PAS and TMS / CMS. Please note that the
document reference is now BS/DES/001.
4. Concerning your category 1 issues: -
a) Action1 - Technical vs Business.
You advise that concern has been expressed at the predominantly technical
nature of the tests, which do not take account of the business implications of the
various failure conditions that are tested. This is quite intentional and is indeed
necessary since the Contract specifically separates POCL Infrastructure into its
own set of contract schedules (POCL Agreement Schedule G01 etc.) as distinct
from the business oriented Services of APS, EPOSS etc. The Service Definition
for POCL Infrastructure essentially requires that an infrastructure is created
which exhibits a set of Service Qualities (e.g. security, integrity, performance
etc.) sufficient to meet the needs of the business functions required by APS,
BES, EPOSS etc.
It is these basic Service Qualities that are tested within the POCL Infrastructure
Acceptance Specification as required by the various criteria. However the
business impacts of a failure, and in particular the recovery processes and
associated Service Levels can only be considered within a particular business
context. Where appropriate these will be included in other Acceptance
Specifications (e.g. correct use of Help Desk procedures for BES, fall back
processing for APS etc.).
On the particular comment against 472/2 the original comment could have been
phrased as "Each Service will have its own set of requirements or procedures for
dealing with the consequences of infrastructure failure ..... "
FUJ00079089
FUJ00079089
July 13, 1999
ICL Pathway does not consider it appropriate to allow an external verification of
application design against infrastructure capability since this is completely within
ICL Pathway's Service and Risk boundaries.
Measurement of ICL Pathway's ability to deliver the required Services will be the
various service levels. There will of course be regular reviews to address and
control the on-going management and operation of the services via the Horizon
Service Review Forum.
a) Action 2 - TMS / OPS Boundary
ICL Pathway contends that the architectural and service boundary is between the
counter applications, desktop and physical counter peripheral environment, and
the middleware used to support data transfer from these environments to POCL
and POCL Clients. This approach provides a clean separation of functionality
and enables an OPS/TMS API to be defined.
This position is supported by the Service Definition for POCL Infrastructure
(POCL Agreement G01) which provides a clear statement on the scope and role
of TMS.
3.2 Overview
3.2.1 The TMS shall provide the interworking between the Outlets and
the CONTRACTOR's central processing sites. TMS shall be
provided using both the Outlet and the correspondence server
Equipment, presenting interfaces to POCL Client systems or
POCL systems. Such interfaces shall be implemented using
TMS Agents, which are specified in paragraph 3.4.1. [4.1.4.2.1]
3.2.2 The role of TMS shall be to provide a secure and resilient
messaging and journalling service which shall support the
transfer of data between OPS and POCL Client services, and
the POCL Services. [4.1.4.2.1]
4.2.2.2 Once a Transaction has been completed at a Counter Position,
TMS shall commit the full Transaction details to that Counter
Position PC’s message store. The Transaction details shall
simultaneously be automatically replicated to all other PCs in the
Outlet so that the data are securely captured. In addition, the
CONTRACTOR shall automatically replicate Transaction details to
a remote server at which TMS is provided. [S467]
As you know additional Acceptance Criteria can be drawn from Contract
Schedules and I can include some / all of the above paragraphs if you wish.
I believe that the above obligations support the position taken by ICL Pathway
FUJ00079089
FUJ00079089
July 13, 1999
and the statements made in the SADD. In keeping with a number of other parts
of the overall contract there is an administrative task to harmonise text to remove
any ambiguities.
a) Action 3/ Criterion 478/11
When considering this criterion, I think it is important to address it in the context
of the entire Requirement 478, rather than in this abbreviated form. R478
requires that TMS can support two forms of data transfer, Files and Messages.
When originally written I am sure you would agree that the term "Message" was
not intended to mean the form of Riposte message now used in the ICL Pathway
solution. The meaning of Data File and Message are as defined in POCL
Agreement Schedule A01 - Interpretations. The ICL Pathway Solution
recognised these two forms and the different business contexts where they would
be used.
In particular sections 5.1 and 5.2 of the ICL Pathway Solution (POCL Agreement
A16 - Solutions) speculated on the potential use of a Messaging service between
an outlet and a Client and how it might be managed. As you will know none of
the Services at Release 2 have a requirement for such a service
In addition since Requirement 471, which concerns the provision of a Messaging
facility within OPS has been moved to Later Acceptance, I propose that Criterion
478/9, 10, 11 (which call for support for such facilities within TMS) should also be
moved to Later Acceptance.
a) Action 4 / Criterion 478/14
As you speculate within your comment sheet, issues concerning the capacity and
timeliness of events within the infrastructure are within the ICL Pathway Service
and Risk boundary. The criterion calls for the qualities of security,
completeness, accuracy and robustness to be demonstrated and the declared
tests will do that.
On the issues you raise in your comment sheet: -
Overloading
POCL and BA have declared that the Workload Brief or later issues of the
Workload Compendium have no contractual status and so we have no basis to
determine what levels of "overload" might be suitable. Part of the risk that ICL
Pathway has accepted is to make a judgement on what this might be.
Re-Tries
In terms of re-tries, this only has relevance within a particular business context,
as discussed above in 4(a). The operation of the infrastructure is the
FUJ00079089
FUJ00079089
July 13, 1999
responsibility of ICL Pathway and a combination of automatic re-try facilities and
manual intervention procedures will be used.
Links to Host Agents
A number of Harvester and Loader Agents will be used during the running of
these tests.
Links to SMS
Although strictly speaking the information passed to SMS is neither a Data File
nor a Message, I have added the tests EV01 to EV07 which concern the
resilience testing of the loss of connection between the Tivoli Agent and Tivoli
management system.
I trust that these changes are satisfactory and that we can now move to approval
of the Acceptance Specification which is now at version 1.5.
Please contact me if you need to discuss any of the issues covered above.
Regards,
Dave Cooke