global product support and solutions · date of issue: global product support and solutions...

GLOBAL PRODUCT SUPPORT AND SOLUTIONS

Document Version 1.1 Date of issue: 31 March 2011

GLOBAL TON AUTHORING STANDARD GPSS, CUSTOMER TECHNICAL SERVICES, THOMSON REUTERS

Revision History

Global TON Authoring Guideline Document version 1.1

2

REVISION HISTORY

Name Date version Summary of changes

Yaowarat S 0.1 Create TON content section

Yaowarat S. 30 Apr 10 0.2 Add another section

Yaowarat S 21 May 10 0.3 Revised according to comments from work group

Yaowarat S. 01 July 10 0.4 Revised according to Julie‟s comments and GPSS Client Site Deployment Testing requirements

Add beta TON process

Yaowarat S 09 Jul 10 0.5 Add TON Approval guideline section

Yaowarat S. 20th

Jul 10 0.6 Revise according to comments from group

Yaowarat S. 23rd

July 10 1.0 Issued

Paul Mear 31st Mar 11 1.1 More Guidance added on the Management Summary

REVIEW HISTORY

Reviewer Name Doc Version Reviewed

Date Sent for review

Date Review Filed

Approved/Rejected (with Reasons)

About this document


3

CONTENTS

About this document 4

Intended readership 4

In this guide 4

Chapter 1 Introduction 5

Objective 5

Roles & Responsibility 5

TON Author 5

TON Approver 5

Measurement 5

Chapter 2 Type of TON 6

Technical operations note (TON) 6

Note fore the record (NFR) 6

END TO END (E2E) 6

Chapter 3 TON Target audience 7

Chapter 4 TON Authoring Guideline 8

Chapter 5 TON authoring practice 22

recommended practice 22

BETA TON 22

Pre-circulation 23

Chapter 6 Approval guideline 24

prerequsite information 24

Recommended practice for approver 24

About this document


4

ABOUT THIS DOCUMENT

INTENDED READERSHIP

CTS Engineers and Management Team

GPSS Staff

Product Development

Regional Launch Management

Technical Account Managers

IN THIS GUIDE

This document provides a guideline and practice for authoring a TON.

Introduction


5

CHAPTER 1 INTRODUCTION

OBJECTIVE

The objective of the Global TON Authoring Standard is to provide a global standard on the scope and corresponding

contents for each section of a TON. This is done to ensure a globally consistent communication approach to client

site frontline staff.

ROLES & RESPONSIBILITY

TON Author

o Provide client site deployment information to Thomson Reuters front line staff.

o Compose TONs that adhere to the Global TON Authoring Standard.

o Ensure that the content of the TON is a reflection of the project requirements and client site deployment test

results (a.k.a. qualification testing).

TON Approver

o Ensure that the product is technically suitable for client site deployment and that all approved client site

requirements have been tested with positive test results.

o Ensure that the contents of the TON adhere to the Global TON Authoring Standard

o Ensures that the content of the TON is a result of the technical client site deployment testing.

MEASUREMENT

A monthly audit will be held to review compliance with the Global TON Authoring Standard. It is the responsibility of

the GPSS Support and Qualification Manager to be accountable for the compliance of the TON contents against the

TON authoring standard.

Type of TON


6

CHAPTER 2 TYPE OF TON

Communication that a Thomson Reuters Markets product is technically ready for client site deployment is achieved

through the following TON classifications:

Technical Operations Note (TON)

Note for the Record (NFR)

End-to-End TON (E2E)

TECHNICAL OPERATIONS NOTE (TON)

A TON is the end result of Client Site Deployment Testing and will be used to notify the target audience that the

product is technically ready for client site deployment. The scope of information that is provided to the target audience

is as follows:

Scope of product support including OS, product version and schedule for implementation

Location of software

Standard for product implementation / deployment

Convey availability of supporting infrastructure(s)

Convey consequences of not implementing various items

Trigger actions by various groups such as the Regional Launch Manager, Deployment Manager

It is important to understand that when a TON is published, the product is deemed technically suitable for client site

deployment. However, the product may not be deployed at a client site until the corresponding support process, user

accounts/permissions, infrastructure, etc. are ready for final launch.

NOTE FOR THE RECORD (NFR)

A NFR is used when it is necessary to share technical information quickly with the target audience which may have

regional or global impact. Scope of information that is provided in NFR can vary depending on users' needs.

Examples of information provided in NFR are

Product obsolescence notification

Technical impact to any product which there is a need for the TON audience to be rapidly informed

To inform 3rd Party of a change in software or hardware configuration

Notification of updates to an existing product or service

END TO END (E2E)

End to End is a baseline suite of TONs required for the implementation of a migration, deployment, solution, and/or

upgrade scenario, which requires installation of multiple Thomson Reuter‟s products and/or services at a customer

site.

TON Target audience


7

CHAPTER 3 TON TARGET AUDIENCE

The objective of this section is to indicate the TON audience and the corresponding relevant information that is

