The following is the first of a two-part excerpt from Streaming Media '99. The focus of this discussion, which took place on June 30th in New York City, is best practices for successful deployment of audio and video on a corporate intranet
Panelists: Brian Heukroth, VP, Marketing, Starlight Networks, Inc. (moderator)
Roger Dean, VP, Morgan Stanley Dean Witter&Co.
Richard Lang, CEO, Instant Video Technologies, Inc. (IVT)
Paul Boudreau, Program Manager, Windows Media Technologies, Microsoft Corp.
Daniel Agan, VP of Worldwide Marketing, Excalibur Technologies Corporation
Brian Heukroth, VP, Marketing, Starlight Networks, Inc. (moderator)
Daniel Agan: I think I'll leave it to my colleagues here to talk some more about the practical and technical issues, but, from my standpoint, the three or four best practice tips that I can give are as follows:
1. The most important one that we've seen with our customers is: you must have a clear idea of what you're trying to achieve when you deploy audio/video on your intranet, be it for training, be it for support, customer relations, for supplier relations, and of those things, have a very clear idea where it is you want to go; and then the road that will take you there becomes somewhat more clear, I think.
2. The second point I would make is that the thing I see many organizations struggle with initially is trying to simply get their arms around what they have. A lot of people do streaming media and then they wish they had some way to archive it, and capture it, and be able to reutilize it, re-express it, repurpose it. So that's another major consideration. Do you want to save this material, do you simply want to stream it? If you want to save it, how are you going to archive it, how are you going to get your arms around it?
3. The third piece--and this is getting a bit more difficult--is how do you make it much more intuitive for people to access this material, if it's at all daunting to comb through material that you already have, or to gain access to material that you're going to be streaming, then I think the natural reaction of, of users is to throw up their hands and walk away. So there needs to be a very intuitive way for folks to gain access to this, either through a particular place where they go on your intranet, or through very clear communications throughout the organization.
4. And then the final one I would add is to have some fun with it and to make sure that you really exploit the power of what is increasingly the migration of the most pervasive medium we've seen in contemporary times, and that's the notion of video, into an environment where it's literally accessible to anyone on your corporate intranet and, you know, the notion of being a couch potato in front of the TV at home is not really true when you bring it into the environment, you can really make business use of it, you can leverage your capabilities and make folks more informed, more effective, more efficient, and better able to do their jobs.
Brian Heukroth: Speaking of fun, we'll turn it over next to Paul, whose company has put all those lovely little cows in all of our boxes, so you're obviously having some fun with it.
Paul Boudreau: One of the experiences I've seen in a lot of corporations is, we've got one group; usually the multimedia group, or one champion within an organization, that's trying to implement streaming media within a very large corporation, or even a smaller midsize corporation, and they're having a lot of difficulties facing the IT department. For the most part, IT departments have got stable networks, or they're struggling to get their networks stable, and it's a very difficult sell to IT. They immediately think, they're going to come into their organization, start streaming 400, 500 kilobyte-per-sec clips and bring down the entire mission-critical network. The way to handle something like this is to start extremely small. Try not to go in there and pitch the big picture, how you're going to enable instantly corporate-based training, Internet streaming, CEO communications to the masses, although that tends to be the largest, or most popular initial deployment project. The thing that we find, [is] it's not the technology. It's usually selling it to the staff at the higher levels of the corporation, and justifying the benefits of streaming media. Now, I'm sure most of us feel we all know the benefits of streaming media. We don't know where it's going, but we're familiar with what we've done with it, we know it's extremely useful, it saves us a lot of money, it has a great way of transferring knowledge to an organization; but the sell is difficult to IT.
1. Start small; tell them you want to do trials on small segments, you don't want to start with the entire corporation; you want them to basically take a network monitoring snapshot before you start your pilot, to find out how much available bandwidth is there now; most corporations are not multicast-enabled to start with, so usually multicasting within an organization is the best and most effective way to deploy a technology, but unfortunately there's usually a long ramp-up time to enable multicasting in a network, so you need to do unicasting, and that's going to kill you. So you have to start very small.
2. Number two is the scope of your project. If you have a specific project in mind, keeping it small in scope, try and get your hands around it, and very clearly, as my associate here to my right said, define the scope of the project. Don't be ambiguous about it. Try and label as much of what you're trying to accomplish as clearly as possible. Put it down on paper, make sure it's justifiable and in its limitation plan. Otherwise you're going to have a difficult time narrowing that scope down after you've deployed, because it's going to waver all over the place, all the organizations once they're turned on to it, within your company are going to want to play a part ... Define your scope, keep your timeline, and keep your roadmap.
Richard Lang: One of my first tips would be to really take a look at general trends in technology, and two of those that I touched on earlier have to do with what is it like to stream? Keeping in mind that streaming was created for an environment where there was constrained bandwidth, and where storage was expensive, the whole notion was, how do we get around these long download times? And streaming's done a great job of that. And it's done a great job of whetting everyone's appetite for what it can be like to have a video network; but think in terms of where are those trends today, and where they are going in the next one, five, 10 years. And if you go from the premise that there's going to be cheaper storage - it's already cheap - and more and more bandwidth, you want to look at the solutions that you use and in particular the way in which you stream, with regard to that environment.
And ask yourself, is streaming as we know it today fully realized? I would offer that it isn't; that there's another step involved, and that step is being able to take advantage of those two trends by a) when you have the bandwidth to do so, don't let it escape unused, be able to, to send content, to stream it, faster than it's being looked at, faster than it's being consumed. Have it reside locally, on the client-side cache, because that's the cheap resource, that's the cheap network resource. So, first bang for the buck, is that you're going to get, in a sense, your network capacity goes up by the aggregate of all your inexpensive client-side cache, and the other big piece that you're going to get, is by preloading content and having it viewed from your local cache, you're going to isolate your client from what's happening on the network and one of the points that's been touched on here has been [that] your IT person is terrified of putting video on the network because it may bring the network down, well, once the content resides locally, it's isolated from that network. The server's done. The server is free to go back to its other requests for video. So, doing that requires being able to stream the content at a rate faster than it's being consumed. And that's currently not the way streaming operates.
The second point with regard to the tips really has to do with architecture. And that's somewhat related to what I've just said, but, right now the basic architectures that are in place to stream video are in a sense naïve in that they don't offer, for instance, no single point of failure. It's typical that your server goes out, and that's the end of the game. There may be a reconnection that can take place. There may be strategies and methodologies to get around what happens if a server goes down, but typically that involves overprovision of your networks, you're using up even more resources. And, it doesn't have to be handled that way. And so, to have an architecture where you can have servers go down, and if they go down, again, going back to my earlier example of watching and listening out of client-side cache, you have the opportunity for the server to be reconnected, or, for the client, rather, to be reconnected to a different server that's got that content. And that new server can essentially catch up, because it can move, it can stream at a rate faster than it's being consumed, so it can retop the client-side cache. And once again, the client has had no interruption in the view. So you haven't had your network crash, you haven't had an interruption in the view, the quality's been maintained, but that has to be architected in just to finish up on looking at the trends going forward, make sure that the architecture that you're selecting is one that is not at the end of its life cycle, but rather is one that's at the beginning of its life cycle and will take you into the next century.