4
4
POL00028359
POL00028359
13 AUG 1999 -<a\
Electronic memo
To john.dické i
cc Bob Booth/ITS/POSG/POSTOFFICE@POSTOFFICE, John
Meagher/POCL/POSTOFFICE@POSTOFFICE, Keith K
Baines/POCL/POSTOFFICE@POSTOFFICE
Hard Copy To
Hard Copy cc
From John G Cook/POCL/POSTOFFICE
Date 13/08/99 12:53
Subject AI314
John,
1 undertook to respond more fully on you latest analysis of AI314. Please find attached a paper
describing this.
Please let me know if you want me to be involved in developing a rectification plan (as it seems
unlikely we will be able to develop and agree a comprehensive document set in the timescales,
even if we agreed on what was required).
John Cook
1st Floor, 20-23 Greville Street, LONDON. EC1N 8SS.
STD Phoni _4 Fax: 0171 400 4955
AI314 summary.do
I
POL00028359
POL00028359
Horizon Programme - Contract Team
AI 314 - THIRD PARTY PROCUREMENTS
Author: John Cook Version: 1.0
Date: 13 August 1999
1. INTRODUCTION
11. AI314 has been an open incident since 15 June 1999. In the most recent
2.1.
2.2,
2.3.
3.
3.1.
3.2.
acceptance workshops it has been discussed in some detail with Pathway.
This paper confirms that POCL continue to consider that this incident is not
resolved and that it should be assigned a medium severity level.
REASON FOR MEDIUM CATEGORISATION
AI314 relates to the requirement on Pathway to provide technical
documentation suitable to allow POCL to procure applications from third
parties. Without such documentation, and if it were not maintained, POCL
would be forced to involve Pathway at the earliest stages of any new
development that may operate on Horizon - even a development that was
intended to be produced by the Post Office in-house resource.
Even if Pathway co-operated fully on each occasion, this would introduce a
delay in any development cycle, and would give Pathway an early view (and
therefore a commercial advantage) of everything POCL are considering. In
the papers that Pathway have produced in seeking to resolve this incident,
they suggest that some documents that third parties may require are in fact
internal to Pathway and that 3" party access to them would be carried out by
Pathway personnel under the control of a Non-Disclosure Agreement.
‘Third parties may feel that they would never be able to bid with confidence
against Pathway and hence Pathway would become the de facto provider of
all Horizon services. Hence it is argued that POCL’s commercial freedoms in
developing its business would be constrained.
ACCEPTANCE CRITERIA
‘The acceptance criteria that POCL seek to test against are those derived from
requirements 469 and 470. In addition, it was agreed that in order to close
AI199, relating to the boundary between OPS and TMS, POCL required that
the documentation aspects of that incident (covered by acceptance criterion
869/5) should be added into AI314.
In their latest analysis of the incident, Pathway include the statement that all
these criteria cannot be considered under AI314 as they have provided
documentation. However the dispute is about the status of the documents
they have been provided, and whether they are fit for the required purpose.
AI314
Page 1 of 5
POL00028359
POL00028359
4.1.2.
4.1.4.
PATHWAY’S REBUTTAL POINTS
Document provision
Existing documents
Pathway’s basic argument is that they have already provided a document set,
supported by a draft policy document. Pathway have cited their response to
requirements 469 and 470 that they would provide the following documents:
(a) OPS Architecture Document
(b) OPS API Document
(c) Counter Hardware Design Specification
(d) TMS Architecture Document
(e-) TMS API Document
(f) TMS Hardware Specification
In fact we only hold copies of documents (a), (c) and (d) above, and only (c)
has been formally provided as a contract controlled document. Indeed
document (d) is marked as “Company in Confidence”. Documents (b) and (e)
have been made available to be viewed, but POCL have not been given
copies. The extent to which POCL can use these documents for 3" party
procurements is therefore entirely constrained by Pathway.
Furthermore, the opening of document (d) includes statements such as:
. “The development of ICL products and services is continuous and
published information may not be up to date. It is important to check
the current position with ICL. This document is not part of a contract or
license save insofar as may be expressly agreed.”
. “These documents do not attempt to fully document the Horizon
solution”
. “These documents are not specific to a particular release of Horizon”
It is clear that these documents are not sufficient for some-one to develop an
application that integrates with Horizon, and that there is a danger of them
becoming out of step as Horizon develops,
In their analysis of the Al, Pathway have cited the Asset Register as fulfilling
the purpose of document (f). Again this document is not yet fully agreed (it
was only provided in late July 1999) and is at a different level to document
(c) for example - it is not a specification, merely an Asset Register.
AI314
Page 2 of 5
POL00028359
POL00028359
4.1.6.
5.
5.1.
5.2.
6.
6.1.
Policy document
The policy document (ICL Pathway External Applications Procurement
Policy) has been commented on separately, but is still in draft and Pathway
have agreed to amend it to take on board some of POCL’s comments.
However the overall concern is that it assumes the active participation of
Pathway from the earliest stages in any new development, and therefore
would make a fair competition very difficult to achieve.
Further documentation
Pathway have pointed out that the document set for any specific development
will almost always require other documentation depending on the nature of
the application. POCL accepts that other documentation may be needed, but
do not feel that what has been provided is fit for the purpose stated in the
requirements. We have already suggested that Pathway could at least provide
a document structure, a quality plan for each document and timescale for the
production of the full set.
In discussion we cited examples of other information we would expect a third
party to require to develop an application. Pathway in part asserted that the
information we seek is part of EPOSS and therefore beyond the scope of the
requirements. The fallacy here is that the requirements were written before
the supplier’s architecture was known and that requirements ascribed to the
POCL Infrastructure, Pathway are delivering as part of the EPOSS service.
(Examples are attached at annex A).
MANAGING 3” PARTY PROCUREMENTS
In their response to AI314 Pathway have cited clause 211 as requiring POCL
to approach Pathway with new opportunities as part of the Partnership
intentions.
POCL contend that this clause is only an indication of a desire to establish
such a relationship, but does not commit POCL to always using Pathway.
The purpose of the relevant requirements is to protect POCL’s commercial
freedoms if it proves impossible to establish such a relationship in all areas.
CONCLUSION
POCL remains of the view that the document set currently provided by
Pathway to satisfy requirements 469 and 470 do not meet the requirements.
The restrictions this could place on POCL’s commercial freedoms are
significant. AI314 remains unresolved and is of medium severity.
AI314
Page 3 of 5
POL00028359
POL00028359
ANNEX A
Examples of TMS/OPS requirements that an third party supplier would need to comprehend.
Requirement 478 provides for TMS to perform a range of tasks,
including for example timed data file collection and delivery,
validation of data files, merging of data files etc.
A supplier will need to know how to invoke these facilities in order to
collate and transfer the data relating to the application they are
developing
Solution 472 (re OPS audit trail) includes:
“Pathway’s solution for the OPS is based on a set of counter
applications running on processors at every counter position. The
counter applications all operate under Riposte, a suite of software
which provides mechanisms for ensuring data security and integrity
within the OPS and across the network to TMS.
Note that it is TMS and OPS that provide the facilities to applications -
it is how applications interact to use these facilities that needs
documenting
All data captured at a post office counter either as part of a counter
transaction or as an administration function (user log-on, teller
balance) will form part of a unique transaction which is given a unique
reference number by Riposte. The format of this journal entry will vary
according to the transaction type.
Note that log-ons, system events and application data is journalled to
OPS
Retrieval of data using a particular key field will retrieve all entries
containing that field and logically determine the overall state of the
transaction data. A complete audit trail of all transactions and other
significant events is maintained within the post office systems and is
automatically available for analysis by both audit access facilities and
value added services which are linked to TMS.
Note that Pathway explicitly acknowledge that value added services
will need to be able to extract information from the journal. They need
to document how.
13 August 1999
Annex A Page 1 of 2
1.0
°
POL00028359
POL00028359
o :
Solution 473
Authentication of all users logging on to the OPS in the post office is
undertaken by the OPS operating system. Full access control and
password management facilities are provided. The OPS uses this
information to ensure that only authorised staff are allowed access to
applications, and then only to those applications for which they have
permission.
Note that OPS provides the access control and the mapping of
applications to users. Again, an application needs to know how to drive
these facilities.
A facility which enables users to securely suspend their current session
and then to resume the session is provided as part of the overall OPS
functionality. The suspend function is invoked by the user using a
specific keystroke (e.g. Control + Key) and may. be performed at any
time providing that there is no counter transaction in progress, or where
the transaction integrity may be compromised by allowing a
suspension (e.g. part way through a smart card transaction). The
suspended session may be resumed by the user entering his password.
Again, OPS is provided facilities that underpin the operation of an
application service. How OPS interacts with the application must be
documented.
13 August 1999
Annex A Page 2 of 2 : 1.0