required to be communicated via the TON.

Target audience Information to be communicated

Technical Account Manager Direct Technical Specialist Global Technical Manager

Client Site Network and Communications

User Permission and Product License

Client Site E2E Technical Migration

Client Site E2E Capacity

Client Site Security

CTS Engineer/ 3rd

party engineer Customer Implementation Specialist

Client Site Installation and Deployment

Client Site Network and Communications

Client Site Hardware Device

User Permission and Product License

Client Site Recovery and Resiliency

Client Site E2E Deployment Integration


Client Site E2E Capacity

Client Site Remote Capabilities

Client Site Tools

Documentation

Field Service Technical Competency

Product Manager Client Site Impact Analysis

Notification that product is technically suitable for client site deployment

Client Site Exception

Global Launch Manager /Regional Launch Manager Migration Project Manager


Notification that product is technically suitable for client site deployment

Release priority planning based on TON classification

Distribution Management Client Site Installation and Deployment

Client Site Hardware Device

Client Site Remote Capabilities

Documentation

TON Authoring Guideline


8

CHAPTER 4 TON AUTHORING GUIDELINE

The objective of this section is to provide an authoring guideline on how to compose a TON. In each section, the

authoring guideline provides information on what appropriate information should be included and the rationale on why

the information is required.

However, the guidelines do not provide the actual contents to be placed into the TON. The contents of the TON are

driven by the project requirements and the resulting client site deployment test results.

TON SUBJECT:

TON Authoring Guideline:

The subject of a TON will be used for referencing and searching. At a minimum, the TON subject must contain

information of the main product name and version.

Therefore, when composing the TON subject, please use the following naming standard:

Please use the full product name that is published on the Customer Zone in the TON subject, followed by

the acronym in brackets and then followed by the product version

<CZ Product Name>< (CZ Product Acronym) > <Product Version>

If the TON is for beta period, word “BETA” must be put in front of product name. For example

BETA <CZ Product Name>< (CZ Product Acronym) > <Product Version>

For example, Thomson Reuters Data Feed (RDF) 2.0.1 , for RRG TON

Or BETA Thomson Reuters Data Feed (RDF) 2.0.1, for beta TON

Why is this information required?

1. This information is provided to allow the TON reader to be able to understand the relevance of the TON

2. It is important that the TON subject naming convention is adhered to as this will allow TON users to be able to

accurately search for the TON.

PRODUCT:


Please use the full name of the product that is indicated on Customer Zone followed by the product acronym where

applicable. In the case that TON is not related to any product, i.e. Infrastructure or Tools, please use the infrastructure

or tool name.


1. The product name is required to understand which product the TON refers to as being able to deploy at client

sites.

RELATED PRODUCT:


Please provide a list of related products to the TON.


1. A consolidated list of related products provides a reference for the field engineer to research settings and

guidelines that may have an impact on overall system operation.



9

CLASSIFICATION:


Please provide classification type of the TON.

For reference, there are three types of TON classification:

Mandatory - Indicates that there will be service and/or business impact if TON is not implemented

Recommended - Indicates that this TON can be implemented on the next site visit

Optional - Indicates that this TON is required only at specific customer sites IMPORTANT REMINDER: For Mandatory TONs requiring client site visits, written approval must be obtained from the Customer Technical Services (CTS) Leadership Team. It is the responsibility of the GPSS Support & Qualifications Manager to engage with the CTS Leadership team and obtain approval. Mandatory TONs for software that will be remotely downloaded by Distribution Management do not need CTS LT review.

Where can I obtain this information? To determine the TON classification type, please use the following evaluation criteria:

TON

Classification

Value

Evaluation Criteria Service Impact Examples Business Impact Example

Mandatory 1. Is there an immediate

service threat to customers

if the TON is not

implemented within a

specified date?

2. Will there be cost/risk to

Thomson Reuters‟s

business if the TON is not

implemented within a

specified date?

Due to increased market update

rates, client site hardware

devices must be upgraded by a

specified date; otherwise client

sites may experience service

disruption due to failure to cope

with increased update rates.

Due to a business decision,

client site products will be

migrated from RXN to BT MPLS

in order to reduce the number of

Data Centers in Thomson

Reuters.

Recommended 1. Delay in implementation of

the release will not degrade

service nor introduce cost

to Thomson Reuters.

2. Is the product release a

result of standard BAU

maintenance release to fix

software deficiencies

reported from customers?

3. Is there an enhancement

that will benefit some

customers? It will also be

up to each customer to

determine its relevance to

their business priorities.

RMDS releases a new version of

the P2PS on a new platform with

bug fixes

Dealing releases a set of

quarterly Microsoft patches for

distribution management to

deploy to client sites.

Customer may not be able to

take advantage of new features

unless the new software is

deployed

Optional 1. Is the release specific to a

particular customer site

and/or region/country?

Eikon releases a BETA TON for

Eikon Mobile that is to be tested

only by BETA sites.

3000xtra releases a patch for the

Japanese version.

