|
|
| ||
|
|
|||
Buzz bashing patrol To protect and serve. That's the motto of the Buzz Bashing Patrol. For this special roundtable interview, we pulled together an elite group of analysts and consultants - elite because they are Network World columnists (for one thing) - and asked them to take a stand on some of the most-talked about issues in the IT industry today: Gigabit Ethernet v. ATM, Windows NT v. the world, electronic commerce, intranets and more. They are the Buzz Bashers, hype-fighting action-figures whose mission is to help you untangle all the acronyms and make better decisions. Your Buzz Bashers are Tom Nolle, president of CIMI Corp. in Voorhees, N.J.; Scott Bradner, a consultant with Harvard University's University Information Systems; Christine Heckart and Danny Briere are director of broadband and president, respectively, of Verona, N.J.-based TeleChoice, Inc; Mark Gibbs, president of Gibbs & Co. in Ventura, Calif.; and Dave Kearns, a freelance writer and consultant based in Austin, Texas. 1. This question has to do with the confusion many readers express in trying to choose a LAN backbone strategy. There's Gigabit Ethernet, ATM, Fast Ethernet, IP switching - in short, no shortage of technologies, but no clear directions. Cut through the hype about all these offerings and lay out the real issues network managers should be considering in planning for the next-generation network. Nolle: The biggest issue is 'incrementability'. Few companies are going to architect their LANs based on central planning decisions, whatever network managers might like to think. Projects funded by business units build networks, and that means pieces of the network move forward as local project activity justifies the move. The best backbone technology will be one that can be added to existing networks without creating a lot of ripple impact and ripple cost. That means that ATM or Gigabit Ethernet can work, as long as both are about the same cost and as long as ATM's benefits don't require a major network shift in the ATM direction. Bits for bucks is the game, now and forever. Gibbs: The real issue: Can you afford it now? To go for a major implementation now is most definitely to be donning the leather helmet and goggles of the test pilot. In six months to a year, the key issues of this new era of high speed backbone choices will start to become clearer: Which standards matter and which don't; which vendors will be stable (these two in combination are probably the biggest put-off to early adoption); and how problematic the technologies will be from the viewpoints of implementation and on-going management. That said, if you are in a large organization you should be trying this stuff out - looking for the opportunity gains that you live with and afford. Heckart: There are really only three real issues that need to be considered in this type of purchase: cost, performance, longevity. What is tricky is that we tend to think about these issues as having absolute values and they don't - everything is relative to the customer's environment, goals, applications, budget, etc. What's 'good enough' for one company, or even one set of users, doesn't hold water for another. The trick is to figure out what 'good enough' means and implement the solution that is cheap enough, performs well enough, and lasts long enough to meet your current and foreseeable needs. The problem faced by many users is that they try to figure out what's 'best'. Best changes every week based on their changing needs and the latest and greatest technology. Best never exists and certainly can't be implemented because by the time it is implemented, it isn't the best any more. Briere: You know, too many managers are purists and continue to look for homogeneous answers when a mix is going to be the result. In any company, you might find ATM, Fast Ethernet, and Ethernet, or some other combination, because different sites and groups are going to have different needs. You don't buy Pentium class PCs for everyone in the company because everyone doesnt need one. You also don't need SONET to the desktop. The most important thing to do is let the requirements drive the solution and not get hung up in the latest and greatest technologies. Kearns: The majority of network connections are Ethernet and will continue to be. There s no gripping reason to go to a different technology for the backbone at this time. Ten megabits to the desktop and 100M bit/sec on the backbone works, and works well for many, many installations. Planning to add Gigabit Ethernet as the backbone with 100M bit/sec moving down to major trunks and, eventually, to the desktop seems a reasonable approach. The 'gotcha' here is that for many networks, bandwidth isn't the bottleneck. Server/router/switch throughput, disk channel, bus speeds, local node buffering, and probably five or six other things all need to be considered. A pipe that s too fat simply wastes resources. Bradner: I'd say the biggest challenge to network designers is the partial knowledge and strong convictions of their management. All too many decisions on the future directions of corporate networks have been based on broad generalities rather than an analysis of the actual needs of the existing network community. Someone from management reads the pronouncements of one of the big consulting companies - 'the answer is ATM (what was your question?)' - and decides on the future direction. The real need is to do a technical analysis of the specific networking requirements and design based on the results of the analysis. Many technologies can prosper because not all networks are the same. 2. ATM v. Gigabit Ethernet: Is this a real battle or nonsense? Nolle: It's really a battle of planning paradigms that happens to be represented as a battle of technologies. The Gigabit Ethernet paradigm says 'buy bandwidth instead of bandwidth management because bandwidth is cheap enough to oversupply your network'. The ATM paradigm says, 'bandwidth management is important; capacity can't be taken for granted, so you'll need a network architecture that can manage capacity for you.' Cost will probably decide the issue, but there's no question that buyers will feel a strong attraction for the simplicity of the Gigabit Ethernet approach. The problem we have with the 'battle' is that we want it to be technical, based on features. It's not that way. Gibbs: Yes, it is real. And the reasons are that lotsa money has been thrown at the former and that lotsa money could be made from the latter ... if the latter is that much easier and cheaper than the former. The ATM vendors don't want to see their investments wiped out and over the next six months they will all be doing their best to hurl stick and stones at the gigabit boys. Heckart: What's nonsense about this and other ATM-related topics is that the message get broadcast out to the masses when it's only applicable to the networking elite. This is a real issue for a very few people. Network World and vendors alike should do a better job targeting messages to appropriate audiences and defining qualification guidelines that end users can apply so they quickly understand whether they belong in the line of fire or are better off watching from the sidelines. Gigabit Ethernet has the high ground, the bigger army, a better supply chain, and nearly everything you associate with what's necessary to win a war. ATM may have somewhat smarter troops with slightly fancier weapons but better numbers and positioning usually win. For any buyer that doesn't need the extra capabilities provided by ATM - namely guaranteed QoS (quality of service) - the easiest solution is just to avoid the battleground and use what's most comfortable and what's 'good enough'. Unlimited bandwidth can't fix every network problem, but it can fix most and Gigabit Ethernet starts to approach unlimited bandwidth for many environments. For those companies that need more than just bandwidth, or need more bandwidth than Gigabit Ethernet can provide, then ATM may be the better solution. Briere: It's the classic elegant versus entrenched battle. If people are thinking about it in the same breath, then it's a battle. If you win enough battles, then you win the war. You're going to see a lot of ATM implementations by the telcos into the home and probably into the office as well. Carriers like Ameritech, PacBell, SBC and BellSouth have already stated that ATM to the home/office is important, vis--vis their broadband deployment plans. So the question becomes how far will it go into the home/office? I don't think anyone knows the answer to this, but both Gigabit Ethernet and ATM will be important in both LAN and WAN implementations. In the LAN alone, you have to ask what a LAN is anymore. If you have ATM into the home feeding five devices, is that a home LAN? Yes, probably. So ATM will be more pervasive than most people think, if only because of the home/SOHO telco-driven implementations. Kearns: Its a real battle in a marketing sense, but outside of the hype market its a no-brainer. Gigabit Ethernet will be the dominant technology, for the same reason 10M bit/sec Ethernet dominates token ring and 100M bit/sec Ethernet dominates FDDI. More network managers understand Ethernet and have a high degree of comfort with it. Bradner: In the campus backbone network it is a real battle. It is quite easy to figure out that Gigabit Ethernet will easily and cheaply (relative to ATM) meet most, if not all, current requirements for campus backbone networks. The only area where there is a significant question is that of quality of service (QoS). But few of today's campus networks actually use any QoS capabilities because of the existing application set and because the network link to the desktop is almost all Ethernet or token ring, which do not support any QoS functions. It is no battle in the WAN arena. Gigabit Ethernet does not go very far (3 Km max.) and requires private fiber. Both of these limitations mean that there will be little wide area Gigabit Ethernet and I'd expect ATM to be the major player, at least for high-speed (greater than 45 bit/sec links). I doubt it is much of a battle in the building backbone arena either, with Fast and Gigabit Ethernet wiping out ATM as a player. 3. Pundits are talking about network-centric computing, meaning we'll shift from these heavy apps-laden desktops to thinner clients running Java and ActiveX applets. What's wrong with this story? Nolle: It's crap. It's nothing but a tired rehashing of the old diskless workstation concept. Dumb terminals can be replaced by semi-dumb network computers. Smart PCs won't be. Gibbs: Nothing is wrong with the story. But there are some problems with it. Migrating to thinner clients is complex and it will take quite a while for the leading application vendors to make any significant inroads into migrating their products to the new world order. And the NC thing is a nice idea but a little short on practicality - you don't dispose of an installed base in less than about three years, by which time the next generation of desktop applications will have come along. Unless Microsoft can't keep up the upgrade pressure, there's little reason to assume that IS will get so comfortable and complacent with PC software that they will have the time and will to go down a different path. Network computers are not the ultimate fix to improve efficiency and costs that some of the pundits would have us believe. Not all the problems of dealing with fat applications go away. For starters, NCs will demand much greater network bandwidth than current applications and the increased server processing and storage demands will be huge. Ya gotta spend the money ... Also, security, security, security. We don't know what the security implications are of either Java applets (as distinct from Java programs, which have nothing in the way of security enforced) or ActiveX, although the latter has a far less convincing story to tell than the former. Heckart: I'd rather say what's right with the story. We all know that the problem being addressed is a real one. We're tired of installing this year's software version only to have every last inch of disk space eaten up on our computer that last year was totally state of the art - especially when 90% of the functionality in those zillion lines of code aren't even used 98% of the time. Downloading what you need when you need it is a great idea. The critics in this idea seem mainly to be of two camps: the 'something-to-lose' category and the 'give-it-to-Mikey-he-hates-everything' category. Those not already positioned to benefit from network-based computing, or already supplying the competitive solution, can find lots of bad things to say about it. Just like we can find lots of bad things to say about the way it's done today. The other naysayers are often consultants, since we make money telling people why things won't work, or those that criticize every new idea until they see 'proof' that there is 'demand'. Every new idea has a lot of bugs that have to be worked out and the NC is certainly no different. What's exciting about NCs is that they could reshape the way networks are built, software is sold and network services are defined. And probably all for the better. Briere: I think people are overdramatizing this whole battle. We're working with some clients who are looking to create the next generation of fax devices for IP transport. These have elements of what you are talking about. Do we consider them 'thin clients' or 'slim PCs' or anything else? No, we consider them fax devices that solve a specific solution in the marketplace. Again, elements of a device can have different characteristics and the penchant for labeling things one way or another is annoying. The network is going to be centric for some tasks and non-centric for others. Taken as a market whole, one will 'win' out, but is that really important for a given user looking to solve specific needs? We've seen a global retailer evaluate NCs and a souped-up smart phone for the same task. Is one more net-centric than the other? It depends what you need that device to do. Kearns: Today's programmers don't understand tight code anywhere near as well as yesterday s did - say, 10-15 years ago or longer. What we're liable to see are today's apps broken into many, many modules. Users will spend lots of time waiting for each module to load across the net and will reject the technology. Bradner: There is not all that much wrong with the story other than it seems to assume an homogenous requirement domain. There seems to be some deep need to find one answer to all possible questions -- maybe because reality is too confusing. Clearly there are lots of places where the existing applications are dumb terminal or X-Window terminal-based and the thin-client/network computer model will work just fine. But there are many other places where the users are doing just fine doing local work on their local computers where the fit is not nearly as good. 3a. Can applets be small, yet powerful? Nolle: Sure, if you believe that all the power of modern Pentium and RISC systems is really a cynical plot on the part of the chip vendors. If an interpretive language can build a superior application, a compiled language ought to do better. Java is still a computer language, remember. It doesn't do anything the hardware itself can't do, and any language that can exercise the hardware features equally well would do equally well. Gibbs: Yep. Distributed processing, messaging, informational functions, etc., are all hugely valuable applet functions. Heckart: Who cares? The better question is: Can small applet's deliver adequate, or even powerful, performance to a user? As long as the answer to this is yes - perhaps as a result of combining lots of applets - then all is goodness. I think applet's should have been called 'ant-lets'. Like an ant, one little applet is pretty powerful per inch of body weight or code lines. And they work great in groups. Briere: I hope some advertising firm did not get a lot of money to coin the word applet because I'm already tired of it. But the question again presumes a broad sweeping conclusion for all applets. If you need an applet to do a specific thing for you and the applet does it, then I'd say it's powerful. If you are trying to cram a full application into an applet or something as large, then I think you're going to be disappointed. Kearns: Sure, a small applet can do one (or two) things very, very well and can be used in a number of different applications - a spell checker, for example. 4. Another term making the rounds these days is quality of service. What are the key QoS elements that network managers should be concerned about and how should they be working toward achieving them? Nolle: QoS is actually pretty well defined, even if everybody doesn't agree that's so. Peak and average data rate, delay and delay jitter, and discard or error rate are pretty well accepted as the key parameters. The question isn't what QoS is, it's what do you do to get it. There are two choices; manage capacity or buy more of it. The network manager has to figure out the cost of each approach and balance them, but the manager also has to remember that resource allocation is like taxation - you've got to rob somebody to give to somebody else. That's why just buying bits per second is so attractive an option to users. Gibbs: The Key elements of QoS are uptime - 99.99% ain't good enough for real business critical applications - and error rate. One in 1,000,000,000 bits ain't good enough for communications. Also, support, which has to be provided 365 X 24 with a maximum of 10 minutes before talking to a technician. Heckart: This problem of defining what QoS means is going to get much worse before it gets better. Unfortunately, many service providers still think that defining meaningful QoS involves performance metrics that take a Ph.D. to understand and a protocol analyzer to prove. So what's the benefit to the end user? Sprint has the right idea in delivering predefined service qualities that map to specific user applications. While the model can be improved upon, all the providers need to remember the KISS principle (Keep It Simple, Stupid). What most managers are concerned about is network availability (up time), response times and throughput. In some applications, like real-time voice, you can add the variation in network delay to this list. What should concern managers most about the past definitions of QoS is the near impossibility of proving whether you're getting what's promised. The ideal provider makes the QoS easy to understand, easy to measure and includes an automated and meaningful penalty for non-delivery. The good news with QoS is that it will help users to distinguish between different services to better understand how frame relay, Internet service, private lines, and ATM compare against each other for meeting the needs of a location or application. Today, it is hard to tell which service is really better or worse in a given area. We can make logical guesses, but there is no service QoS on each to help us validate those guesses. As QoS definitions mature and forum bodies look at setting guidelines for measurements, comparative shopping for the best value will get easier. Briere: Achieving them? I must be one of the ones confused here. I think of QoS in a ATM/WAN type of way, where select applications have different access to different resources depending on what they are trying to do. Network managers will need more and more to quantify their needs in order to take advantage of QoS. This goes back to really understanding what each site and application requires, recognizing that no single solution is going to win out. Kearns: To the user, QoS means 'can I do what I want, when I want to.' To the net admin that translates to access, throughput and directory services. Access - 100% uptime for all services via clustering and redundancy. Throughput - Predictable throughput, all the time, any time. Directory services - easily locatable objects and services. Bradner: This is a very old story, going back to at least 1964 and the first discussions about the idea of doing packet rather than connection-based data networks. The traditionalists have been decrying packet-based networks ever since. For years, but thankfully no more, IBM speakers claimed that you could not build a corporate data network using TCP/IP because it is based on individually routed or switched packets rather than being connection-based and the corporate network needed QoS which they claimed would only work with connection-based networks. There are three types of QoS that are reasonable to talk about: probabilistic QoS, where there is a high probability that there will be enough network and server resources to get the tasks done in the required time; instance of application QoS, where specific resource reservations are made for each individual IP phone call or other resource demanding application when it is run; and class-based QoS, where network uses are divided into classes and traffic for the classes is handled differently by the network. Probabilistic QoS is where most networks are today and that works quite well in bandwidth-rich campus environments. I'd vote class-based QoS as most likely to succeed and instance of application QoS as a pipedream with far too many scaling, authentication and accounting issues to succeed in the real world. 5. Back on thin clients for a moment: We have NetPCs and NCs, each promising to reduce network/systems administration costs. Will they really provide the big savings people expect or will they wind up costing more on the network and server side? Nolle: Stockpile them next to the diskless workstations. Turn them into space heaters or attractive high-tech metallic collages on concrete pedestals in front of headquarters. NCs are replacements for dumb terminals. NetPCs are just hype. Gibbs: The wise NW reader should tread carefully. There isn't yet the catalog of applications and tools that make for a convincing story and the infrastructure upgrade costs are significant. Plus, most IS shops will have two or three years before they have fully amortized their existing investments so leaping into the fray is probably not an option for more than trial systems. That said, trials with suitable victims ... er, guinea pigs...er, users will be invaluable. Definitely a market to watch but I wouldn't recommend getting too excited until there's a realistic story with applications and NC/NetPC system (not just unit) pricing. Heckart: I seem to remember people asking similar questions in the early 90s about the benefits of LANs and whether they'd really save money compared with everyone having their own storage space on the PC, their own printer, etc. Kearns: There's a big difference between the NetPC and the NC. Its the NC that'll needed bigger servers and bandwidth. But either way, there'll be costs involved - new equipment, new infrastructure, training and support. Thin clients do have a role to play in the corporate network - replacing dumb terminals, if nothing else. Imaginative IT managers will have a broad mix of NCs, Windows Terminals, NetPCs, PCs and workstations on their networks, with each contributing as best they can. Bradner: I see no real differences between NetPCs, NCs and terminals, and I doubt that there will be any significant cost differences between them. A corporation is not going to save any real money by tossing out old 3270 terminals and putting in NCs instead (except for the repair costs of the 3270). I would also doubt that there will be much savings in moving from|real| PCs to NetPCs or NCs - a whole pile of the costs are common - training, software etc. - and I'd expect that many of the other costs will balance out. There is one substantive difference between distributed PCs and the alternative, and that is the reempowerment of the corporate IS department - traditionally not the most cost-efficient part of the corporation. 6. To hear some people talk, intranets are the corporate computing platform today. But what should reasonable people really be working toward with intranets and what applications will never be intranet-appropriate? What's the biggest mistake people are making when it comes to intranets? Nolle: Not knowing what one is. We've found in surveys that while over 90% of companies have a commitment to intranets, only about 7% really have an idea of what an intranet is, how it would be different from just a corporate information network or an IP network. If you start with an objective view of what an intranet is, there is no application limit to one -any more than there is to any other data network - except cost. Gibbs: The applications that will never be intranet appropriate are those with heavy and/or complex database demands or where complex functionality, such as dynamic multimedia in a real time environment, is involved. The goal to work towards is information distribution. The biggest mistake is lack of planning and lack of attention to detail (wherein God is, so I'm told). Heckart: Intranets are appropriate when information needs to be widely accessible to a number of people and/or when collaboration is desired. This is why networks are built in the first place. What's different about an intranet is it standardizes on a set of plug-and-play, off-the-shelf, networking and programming protocols. The intranet uses Web technologies and interfaces so that it is easy and intuitive to use and navigate. The two biggest mistakes being made is that many users don't go into the process of building an intranet with a clear understanding of what they hope to achieve, thus they never know whether they did. And, they are building many separate intranets - different intranets for different communities of interest and using different network facilities. This is the way networking was done, so why not intranetworking? Because it diminishes the economies of scale and thus the total savings. Briere: The biggest mistake that people make with intranets is assuming that they are missing out on something. These are nothing new, just renamed internal networks. What is new is a new generation of standards-based options for addressing intranets, and the fact that the more distributed economy is putting this on the front burner. It's too big a job to try to answer what applications don't belong on intranets. But I will say that a good manager should define intranet very generally as almost any information that needs to be shared internally - whether hardcopy, fax, electronic, voice, video, whatever - and start prioritizing the benefits that would be gotten the soonest and with the biggest bang for the buck to start migrating to an internal information backbone or intranet. Kearns: An intranet is a good way to reduce the use of paper while delivering data in a more timely manner. The best uses so far are distribution of HR, PR and marketing information, forms automation, such as expense reports and vacation requests, and project management, where you can combine typical timeline information with a data repository. Data entry (telemarketing, accounting, etc.) apps aren't yet ready for the intranet, though. The biggest mistake people make with intranets is abysmal design. The intranet has to attract users in much the same way an Internet site does. This requires paying close attention to design issues as well as Quality of Service. Bradner: Another case of pundits seizing on something as a common answer without considering the actual needs. Intranets, and by that most people seem to mean Web-based services, is a rather common answer these days. I think that within a very few years TCP/IP will be *the* network protocol in almost all corporate networks, with only legacy SNA as an alternative. But I'm not that sure we know what the application set will be. Clearly the Web will be a big player but I expect to see others also, most unknown as of now. One can force-fit heavy data entry applications into Web- and Java-based systems but for many of these application-specific software on the desktop seems to be a far better idea. One big mistake that I keep seeing is to place people in charge of the corporate intranet whose training and expertise are in IBM SNA networks. The TCP/IP clue density is more than a bit low and there is little language in common between these people and people who actually understand TCP/IP networking. 7. We keep hearing that telecom reform isn't happening. But what s really going on in the telecom industry today and how should customers be taking advantages of the trends? Nolle: Reform is happening at exactly the pace expected - slow. The telecom act won't really kick in until some time in 1998. Then, the biggest impact will be on services at fractional and full T-1 levels, where copper-based provisioning is involved. There will be competition in major metro areas only, however, and the focus will be on services that cost more than $200 per month. Buyers will need to be flexible in the first three years or so (till about 2001) to take advantage of new deals. Keep contract terms short and avoid minimum carriage clauses to get discounts. Gibbs: From my perspective - that is, as a non-telecom analysis type of guy - pricing seems to be improving most particularly for WAN data connections, making for cheap interconnect via Internet ISPs. Routing as much traffic as possible over Internet links makes a lot of sense. That includes telephony. Heckart: There is not much for customers to take advantage of yet - at least as a result of the last attempt at reform. What any customer interested in better future prices and service provider selection needs to do today is to vote with the pocket book. Give some of the budget to the competitive service providers - especially in the local area. If you say you want choices, but always give your network to the big provider, you're perpetuating the problem. Money talks, and without revenues and customers the competitive providers won't survive. Briere: Look, when the reform first happened we warned people not to expect it anytime soon because it'll be tied up in courts forever. This is still what we are saying. Everyone is finding out its more expensive, more complicated, more damaging, more trouble and more market-upsetting than initially imagined. Washington classically figured it could come in and remake the industry overnight, and it was wrong. If anything, events have shown, again, that Washington has a very hard time controlling the marketplace with all the market forces at work. Ttions for security and that there would be no-fee, not even the current $50 one, in any cases involving the use of intercepted credit card information, that could send a strong message. This does not fix the companion worry about privacy, that will be harder to address. Heckart: Not all but a lot of the security concerns are overhyped. How often do people give total strangers their credit card numbers over the phone today? How secure is this? AT&T has the right approach in overcoming hesitation about electronic commerce with its SecureBuy program. There is no risk to the merchant or the purchaser here. This is a problem that can be 80% to 90% solved with good marketing, not technology. For some companies and some applications it will take solid technology, but for many a simple guarantee of protection and reimbursement should suffice. Briere: I'm the worst one to talk about Internet security because everyone in my own company disagrees with me. I think it's hooey at the highest level. Yes, we need protection and control over access - we have that with our private nets. But FUD is keeping a lot of applications from moving to EC, when the downside risk is actually very small. I think people need to start experimenting now, because this is going to move very fast when it moves. People will be surprised at the differences between now and five years from now. This comes from the father of a family that orders groceries by fax and clothes by mail-order. EC has been here before -- all we are really talking about is moving it to the TV or computer, and that jump will not be as hard as many project. Kearns: If you show people stats concerning the reliability and security of EC vs. traditional paper technologies, their eyes open very wide. This lasts about an hour. We have to keep doing it, over and over, while pointing out further advances in EC. It has to be done almost one-on-one until a large enough core group of unfearful executives emerge. Nolle: Why do we want to? That's the first question. Do we think that EC in the sense of buying on the Internet is going to create new demand? People buy because they have money and interest, and there's probably not more than three to eight percent of new demand that the Internet could create, by being able to put buyer and seller together at the feature exploration or value exploration level. Theress no indication I can see that completing the purchase on the Internet once the stimulation of interest has occurred is really worth investing in. Does the buyer get all hot for a new product and then say, 'Shucks, my mother was frightened by an 800-number vendor so I won't call toll-free to buy this'? I don't think so. Barriers to EC are like barriers to network management purchasing - every time you knock down an objection the buyer raises another one. If they have barriers in their minds, its because they doubt the intrinsic value. 8. What are the developments in network/systems management to which our readers should pay the most attention? Nolle: There are two issues; policy management and jurisdictional management. Policy management is important because it lets buyers set policies to govern future network behavior, rather than enter reactions to current behavior. That's what buyers wanted all along. Jurisdictional management has to be defined first - it's the ability to present a management view that is suitable to the interest of the user. Most companies have multiple consumers of management data, but only one system to provide it. That system is targeted at the network professional, who's only one of the consumers. The real power in networking is the end user, and a management system targeted at the end user would have to be more service-oriented. Bradner: There are two big problems with the current generations of network management 'tools': they don't tell you when your users are going to be upset with the service they are getting; and they are mostly toys for gurus. I expect to see management systems coming on the market in the next year or two that understand that users have a very confused understanding of what the 'network' is. They see a collection of services, some local to their desktop and some remote. It is unlikely that the user thinks all that much about the connectivity tissue between the services and the user, unless you are doing a real bad job of managing the net to begin with. I expect that we will start to see network management systems that understand what the network is from the user's point of view over the next year or two. Hopefully these new systems will understand that not every corporation can find enough gurus to run their nets and make the systems a bit more people-friendly. Gibbs: Distributed directory and naming services and technologies that recentralize data processing, such as back-end Web server applications and applets that window into remote server-based processes. Watch the likes of Digitivity, Microsoft with Visual InterDev, and the Java camp. We also need to watch the increased decentralization of offices and the growth of telecommuting, and increase the focus on information content and knowledge management. Heckart: Portable operating systems like Java and now Inferno could make it possible for lots of non-intelligent, non-networked devices to be intelligent and networked. From your watch to your smart card to you-name-it, these technologies combined with affordable anywhere, anytime communications will lay the foundation for the communications age to come. Service providers and end users alike need to be focusing on network integration. Whether this is over IP, frame relay, ATM, or cans-and-strings, the integration of voice, fax, and data over the same network will save billions of dollars a year. Internet voice and fax, alliances between PBX and data network equipment vendors, and voice and fax over frame relay and ATM all need to be seriously considered and evaluated. Will your PBX be LAN attached or will the data route through the PBX? How will you consolidate and operate the combined network? The savings are worth the trouble of exploring these questions. Briere: I think the advent of Java into management systems is really revolutionary, given the expansion of Java-speaking devices. You can manage a network from a cellular phone outfitted with a browser, today. That's a far cry from the Sun SparcStation approach a few years ago. Imagine being able to walk off an airplane and go to an airport kiosk to check on the health of your network - pretty amazing. With multinetwork access into the home, you'll be able to have your network management alarms come through to your TV set, as soon as we get better resolution there. Kearns: The Internet is becoming less U.S.-centric every day. Readers need to watch the UN General Assembly to understand what could happen. Directory services is the most important technology decision facing our readers right now. They need to make some decisions and lobby their vendors to fall in line with them. Mobile computing/telecommuting will affect a majority of our readers within the next 3 years. You'd better have a plan in place to deal with it. 9. Is NT going to take over the world? Listening to the press, you'd think so. What are the weak-spots in the NT story? Nolle: NT has already taken over the world, but the Unix players don't know they're dead. The stories on NT's weak spots are important, but the most important feature of any operating system is that users can relate to it. They relate to NT better than to any other server or multi-user platform. Go ahead and send snotty e-mails, Unix fans; I'm only telling the future, not making it. Gibbs: The anti-MS camp waving the Java flag is in high gear and that indirectly weakens the NT story. NT 4.0 is, without doubt, a great OS but it doesn't fit every IS need anymore than NetWare or Unix does. I'd place NT in a dominant position but not the flat-out winner. Kearns: NT is well on its way to reducing Unix to a niche market as an application server. Its still a long way, though, from dominating the NOS market and may never get close, since Microsoft appears doomed to never understand networking. Its a desktop company and will always be a desktop company. 10. Is there a Year 2000 Network Crisis looming that no one is discussing? Nolle: I'm not convinced there's really a Year 2000 computing crisis. I saw a TV commentary on the issue that contained just about every piece of misinformation that could be assembled on the topic. Chicken Little said the sky was falling; it wasn't, but everybody remembers old Chicken Little and nobody knows who said the sky WASN'T falling. Moral: hype gets ink. Gibbs: Only as a reflection of the general Y2K crisis. I suspect that many network management systems will show signs of problems but I don't think it will be anywhere near as bad as the mainframe world. Briere: Yes, what are IBM and all the other systems integrators going to do in 2001? Bradner: Getting reservations for New Year's Eve? There is not all that much of a Y2K issue in Internet technology and applications, a few things are showing up but so far they are minor. That may not help your state of mind all that much if the other kind of ATM won't give you your money because you have not used your account in 99 years. Kearns: Well, we did just hear about a problem with JavaScript, so there are probably a number of problems hiding in places that no one has looked as yet. 11. Wild card: What question about overhyped topics should we have asked and how would you answer your own question? Nolle: The big question is not on overhyped topics but on why any topics are overhyped. Are we heading for a tabloid technology press? Controlled circulation pubs are printed because advertisers believe they influence buyers. Is 'entertained' or 'titillated' a substitute for 'influenced' in this sentence? Gibbs: A general observation about how the press treats market issues: We have a tendency to report as if each new paradigm and technology will sweep away the existing solutions and problems overnight. This flies totally in the face of the market's intrinsic inertia and existing momentum: Those who have no truly pressing need will stick with whatever workable solutions they have while those who have problems to solve will gravitate towards solutions that the market has proven and are known to be low risk. If anything, pragmatism is underhyped while novelty is overhyped as if it were proven to be useful. Briere: It's funny, you asked almost all LAN type topics and hardly any WAN ones, unless the network crisis question above was one. I think you should ask something about voice, data, and video integration across the WAN. Do we need to move to change our planning for this now that viable integrated offers are moving towards the market? I'd say that users need to be looking at each site and application for its needs, and the WAN of the future/today needs to be able to mix and match at will . You need to allow remote home office users to come in on IP-based voice and video and transit out via circuit-switched gateways, in some instances. You need to allow access to fax mailboxes via IP as well as circuit switched. The intermingling of the Internet and the circuit-switched WAN is going to be an interesting line to walk for most managers going forward, as the Internet and other data services like FR and ATM will start competing for a lot of the traditional WAN traffic, especially fax. Kearns: What will be the outcome of the Netscape vs. Internet Explorer battle and how would the right or wrong choice impact the user and the intranet? For the foreseeable future, savvy users will use both. Its content providers who could force the issue. Bradner: You seem to have hit most of the over-hyped topics just fine.
How to Advertise | Copyright
Home |
NetFlash |
This Week |
Industry/Stocks
|