IMD Interview: Reuters' Buford Smith Talks About SDS3

Reuters Holdings PLC announced SDS3 in 1989. The Ku-band satellite data delivery system -- part of Reuters' Integrated Data Network -- was slated to carry Reuters' entire database of securities.

The system was seen as a stepping stone into the then- attractive North American retail brokerage market. Indeed, Reuters announced a number of retail-oriented products that were to be supported by SDS3 but that never made it to market. SDS3 has since been focused on overseas markets with lower-quality terrestrial communications.

Buford Smith, senior vice president of Reuters' information product technology group, was prime mover behind the SDS3 project. Under a recent reshuffle, Smith finds himself with a new boss -- executive vice president David Ure. He talked to IMD about the status of SDS3, its past and its future.

Smith: I have a different person to report to, so that has changed for me personally. But the development organization still has the same mission and is still doing the same things. The field organization was revised a bit and so our clients, our internal clients as it were, are a little different.

Smith: We are pretty far along. It has been a program the company has had an interest in for quite a long time and has been working on in the background. We are in the process of doing field trials at a number of locations right now. I think we probably have something in the order of 50 sites that have SDS3 delivery.

It's probably important to say at the outset that SDS3 is not a product. That's a point of confusion with a lot of people. It's an alternative delivery system. It's one aspect of IDN [Reuters' Integrated Data Network high-speed communications network]. I don't think we've ever seen SDS3 as being the only way we would deliver data to clients. It's always been a view that there would be a mix of facilities that are used to get data to a client site.

But, at any rate, we are in field trial. We have installations in Spain, in Portugal, in eastern Germany and there may be some others. We have a trial in Indonesia and soon we will be testing in China as well.

We've concentrated in the beginning on places where it is difficult to get a communications line or where the communications facilities aren't particularly good in terms of error rate quality for high-speed services. Those are the places we have the most obvious advantages in and they seem like a good place to test.

But we have tested in some other places as well. That's coming to an end and we are in the process of negotiating internally through our quality process. We've been doing extensive tests to compare performance via SDS3 with performance over conventional telephone facilities. Prior to that we'd done lots of testing on availability, basic quality of the service. So we're pretty much coming to the end of that process. From the European test sites we're currently earning revenue, and we'll be expanding further soon.

Smith: The principal part of SDS3, the uplink facility, was developed originally in Asia; we had a number of satellite uplink developments we standardized on for our Asian broadcast system. That's the piece that extracts from the database what we want to transmit via satellite or via broadcast and puts it out. So there is a series of releases for that, which will go on for quite a long time -- as long as SDS3 is an active system -- basically increasing the speed, the operator interface responsibility, that sort of thing.

At the receiving end, the client site, there is a device that receives the data, maintains the local database and services the terminals, their inquiries and updates. So that has a schedule of releases. We have had two different teams working on that part of SDS3 for quite some time. And in the past year, we've merged those two operations; we felt that it is now time to have just one client-site system. So that, too, has its release schedule queued up for quite a long time and I think that will be a development program in a number of years to come.

Smith: The overall concept behind SDS3 is that over time it is likely that we are going to need greater and greater bandwidth to deliver services. That doesn't necessarily imply satellite delivery, although that's usually what comes to people's minds. It certainly can be broadband cable as well. But we have done most of our development around satellite delivery. We also want to look at high-speed terrestrial delivery as well.

But it is a broadcast service of a very high data rate signal. The idea is to consolidate all the update traffic from all exchanges around the world into a single pipe that would carry all of our editorial output; to combine that in to this super pipe and transmit that to as wide a geographical area as is possible.

Theoretically, if the laws of physics hold, from three uplinks you can cover the entire surface of the globe. In a practical way, you probably need only a slice of that. At any rate, the idea was to make this available to as much of the world as is possible. Conventional facilities -- their availability and quality -- vary a great deal from country to country, from location to location. So SDS3 is either very badly needed in some locations or not so needed in others. But the idea is to try to improve the quality, to try to improve the ability to get rich data types, to get a very high rate of update out to the client site directly.

One of the nice things about SDS3 is that it eliminates some of the intermediate infrastructure that is associated with conventional delivery. Whether you are talking about the Reuters network or a competitor's network, generally there are a lot of common points in the way those communication networks are put together. And they generally have regional sites and district sites and so forth, and all those are linked together. And the Achilles heel generally is the local loop itself -- that's where the lowest availability portion of the whole network is. SDS3 leapfrogs all that. You go from a central technical center directly to the client site. So it has the promise of improving quality and availability.

Smith: No, I don't think so. We've had satellite delivery in North America, but we've had satellite delivery in previous versions of SDS in Asia as well. No, I don't think there is anything about the U.S. retail brokerage market that particularly caused us to try to create this system. It's obvious to think that's a way to reach those guys. But, quite frankly as you know, that particular market has never been of prime interest. It's there with a lot of keystations and it's interesting in that respect. The margins associated with that business have always been very, very low. So I think, we generally have felt there were other opportunities for us and other things. SDS3 is very much oriented toward mainstream products that we have and the customer base that we have right now; trying to serve them. If we can get some additional business, that's great. But I don't see U.S. retail as a focus of SDS3.

Smith: Yes, I think that's probably an accurate observation. It's ironic because a lot of the development for SDS3 has been done in the U.S. Right now, North America is probably doing the least [with SDS3]. But I think that's explained by the fact that within North America we're blessed with very high quality communications; they are available everywhere, they're improving every day, they're relatively cheap if you consider what is charged for communications around the world. So it's not a desperate need that we have here. People in our North American operation are very up on SDS3 and its capabilities -- and because responsibility lies here for Latin America as well, they're very much involved in the Latin American implementation, which will in fact use SDS3 fairly extensively. It will replace SDS2 in Latin America. So they are quite involved, but they don't have the same pressing need that some others might have.

Smith: There are some domestic products that are on it and there are some global products that are on it. It's being used particularly in the field tests to offer high quality communications to some locations where communications have been difficult. We can expand on that some more as soon as all the test results are in. From what I've seen so far it looks very good, very promising.

Smith: No, there has been a lot of testing in North America, but there is none that I'm aware of at this particular moment.

Smith: Yes, I heard the same thing.

Smith: No. We have had some involvement with Dean Witter on SDS3, as you know. They had a number of sites that actually received the SDS3 transmissions, so we had some ongoing testing with them. But I'm personally not aware of any program going on with Edward D. Jones, but that's not to say that there wasn't. It could be that we are delivering news to them, which they are then uplinking over their own system.

Smith: Once again, SDS3 is simply a delivery system. So we're constantly looking at new products. We've looked at some superlow-cost high-grade services. I think they may be in that particular area that we were talking about. But there wasn't anything particularly SDS3-related about them. They may have used SDS3 as the data delivery mechanism. But that [a retail branch system] is certainly not a product that's under current development.

One of the good things about SDS3 is that it allows our local business units to define local domestic products. In fact even in the field trials some of that is going on. Because there is a tremendous amount of content available in the broadcast and because there is also a back-link capability from the client site, local domestic services can be offered over the service as well as the global products. I think that will be utilized quite a bit in the way various business units within the company roll out a service.

Smith: No, it's not designed as a superlow-cost service. What we attempted to do was to target it more at higher performance. If you think about carrying every update that there is as a goal, plus all of the news, the thousands of stories our reporters generate -- making that available on a small dish at every rooftop is a pretty ambitious undertaking. And that doesn't sound like a superlow-cost service. When you look at it on the larger scale, in terms of central system cost, in terms of cost at the client site, in terms of what it costs you to deliver equivalent speed and availability, then it's quite economical. But no, it's not at the low end of the spectrum in terms of performance vs. cost; it wasn't intended as that sort of service.

Smith: That's certainly the goal. As we've come along with the development, we've put more and more into the data stream and we'll continue to add things to it. It's a pretty full subset already, but it is a subset. That's one of the reasons why we have the back-link capability. What we want to carry at the local cache are the high hit rate sort of instruments. If a particular office has seven or eight terminals and if you look at all of the instruments that they request information on, you'd be skewed very much to a small set. We want to make sure that they get absolutely quick response on those.

If there is something that they need that is not carried in the local database, there is always a method to get to that information quickly, as well; as quickly as we deliver it over terrestrial network. And then there are some services -- both presently offered and that could be offered in the future -- which are essentially two-way in nature, where you need to go out to the larger network. So one of the things that has occurred in the SDS3 development is the addition of this two-way capability to what initially was mostly broadcast.

Smith: Well, that could be an extension of it, but probably not. Our Company Newsyear product, where we have a year or so of historical text, might be a better example. You probably don't want to transmit all of that to the subscriber site but an SDS3 subscriber could gain access to that or anything else we have in the way of historical information.

Smith: Transactions have their own separate network, primarily for performance and security reasons. Maybe at some point we are going to integrate that but not now. That's not a real focus at this current moment.

Smith: We're beginning to see a bit of a return in that we have a few sites on it already. As soon as the trials are finished and the necessary internal approvals are received then I would think that we'd deploy it more. But as I say, I don't think we are looking for 100 percent of our subscribers being served by SDS3. It'll always be a part of the total solution.

Most of the resources are concentrated on the uplink facility, concentrated on the client-site cache device. They're a pretty small team, actually. I guess it's a truism in software development that the optimum team size tends to be relatively small; when you have too many people it becomes counterproductive.

So, there are two relatively small teams that work on those two components. There has been a fair amount of project management trying to pull it all together -- all the million and one details it takes to put together an overall system. We've used outside contractors a good deal and so they've certainly deployed some resources as well in the development area of these two key teams and in project management.

Smith: No, I don't think I could. But as our development projects go, it's not a huge expense. We have more resources deployed on other things, I would say.

Smith: Yes. The back-link facility is really nothing more than a terrestrial IDN facility; so anything that can be done on a current Reuter Terminal can also be done on a Reuter Terminal connected to SDS3.

Think about the overall architecture for a minute. You're broadcasting out to a controller at the client site, which maintains the local database. It has that broadcast coming into it with a high update rate. It also has a connection that can go off to the various central facilities, main technical center; a conventional two-way channel. And that can either be present or not present depending on how or what business unit wants to deploy it, what services may be offered. But I think most will probably have this back-link facility as we call it. Any retrieval request is satisfied first out of the local cache and if the request is for something that is not in the local cache then it will go on to the conventional facility and is treated just like any terrestrially based terminal.

Smith: You have to have a two-way channel, either terrestrial or satellite. You can provide service out of the local cache alone, but you don't carry everything that Reuters has in the broadcast. The Company Newsyear is a good example of that. Also, we don't put some of the time-series historical data in the broadcast link. So if you want to, in your local country or region, offer a service to a client that has access to those [historical items], then you need this back-link facility as well. So we've essentially allowed them the traditional IDN terrestrial link into the same server so that you've got access to two paths.

Smith: It is. It's specific to SDS3, for high-speed updates. It's going to be a very important component in our future deliveries, but if there were no satellite components involved then you wouldn't use this particular box, the AMS as we call it. It's essentially a 386 with a lot of disk and a lot of main memory. It's souped up, it has some co- processing machinery to give it some additional capability.