There may be extra cost to TR

or the customer for a special

piece of hardware that not all

customers need (e.g. with extra

power supply, or non-standard



10

TON

Classification

Value

Evaluation Criteria Service Impact Examples Business Impact Example

Changes are being made

centrally or remotely and the

TON is for information purposes

only

size (e.g. USFF Dealing Server

hardware))


1. It is important to understand that multiple TONs are published on a weekly basis; therefore, it becomes a

challenge for CTS to determine which TONs are to be implemented at client sites. The TON classification provides information on the priority of when the TON needs to be implemented at client sites.

2. The TON classification has an impact on the priority of CTS deployment/migration plans. Before a TON is published, prioritization and planning must take place to determine what resources and budgets are required to complete deployment within the specified completion date.

3. If a TON is marked as mandatory, the product/proposition must be deployed successfully at client sites by a specific target date in order to resolve a service issue and/or meet business targets (i.e. migration to a new platform).

WHEN REQUIRED:


Please specify the date when the client site deployment should be completed. This can be either a date or a

statement depending on the TON classification.

The table below shows the relationship of the TON classification and the When Required field

TON Classification Value When Required Value

Mandatory Date

Recommended Statement “ Next scheduled deployment, to be

determined locally”

Optional Statement “ As required”


1. Given limited CTS resources and multiple priorities it is important to provide guidance on when the client site

deployment must be completed. This will allow CTS to be able to plan effectively for when the client site

deployment will need to take place.

DEPLOYMENT AREAS:


Please provide information on where the product/proposition is targeted for deployment.

Options are: Global, AMERS, ASIA, EMEA. In situations where a product/proposition is only deployed for a specific

set of countries, the actual country name may be listed.




11

1. Due to business requirements and customer demand (i.e. maturity of markets), it is possible that a global

product/proposition may be rolled out globally in phases (i.e. roll out in AMERS prior to ASIA).

2. It is important that GTMs/TAMs and CTS engineers do not deploy products in regions that are not specified in

the TON as the supporting infrastructure/production environments and corresponding support teams may not

be in place to provide the level of service required by the customer.

HARDWARE/SOFTWARE INFORMATION:


Please provide the following information:

Software Version

Hardware RIN number

IMPORTANT REMINDER: All hardware devices that are owned by Thomson Reuters require a Reuters Identification

Number (RIN). A RIN is a confirmation that the hardware device has passed client site deployment testing and is

compliant with TP-FS1 Client Site Equipment Selection and Approval Requirement Definition Policy. More

information can be found at:

http://www.ime.reuters.com/tp/sections/policy.asp?sec=FS&polID=1


1. Software and Hardware versions are required to ensure that the CTS engineer installs the correct software

and/or hardware version during a client site deployment.

2. The RIN number is a confirmation that the hardware is in compliance with Field Service Policy TP-FS1.

GLOBAL PROJECT CODE:


The Project Code would be provided by the person maintaining the Global Project Register. This will be used for

tracking upgrade and migration activities


1. For Mandatory TONs requiring client site visits, a Global Project Code should be assigned - this implies that

the project has been reviewed by the CTS leadership team, budget implications have been assessed and

agreed, and the resulting upgrade or migration project planning has been kicked off. By having the code in

the TON, it will help TAMs who are planning their customer upgrades know which code to put in Siebel to kick

off the order (the code is used in the Technical Order Management (TOM) system). A project code may not

be necessary for Recommended or Optional TONs if there is no related upgrade project; it is also not

necessary for Mandatory TONs for software that will be remotely downloaded by Distribution Management.

MANAGEMENT SUMMARY:


Please provide a summary of all the key points in the TON so that the target audience can effectively determine the

following:

What is the objective of the TON?

What are the products/propositions that will be deployed as part of this TON?

Consider what senior CTS management (including Deployment, IMG, TSG, Vendor Management,

Service Management, etc.) need to know about this TON e.g.:

o What are the most significant benefits of implementing the TON,

o What is the customer and other impact of not implementing this TON?

What are the wider implications of this TON e.g.:

o Costs

o Business processes,

http://www.ime.reuters.com/tp/sections/policy.asp?sec=FS&polID=1



12

o Installation and support processes

o Documentation.

o Are any actions needed by clients

o What are the risks?

o Is there a fallback plan (is one needed)?

o What needs to be done to measure success?

Bear in mind this is a summary and remember to keep it

o free of technical jargon

o short

o concise

o unambiguous

Any detail required should be in the body of the TON and not in the management summary.

Example of Management Summary

TON 10522

This DACS Permission Service Binary Update for Thomson Reuters Eikon (DACS Patch) version 6.0.0.F9 is required

to be patched on DACS Server/P2PS, in order to be able to work with Thomson Reuters Eikon.

This patch allows Thomson Reuters Eikon application (in Customer Managed mode with local RMDS) to retrieve the

permission from the local DACS via HTTP request in order to synchronize local permission with Thomson Reuters

