CAs
Response:
Response:
Response:
Issue 9
osponse’
» 28 FEB ’96 10:24 FROM BAYPOCL REQUIREMENTS
dtem 2 of Pau! Rich's leter "IT Concurrence ©
Interfaces between POCL systems and PFI Service via TMS
Implication 6: “Additional interfaces will be req
implication 7
POL00031277
POL00031277
TO 99221120 P,05/08
eting” dated 9 February 28
d unless our requivements are ch. ares
before the ITT is issued. These will become expensive”
POCL ADT (S. Woolley) and ISSU (C Hooper) have «
length, agreed the requirements and provided and agreed th
document;
It is unlikely thai ail the interfaces that may be requ
contract could be sensibly specified, and addition
feature as part of the cost of amending or taking on products.
he Business Case Benefits of TIP and Distribution (and therefore
ign) are dependent upon the right interfaces being in place from TMS
are being jeopardised
These business cases are nota programme issue
The programme has passed onto service providers the requirements for the 1
and Distribution system Interfaces as provided to the programme by the
relevant teams
The programme is constrained by the data st
supply the service provider as requiremen’
plied ¢ it, as to the data it
Implication §. “The iS Strategy will be compromised if the appropriate information
interfaces are not available”
These are addressed in the previous two responses,
It is believed that many of the issues raised in this memorandum were addressed fu the
second meeting that took place with IBM
~The StorePlace solution being cifered does not use a database. All cour
transactions are written to a ‘flat file’ log.”
This was raised as a C5 risk (due to difficulty
demonstrator phase, and wes reflected in the releva:
uting Costs) carl
we factor score
ty
Though IBM are not using a database, their solution does satisfy our
requirements.
POL00031277
POL00031277
+ 28 FEB °96 19:25 FROM BA/POCL RESUIREMENTS To 99221120 Pa
Item 2 of Paul Rich's leer “IT Concurrence Meeting” dated 9 February 28
Issue 10: “IBM are proposing to implement a special “tok:
receipting Benefit Cards at the Counter.
ement’ appiication tor
This application will be under the Benefits Agency contro! and specific
(99? on our counters) directly into PAS, and bypas he Generic capabilin
which we would Jike to see
IBM are implementing the mangement of Benefit cards as an ex
and trace’ system. since StorePla a retail
complex token management capability.
ckage, does not c
The card management portion of the overall soiution can be split off for aii the
service providers if they so desired.
Issue 11. “LBM have not demonstrated that they
transactions, as applied to the Post Office.
iy appreciate the concept of z
They need to demonstrate more convincingly that th
‘ansactions will support us into the furure”
concept of genene
Response: 1BM have the concept of parameierised and sub-classed generic transactions,
this issue was addressed in the subsequent visit to [BM.
“Pathway Visit - Strategic Concurrence” - January 22, 1996
will be mn which [ believe is different trom the view e POCL, particuiaris
in the area of Cash Accounting and related Processes, and the R:
reconciliation and TIP.
This needs to be checked our by Dave Smith and Peter Dent ASAP
They have a structured system which might be very difficult to change”
Response, Pathways understanding is in line with current POCL practice and as defined is
the functional requirements by POCL.
“They do not support the concept of the ‘5 generics.”
nised by the programme, and is reflected as a C5 ri
1g egainst the appropriate value factors.
Response: This has been recog
corresponding mar!
fmipheation “They have not adopted a standard ‘Retail Front Ena’, and therefore the
need to spend considerable time ai rt doing this. 1 am not certain thar
within the time constraints of the Programme, that they can develop ali the bes
demonstrated retail controls that we would expect to see in a fully roiled
system. (Retail specialists have spent many years developing these conwo!
(e.g. They cannot yet demonstrate the concept of a Customer Session work
Respons
FEB '96 16:25 FROM BA/POCL REQUIREMENTS TO 99221120
Item 2 of Paul Rich's lever "IT Concurrence Mestin,
Response:
Implication 15;
POL00031277
POL00031277
properly - where they have tried to Pilot it, a customer cannot do tnore than
transactions - many more examples are available)
They talk about, and can describe some of the processes and bur thes
have not demonstrated that they really understand the amount of effort in or =
in delivering them.”
This has been recognised by the programine, wi
against the appropriate value factors,
corresponding 5
Their system is 2 ‘closed’ design. The Pathway solution is based aroun?
innovative messaging technology. As long as the system is ‘slosed” then this
technology may (yet to be proven) work effectively, However as soon as po
need to communicate with systems that do not use the messaging technol: 2}
you have to write a software agent
These Software Agents can be very cumbersome. need to be riten for ev<
eaternal interface (2.2. Moving daca to TIP, Interface with Bill Payment Chon
(each needing his own agent). Distribution etc. etc)
There are very fow (if any) Software Agents currently written, aud we would
specify al! of them in advance of the ITT, as each new product’custam:
system may need one, and we will probably be asked to pay an appiop:
for additional Software Agents. "1!"
Pathw
deed requite the creation of software agents
the interfaces to external sj stems, however these agents are equivales
interface modules that would need to be written in the other two sys
any other simil: erings) to ha: Specific data processi
formatting and communications protocols for the transfer to the
The term "software agent” is 2 feature of the particular style adopted by
academics within Escher; the term Life or module might be equally
appropriate, The agent is a program which uses the published Riposte 32
extract data (in the form of messages) from the Riposte Message Store.
processes it according to business requirements - for cur clients, this would
mean formatting it to their particular neeas and transferring it tc them
The Riposte API includes calls to enable both “on line” and "batch" agents
written; indeed, the An Post Savings Bank transaction witnessed
just an agent using the APT to handle on-line withdrawal and de;
transactions performed at the counter, The agent “listens” for the specific
transaction type, and forwards the authorisation request onto the Savings Bar
computer (an existing mainframe application) in real time; it then passes the
response from the mainframe back to Riposte (across the API) and down te
requesting terminal
Ap agent can handle transactions for more than one client; indeed, it would bs
possible to pass al! transactions of a particular generic type though the same
agent. As with any of the solutions, however, it is likely there would have to be
POL00031277
POL00031277
Deputy Director
BA/POCL Programme