TFP Hub Configurations

This document is meant to provide a road map for the planning and implementation of TF Dataworks Enterprise solutions for customers relying on a basic shared data environment known as the TF Dataworks Enterprise hub. This document is intended to help Thomson staff understand what the Hub is, what it is for and how it can help in the rollout of various specific solution types.

The TFS Hub

The main purpose of the TFS Hub is to allow data sources to be shared among multiple customers in a properly permissioned and auditable manner. The central technology in use is Dataworks Enterprise.

The hub itself is implemented as an expandable number of boxes connected using TCP/IP virtual circuits in a LAN environment. Most of the boxes attached to the hub are dedicated to ingest or distribution of data. The hub itself in the diagram is more conceptual than physical.

Dataworks Enterprise Handlers ingest data from various TF or external data providers. These sources are made available to downstream clients in the form of Dataworks Enterprise sources. As each handlers makes data available it attaches permissioning information to the data so that downstream clients can choose whether the individual user has access to the data. In many cases, the actual sources of data might be arrays of TF data server, such as GT data. Dataworks Enterprise provides support for load-balancing between these sources using Hydra (and, later Freeway).

Some sources will initially be �un-permissioned� relying on facilities within the remote server to apply source level permissions to the source. For instance, if a client needs access to a set of WorldScope data, they may have a specialised source created for them that is hidden from all other customers. The customer need not be aware of this operation. In the long term all sources of data should be permissioned in the hub.

Internal distribution within the hub will use TCP virtual circuit technology in the first instance using standard Remote Server/Client technology. At some time in the future, the distribution technology in the hub will be based on Freeway for performance and scalability reasons and to simplify management of the hub.

The TFS Hub provides shared access to data resources.

By sharing data in the hub, we should be able to increase the reliability of data without incurring substantial additional costs.

The central tail circuit distribution technology is TCP virtual circuits supported by standard Dataworks Enterprise Remote Servers. Dataworks Enterprise Remote servers provide configuration options that allow them to show/hide or rename Dataworks Enterprise sources according to groups depending on peer connection addresses. At some time in the future, this data will be centralised into the permissioning server to ease the cost of implementation.

The Remote Server that provides the tail circuits are either shared between customers or are private to them depending on customer requirements, cost, ease of implementation, etc.

Apart from ingest and tail circuit technologies the hub supports a central permissioning server (and its associated SQL Server database), This server (a hybrid Dataworks Enterprise handler) holds permissioning information for accounts that access the hub. NOTE: this may not the same as accounts that may be accessing data for management and efficiency reasons. Dataworks Enterprise permissioning system is a fully distributed permissioning system that can integrate various permissioning models in use in TF.

Customer Configuration One

The simplest customer configuration would be entirely hosted within Monmouth house. This solution would either be providing some external API (XML/HTML) or might form part of a hosted web/wap solution.

Configuration One: Implemented and Managed in our Hosting Site

In this environment, the remote server(s) may be either shared between customers where bandwidth/CPU resources allow or may be allocated on a per customer basis. Downstream clients accessing the shared data must be permissioned appropriately in order to use it. This might involve one or more user accounts within the central permissioning server (depending on the particular roles for those accounts) and may have oone or more downstream accounts associated with users of the shared data. Where there is a one to one mapping between roles and accounts, the permissioning information will be held on the hub permissioning server. Where there are many downstream accounts connecting to a small number (or one) upstream account, the architecture allows the use of a Permissioning Proxy that translates from one to the other.

In some cases, the data provided may be �summarised� in this configuration, depending on customer requirements. This will be achieved using Dataworks Enterprise Snapshot solution or something similar.

This type of solution is managed and maintained by central systems support staff such as TICCS FM, TICCS Real-Time Support and WAN Support.

Customer Configuration Two

In the second configuration, some part of Dataworks Enterprise system is installed at the customer site. Again the permissioning is distributed to the host on the customer site (which probably has implications for SLA boundaries). As with the first case, data is access from the Hub with the appropriate permissioning information.

Configuration Two: Solutions Implemented at the Customer Site

In this case, central systems are managed and maintained as they are for the first configuration. However, the equipment and software at the customer site may either be managed by the customer or by field services depending on costs and customer requirements.

As with the first configuration, there may be use of the Permissioning Proxy at the customer site, to handle variations between on-site and central user accounts or simply to provide localised caching of permissioning information.

As with configuration two, the data provided may be �summarised� in this configuration, depending on customer requirements.

Customer Configuration Three

In the third scenario, the customer demands non-shared data (or we decide that for implementation reasons this is more appropriate). Generally, for customers in this category we will endeavour to move them to configuration two or four depending on requirements.

In this case, some private data resources are made available to the customer possibly with the addition of hub-based shared resources. Where the latter is the case, the customer must be permissioned to receive that data. The private resource may or may not be permissioned as appropriate depending on the downstream requirements of the customer. For instance, if they have a permissioning requirement for heir users then the source has to provide the permissioning information at the point of ingest.

The management of the central systems will, as usual, fall into the respective groups who maintain Monmouth systems, e.g. TICCS FM, WAN Support Team, TICCS Real-Time Support, etc. The support for customer site systems will be provided either by the customer or by field services depending on requirements.

Configuration Three: Some Customers Demand Private Access to particular data sets

Customer Configuration Four

In this configuration, some private data is made available directly on the customer site. This may be because the data is external to TF or it may simply be a matter of delievery costs and bandwidth requirements. The most obvious case is the real-time distribution of GT data. This may be better provided using broadcast satellite to the customer site rather than distributing the data across the normal circuits.

Configuration Four: Some Data needs to be integrated at the Customer Site

It is likely in this case that there is a back path circuit for the delivery of other kinds of TF data, e.g. DataStream, Intraday pricing, using the standard RemoteClient/Server technology. If a client demands this level of support, it is likely that they will have a number of central system accounts and a larger number of user accounts downstream. The Permissioning Proxy will resolve these issues at the customer site.

Support for the customer site systems will depend on the requirements of the customer, the location of the SLA boundary and the needs of TF, but would normally be provided by field services.

Support Issues

Dataworks Enterprise Support Team are relying on field services to provide support for:

Support for Dataworks Enterprise software should be provided by specially trained individuals such as Thierry�s group (assuming the appropriate FSA accreditation) and as a second or third tier by Dataworks Enterprise Support.

Support in Monmouth house would continue as at present.