Platform's Hosted Permission System (Hosted DACS on AAA services through Web Service Gateway).

This patch is mandatory for P2PS users, NOT for RTIC users.


1. As there are multiple TONs that are released on a weekly basis, this helps CTS engineers and managers

quickly understand an overview of the TON without having to read the entire TON.

2. The contents of the Management Summary section will be sent out as part of the TON email subscriptions.

CUSTOMER IMPACT:


Please list the impact to customers as a result of implementing the TON

Customer Service Impact:

Deployment/Installation/Migration/Upgrade Window (i.e. weekends, AMERS market closure.)

Provide information on the length of time required for a successful client site deployment.

Provide information on the downtime required during client site deployment.

Provide information if the products/services need to be restarted during client site deployment.

Business Impact:

Potential cost imposed to the customer/Thomson Reuters due to higher technical requirements, e.g. more

bandwidth, higher hardware specifications, upgrade of other related systems and etc.

Potential commercial impact

Why is this information required? 1. It‟s vital that CTS engineers, CIS and TAMs understand the service and business impacts during client site

deployment.

2. These impacts will then allow the CTS engineer to plan when the client site deployment should take place.

3. GTMs/TAMs will be able to use the client site impact information to inform customers

IMPACT OF NOT IMPLEMENTING THIS TON:



13


Please list the consequences that the customer and/or Thomson Reuters will face if the TON is not implemented.

Customer Service Perspective: If this TON is not implemented, the customer will not benefit from the bug fixes and

feature enhancements, which may result in service issues at client sites.

Business Perspective: List the most significant benefits to Thomson Reuters (i.e. obsolescence of legacy systems,

central delivery mechanism into consolidated platform, reduce DC footprint, market competition advantage.)


1. It is important to understand that the majority of TONs that are being published are either classified as

„Recommended‟ or „Optional‟ and CTS engineers and/or Regional Launch may have a difficult time

determining when to deploy a TON. Therefore, this section provides more information to CTS engineers

and/or Regional Launch so that priorities and resources can be planned appropriately.

2. It is also important to understand that TONs need to equip CTS engineers with adequate information on the

customer service and business rationale for deploying the TON, so that this information can be

communicated back to key stakeholders (if asked.)



14

REMOTE CAPABILITIES:

TON Authoring Guideline: Please provide information about remote access capabilities to a client site desktop or server. Examples are as follows:

All new desktop products will use WebEx capabilities.

All RMDS devices are normally remotely accessible via the client configuration.

For DDS servers (RDF and RWS) and DOIP and MOIP servers, these can be accessed via PTME in order to remote check the servers.

Why is this information required? 1. Thomson Reuters Markets is moving away from on-site deployment/support as on-site activities result in

additional cost. The firm is moving in the direction of remote deployment and support. Therefore, when applicable, it is important that the TON provides information on remote capabilities that will allow remote deployment and/or support of the product/proposition.

COMPONENTS:


Please provide information on the components required for deployment at client sites in order for the

product/proposition to function successfully.

Components are classified as follows:

Software

BIOS/CMOS/Firmware versions

Operating system standard build version

Application versions and platforms

Infrastructure/Technology

Hardware Physical dimensions

Heat and power consumption

Environmental and installation requirements, including airflow, orientation, mounting hardware, manual

handling for heavy items

RIN and supplier part numbers

Export classifications for hardware and software


1. It is important to keep in mind that the product may be installed at a client site that has never had the

product/proposition before. Therefore, the component section provides information of the complete

environment that CTS engineers need to be aware of when deploying the product/proposition at client site.

2. Acts a mini-checklist of what is required at client site.

PRODUCT DESCRIPTION:


Please provide information on the objective of the proposition/product – why is Thomson Reuters delivering these

propositions/products to customers?

Please provide a technical description on the main features of the product including main bug fixes and/or

enhancement changes to the proposition or product.



15


1. Given the number of TONs being released on a weekly basis and with CTS engineers having limited time to

learn about every new product release, it is important to provide the main highlights of the product/proposition

in the description section so that CTS engineers can easily come up to speed on the main features of the

product and have the confidence to deploy the product at a client site.

MAJOR CLIENT SITE DEPLOYMENT DEFICIENCIES:


Please list any all known deficiencies or point the reader to the external repository (PAZ, customer zone, etc.) or

release notes that have an impact on client site deployment.

IMPORTANT REMINDER: The purpose of this section is not to duplicate information that is already provided in

Release notes/README/CAZ. Instead, the objective of a TON is to declare that a product/proposition is technically

suitable for client site deployment. Therefore, the major deficiencies should only highlight issues that will impede

client site deployment.


1. During client site deployment, CTS engineers need to be aware of product/proposition deficiencies that

impede client site deployment. They then need to be able to implement any approved workaround (if

available). It is not the CTS engineers‟ responsibility to be aware of all deficiencies.

ESCALATION PATH:


During client site deployment, CTS engineers/Distribution Management may encounter technical issues. In such a

