Building E-Commerce

December 15, 1998

If your network is already performing at near capacity, youıll need to make architectural adjustments before implementing a new server. Remember, even though a chunk of this e-commerce server solution will sit outside your firewall, itıs still on your network and will weigh heavily on overall network performance.

If your performance data shows that traffic is on the heavy side, look first to all your high-usage devices. That means servers. Typically, these generate the most network traffic by necessity. Easing traffic load could be as simple as building your own backbone specifically for your server farm. Upgrading your server segment to Fast Ethernet or Gigabit Ethernet is a quick and easy way to greatly ease network traffic load. For those not using Ethernet, FDDI is another good and very mature backbone technology that will also ease performance troubles, but it will cost you both in terms of price and complexity when compared to advanced Ethernet solutions. ATM is another option, but frankly, FDDI is just as mature and much easier to implement than ATM.

Examining your routing architecture is another necessary step, both in terms of solving performance problems and in determining the granular mechanics of your e-commerce connection. Segmenting additional e-commerce extranet traffic is a good idea. Segmenting traffic will not only provide better performance, it will also make the e-commerce traffic easier to track and manage. You can go one step further and place such traffic on its own switch fabric, in effect creating a separate e-commerce backbone. This is expensive, but great in terms of ease of design, performance benefits and security. Again, determining how far you need to go is dependent on testing.

Testing your e-commerce traffic is probably the trickiest step in the whole process. The only way to succeed is to treat any e-commerce application, storefront or extranet, as a full-blown custom client/server application. That means youıll be testing not only during this network construction phase, but also throughout the siteıs development and implementation phases.

Unlike actual client/server application processes, e-commerce developments usually donıt have a lot of time. The need to get on the Web and start competing always overrides ITıs need for caution. This means youıll be building the network infrastructure probably long before the developers are ready with any kind of alpha site prototype. Naturally, youıll be working on educated guesses at that point, but you should be backing those up with test data as soon as it becomes available.

Again, by keeping in close communication with the siteıs development team, you can minimize any nasty architectural surprises. Will the site be using a back-end database? Almost certainly, but will it be flat file, relational or universal and will it need to tie in with an existing legacy system? Who will have access to queries and what kind? Will the database require its own hardware? Will there be additional hardware in terms of a transaction server or similar high-availability middleware? Are the developers planning on any advanced Internet technologies like Java applications, videoconferencing, push technology or voice over IP (VoIP)? Will extranet users require any kind of direct dial-in, and if so how will that affect your RAS (remote-access server) platform?

Finding this information as soon as possible will enable you to make an educated guess on how that traffic will affect your network. That guess will need to be improved by testing, which will typically begin with application modeling. A number of network modeling tools exist, which all basically allow you to run simulated application traffic through your network as a ıwhat-ifı exploration tool. Ganymede Softwareıs Chariot 2.1 and Pegasus, for instance, let you model actual application traffic over both local and wide-area segments. Once data has been obtained, you should perform any network upgrades before moving on to the actual hardware server phase.