situation, CTS engineers/Distribution Management will contact GPSS for assistance and/or escalate the issue to

GPSS for resolution.

Therefore, please provide the following information on how CTS engineers raise technical issues to GPSS.

SIEBEL CRM Resolver group

Email Contact

Hours of Operation


1. During client site deployment, an engineer may encounter an unexpected technical issue; therefore,

escalation information needs to be provided to CTS engineers so they know how to obtain assistance on

technical deployment issues.

TESTING OF SUCCESSFUL CLIENT SITE DEPLOYMENT


List any applicable testing methodology to verify readiness or success of client site deployment: (inclusion of the

below and corresponding testing methodology is dependent on the product/proposition.)

Installation and deployment: Test that the product has been installed in the correct directory structure

Co-existence and Backward compatibility: Test that the product has been successfully installed/upgraded

without impacting other Thomson Reuters products on the same device.

Licensing: Test that the product license allows successful service subscription from the installed product.

Production/Head-end/ Service Pack Information: Test that the installed product is successfully connected to

the right production/head-end service and the right service can be retrieved via MPLS.



16

Network Connectivity: Test that the network/comms from client sites, such as router/switch configuration,

has been setup properly to connect to the right production/head-end service through the defined delivery

infrastructure (i.e. MPLS, internet.)

Bandwidth Requirements: Test the appropriate level of last mile bandwidth size allocation has been allocated

for the installed product.

Hardware Information: Test that the product has been successfully installed on the right hardware

specification

3rd

party technology: Test that required 3rd

party software (i.e. JRE, MS patches) has been installed with the

product.

Migration Scenario: Test that the services at client site prior to migration are able to access after migration

has been completed.

End-to-End Integration Scenarios: Test that the installed product can subscribe to services from the E2E

service scenarios. For example, Elektron connected to RMDS 6. A client site app (i.e. Eikon) should be

configured to connect to a RTIC/P2PS that is retrieving IDN data from Elektron and not from the RDF 2.x -

IDN feed.


1. Before concluding the deployment is complete, information needs to be provided on how to verify that the

deployment was successful. This information is conveyed in steps required to verify that the deployment is

successful.

AREA SPECIFIC INFORMATION:

TON Authoring Guideline: List of specific information to each region This section is only applicable for the Americas and indicates if IBM needs to be aware of the TON contents (this is usually the case for Americas deployments, but not always.) This section may also be used to add other specific details that only apply in the AMERS region. AMERS Specific Information Service Vendor: IBM Integration Vendor: IBM

Why is this information required? 1. It is important to understand that Thomson Reuters CTS engineers consist of both Thomson Reuters

employees and outsourced vendors. It is also important to understand that each vendor may be different, dependent on the region. For example, in AMERS, on-site work is outsourced to IBM. In such a situation the outsource vendor may require additional instructions on client site deployment. This information is provided regionally prior to publishing the TON.

RELATED HARDWARE:

TON Authoring Guideline: Please list approved hardware on which the validation has been done

IMPLEMENTATION:


The purpose of this section is to provide technical implementation information about a product/proposition at a client

site.

IMPORTANT REMINDER: The purpose of the „Implementation‟ Section is not to repeat the product installation step.

Please be reminded that the Implementation section covers all the components that need to be deployed at a client

site in order for the product/proposition to operate successfully. Therefore, step by step installation should not be



17

provided in this section. Instead, reference should be made to the Installation/Configuration Documentation that is

located on the PAZ page and/or available in the product/proposition package.

During the creation of the TON, please consider the information below that should be included as part of the TON.

Please be advised that not all the information below will be applicable to every TON. Inclusion of the information

below will depend on the project requirements used during client site deployment testing (a.k.a. qualifications.)

1. Client Site Installation and Deployment: Information on client site installation and deployment is provided to

ensure that a Thomson Reuters product/proposition is able to meet the following client site installation and

deployment standards:

TP-FS1 Client Site Equipment Selection and Approval Requirement Definition

TP-FS2 Client Installation Policy

More information regarding the Field Service Technical Policies can be obtained from:

http://www.ime.reuters.com/tp/sections/section.asp?sec=fs

During creation of the TON, please provide the following information:

Installation Standards: Information on the Installation Standards that cover the entire process range of work

at the client site and the work carried out in preparation of the equipment destined for installation on the client

site.

Manual Installation: Information on manual installation indicating a limited number of steps required for

installation, thus reducing the amount of time a field engineer requires to be on site.

Remote Deployment Installation: Information on GMI/PTME enrollment and deployment. When applicable,

the server should be prepared away from the client site and only requires the server to be enrolled when

plugged into GMI/PTME.

3rd

party Dependency: Information on 3rd

party software required for installation. Please be advised that if

the product requires 3rd

party software to be successfully installed, compatibility with the on-site 3rd

party

software should be verified if supported by Thomson Reuters Markets.

Downtime: Information on installation window. Installation should take place outside of market hours and

should not require a downtime that would impact client site services and business operations.

Software Installation Tools: Information on approved installation tools and deployment approaches.

Installation Audit: Information on how to verify that the installation has been completed successfully. All

new client site installations must be audited by the Thomson Reuters Markets group responsible for

installations to ensure that (1) the order details have been fully completed and (2) the installation meets the

requirements of TP-FS2 policy.

Security for installation of operating systems: Information on any actions required to prevent any potential

security threats that may impact client site services and business operations. This may include information on

firewall settings, port permissions, and internet site certification.

Virus Protection: Information on any anti-virus software that is required to be installed at client site. Please

be advised that all system, media, etc., either supplied to the client or used for maintenance purposed must

be virus free.

More information regarding antivirus practice can be obtained from

http://www.ime.reuters.com/gsp/kzscripts/default.asp?cid=576&highlight=anti%20virus

Un-installation: Instructions on how to uninstall the product. The “uninstall” approach should reinstate the

previous version of the product without any data loss. This may be automated to provide automatic fall back

to the previous version of software.

2. Client Site Network and Communications Information: Information on network and communications is provided

to ensure that all client site network devices are set up correctly to receive services from Thomson Reuters.


http://www.ime.reuters.com/tp/sections/section.asp?sec=fs

http://www.ime.reuters.com/gsp/kzscripts/default.asp?cid=576&highlight=anti%20virus



18

BT Service Package Requirements:

o Information on the services required in the BT Service Packages to deliver services at client site.

o Information of client site IP ranges and impact to IP address translation at client sites, firewall

changes and impacts to statistics routes for client site products (i.e. RDF, RWS, RMCD)

Client Site DNS Setup:

o If changes are required to the client site DNS, please provide the following information:

Client Workstation resolver only (No client site DNS)

Client Site DNS using selective/conditional forwarding

Client site routing of IP subnets are need to route to the correct Thomson Reuters

gateway.

Delivery Infrastructure: Please provide information on the delivery infrastructure that the products are supported on:

o Internet Connectivity o BT MPLS o Savvis o ELF o Satellite Receivers o WiFi

Network and Bandwidth Requirement:

Please provide information on the required network connectivity:

o WAN and LAN speed links:

Link speed

Half/Full Duplex

o Client Site Firewall setting/configuration

o Client Site Internet Proxy setting/configuration

o Client Site network protocol (TCP) and port numbers

Please provide information on bandwidth requirements:

o BT Service Pack B/W requirements

o Supported number of stations/client apps connected to client site LAN based on specified B/W

requirements

Please provide bandwidth requirements for supported delivery infrastructures: o Internet Connectivity – ISP internet speed (upload and download) o BT MPLS (BT Service Package B/W specification) o Savvis o ELF o Satellite Receivers o WiFi for Mobile (Blackberry, iPhone)

3. Client Site User Permission and Licensing Information: Information on the required user permission and

licensing for the client site service to operate successfully.

During creation of the TON, please provide information on the required user permission and/or licensing required at

the client site.

4. Client Site Deployment Integration Information: Information on the integration environment that the product has

been tested against to ensure that a Thomson Reuters product/proposition can be deployed into a client site

production environment.

IMPORTANT REMINDER: It is important to understand that customers will have multiple Thomson Reuters products

from various SBUs (Enterprise, S&T, I&A, Media) integrated in their production environments. Therefore, it is

important to provide information on the E2E integrated environment which the product, specified in the TON, has

undergone client site deployment testing.


Co-existence of multiple Thomson Reuters products on the same client site device:

o Information on Thomson Reuters products that can co-exist and be installed on the same pc/server.



19

Backward Compatibility Testing Requirements:

o Information on backward compatibility. Please note that the latest product version should be

backward compatible with at least the two previous versions.

End-to-End Integration Testing Environments:

o Information on the integration environment that the product/proposition has been tested against to

ensure that the product seamlessly interacts with other products without service impact.

IMPORTANT TIP: Using a diagram to represent the E2E client site environment used during client site deployment

testing will be easier to understand compared to listing a set of products.

5. Client Site Technical Migration Information: Information on the approved migration path and deployment

instructions.


6. Client Site Deployment Testing Requirements: During client site deployment testing, execution of technical

migration testing considers the following requirements:

Information on migration path for legacy products according to defined and approved migration path

Information on setup/configuration for dual-running is supported for legacy and new products during migration

Information on roll-back migration instructions (if required)

IMPORTANT REMINDER: If the migration requires both migration of infrastructure and products, the information

should be provided in an E2E TON. Please be reminded that an E2E TON is a baseline suite of multiple TONs

required for the implementation of a migration, deployment, solution and/or upgrade scenario which requires

installation of multiple Thomson Reuter‟s products and/or service infrastructures at a customer site. Therefore, in an

E2E TON for migration, the following information should be referred to:

o Client Site Delivery Infrastructure

o Client Site BT Service Packages

o Client Site Network and Communications

o Client Site Supported platforms (Operating System, hardware specification) need to be verified for

designated migration path

o Client site User permission and license

7. Client Site Capacity Information: Information on the capacity that client site devices are able to cope with from

increased update rates on the Full-Tick Network (FTN).


Information on the capacity (in terms of updates/second) that the product has been tested against in

preparation for IDN Up-speed on the Full-Tick Network (FTN) and B/W Optimization Network (BON).

8. Client Site Tools: Information on client site tools that will be used by field service and/or clients that are available

and adequate for troubleshooting, assisting in deployment and performance measurement (when required.) Some

tools are as follows:

Diagnostic Tools: Tools for troubleshooting service impact issues such as, but not limited to, RIC

watch list, cache dumps, logs, incoming/outgoing data monitoring.

Deployment Tools: Tools that assist in installation/deployment of products that reduce time required to be

on-site.

Performance Tools: Products where latency measurement is part of the proposition (i.e. RDF-D) need to

have a standard latency monitoring tool.

9. Field Service Technical Competency: Information on technical skills required by field service in order to deploy

the product successfully at client site. This is important as new product/propositions can introduce new technology to

support the market trend, customer demand and Thomson Reuter‟s business direction.



20

IMPORTANT REMINDER: It is also important to understand that Thomson Reuters has outsourced field services, in

some regions, to 3rd

party vendors (e.g. IBM, HP), therefore, it is important to provide visibility on the technical

competencies required to deploy a product on a client site.


Operating System: Windows/UNIX (Solaris, Red Had, SuSe)

o Ability to install, administer, use and troubleshoot tasks and issues in operating systems required by

products

o Has an understanding of basic concepts of operating systems, processes, inter-process

communication and synchronization, file systems and memory management, segmentation, paging

o Has an understanding of environment setup, loading and linking libraries

o Has an understanding of basic OS commands

o Able to perform both attended and unattended installation of operating systems

Database

o Ability to understand database concepts and ability to install, administer and use DBMS software.

o Able to set up and configure RDBMS application and able to use query languages including store

procedures effectively.

Network: Firewall, CISCO switches/routers, Satellite receives

o Ability to understand network concepts of TCP/IP, UDP, network communications, network

performance, network hardware as well as ability to use network tools to troubleshoot problems.

o Understands concepts from level 1 and able to design simple Ethernet LAN including using basic

network troubleshooting tools, which generally come with OS, to analyze and troubleshooting network

issues.

o Has an understanding of various network topologies, client-server models, and structure/mechanism

of 5-layer simplified OSI model: application, transport, network, data-link and physical layers

o Has an understanding of local area network, design concepts of protocols, routing algorithms,

application of network.

o Has an understanding of IP broadcast, multicast and unicast as well as able to explain the difference

and the similarity among their concepts.

o Has the ability to setup and configure CISCO switches/routers, satellite and firewalls.

Product Installation and Tuning

o Ability to set up, install and configure products within area of responsibility including other

dependencies that are required.

o Able to perform advanced configuration of the product as well as its prerequisite or dependent

applications to construct a system that offers completeness of specific features required in certain

scenario.

Management Systems

o PTME

o GMI

Why is this information required? 1. It is important to understand that during client site deployment, a CTS engineer may need to go through

multiple installation documents (depending on the number of components.) Therefore, the implementation

section provides information of the end to end sequence of actions required during the client site deployment.

2. If one of the actions requires information from the product installation guide, it should be referenced from the

TON and not re-inserted into the TON.

ADDITIONAL INFORMATION:


Use this section for other relevant information.

TON PLAZA:

TON Authoring Guideline: Provides all URLs to relevant information related to the TON



21

For example:

PAZ GPN Customer Zone intern use Customer Zone external Support Model Roadmap Technical manual Release Notes

Why is this information required? 1. It is important to understand that the aim of the TON is to provide a complete set of information to a CTS

engineer to avoid having the CTS engineer waste time searching for corresponding information. 2. Therefore, information related to the product/proposition will be linked from the TON, which the CTS engineer

can use as a reference.

DOCUMENT INFORMATION:

Author: Author of the TON

Co-Author: Co-Author of the TON

Approver: TON Approver

Release Date: The date which TON has been published

ASSOCIATED TONS:

TON Authoring Guideline: Please list the TONs that contain content related to this TON. An Associated TON is defined as a product that interacts with the product as part of a workflow, but is not pre-requisite for installation.

Why is this information required? 1. It is important to understand that this information is not mandatory. 2. This information is provided for reference by the TON reader.

PREREQUISITE TONS:

TON Authoring Guideline: Please provide a list of TONs which need to be implemented prior to this TON in order for the product be deployed successfully at a client site.

Why is this information required? 1. It important to understand that Thomson Reuters Markets products can be complex and are designed to

interact seamlessly. 2. During a client site upgrade or migration, multiple products may be installed/upgraded; CTS engineers need

to be clear on the sequence of TONs that need to be implemented, as well as whether any activities described in the pre-requisite TON are required prior to client site deployment of the product specified in this TON.

KEYWORDS:

By default, existing key words should be used. If a new key word is required, approval from the TON approver is

required prior to creation.


1. This information is used for the search capability within the TON Server Database.

TON authoring practice


22

CHAPTER 5 TON AUTHORING PRACTICE

RECOMMENDED PRACTICE

The following practices are recommended for TON authoring in order to provide consistent information to the CTS

engineer:

Acronyms shouldn‟t be used in the TON. Third parties now view TONs therefore they should be easier to

read.

All documentation contained in a TON or linked to by the TON needs to be published and signed off by

the time the TON is released.

Contain all relevant information in the TON; do not link to outside information. Since third parties now

view TONs they do not always have access to referenced or linked material.

The following information should be obtained from Product Management in order to help TAMs explain to

a customer‟s IT manager the key features and implications of the upgrade/migration: o Purpose of the upgrade/migration o Potential impact on the client‟s systems/operations o Technical requirements of the affected systems/products o Potential impact on the cost of installation and maintenance

Ensure all TONs are classified correctly with the right keywords and are consistent

Hardware related TONs should provide the following information: o BIOS/CMOS/Firmware versions o Physical dimensions o Pre-installed operating system and applications and recovery method o Operating system standard build version o Heat and power consumption o Environmental and installation requirements, including airflow, orientation, mounting hardware,

manual handling for heavy items o RIN and supplier part numbers o Export classifications for hardware and software o Cross reference to supported products o Detailed specification of the hardware (Quickspecs, product brief, etc.) o Warranty details o Warranty support contact and process details o Installation documentation

In the event there is a need to edit the published TON, the author must provide a meaningful justification in the request as this message will be displayed in the historical TON page so that the TON reader understands what content in the TON has been edited/changed.

BETA TON

The TON can be released when the product goes to beta period with the following recommendations:

Word “BETA” must be indicated in the TON subject.

After ending of the beta period, the TON needs to be modified and re-publish in order to incorporate

additional information / feedbacks during beta period.

Word “ BETA ” must be removed from the subject when re-publish for RRG.

TON authoring practice


23

PRE-CIRCULATION

The objective of pre-circulation is to obtain comments and views from product stakeholders. The following actions are

recommended for TON pre-circulation:

There should be a peer review process within the team prior to pre-circulation or approval stage. This is to ensure correctness and consistency.

Key stakeholders for each product should review the TON in for pre-circulation and sign off for publishing. Also, comments from stakeholder must be addressed prior to publishing.

When the TON goes to pre-circulation stage, authors should notify the key stakeholders by e-mail in order to avoid missing information.

Approval guideline


24

CHAPTER 6 APPROVAL GUIDELINE

The objective of this section is to provide factors to be considered as a last checkpoint prior to releasing the TON in

order to maintain a global standard of the TON content.

PREREQUSITE INFORMATION

The TON objective is to communicate that a Thomson Reuters Markets product is technically ready for client site

deployment, therefore, the approver needs to perform an effective role in order to meet the TON objective. Related

information which needs to be ready for reference for approver role is:

Client Site Deployment Testing requirement

Client Site Deployment Test report

RECOMMENDED PRACTICE FOR APPROVER

It is a recommendation for an approver to verify every section in a TON against the guideline in chapter 3 in

order to ensure meaningfulness of each section.

In order to achieve the communication objective, the type of TON should be selected properly according to

the purpose of the communication. For example, a NFR should be used for product obsolescence notification

instead of a TON. Please refer to chapter 4 for the communication purpose of each TON type.

The approver needs to ensure that recommended practices in chapter 5 are applied in the TON.

Prior to issuing a mandatory TON requiring client site visits, approval from the CTS Leadership Team must

be obtained, and a TOM Project Code assigned.

An approver should ensure that feedback from key stakeholders during the pre-circulation are addressed

accordingly.

Any documents containing client site deployment instructions for third party engineers should be attached to

the TON instead of providing a link to them, as some of the readers might be unable access documents via

the IME network.

When information in the TON is required to be changed for any reason, the author should provide detailed

information such as the following:

o What are the purposes of editing?

o What are the sections and information changed?

o What is the new information in those sections?

The above information will help the TON reader to distinguish between the current and previous versions

as this information will display in the TON historical page. This will help to protect the CTS engineer from

misinformation. In addition, an approver needs to ensure that the TON is not in the “being edited” stage

too long. The editing process should be completed as fast as possible.

Document Version 1.1

© 2010 Thomson Reuters. All rights reserved. Republication or redistribution of Thomson Reuters content, including by framing or similar means, is prohibited without the prior written consent of Thomson Reuters. 'Thomson Reuters' and the Thomson Reuters logo are registered trademarks and trademarks of Thomson Reuters and its affiliated companies.

For more information

Send us a sales enquiry at

http://thomsonreuters.com/about/contact_us

Read more about our products at

http://thomsonreuters.com/products_services

Find out how to contact your local office

http://thomsonreuters.com/about/locations

global product support and solutions · date of issue: global product support and solutions...

Documents